I have a proxmox server in a data center with a few public ipv4 addresses, with a opnsense router VM handing out virtual IP’s to everything including proxmox. It also runs a wireguard peer.
When I ssh to proxmox’s public ipv4 from my laptop connected to witeguard, it gets rejected. If i ssh to proxmox’s internal LAN IP it works just fine.
There’s nothing in SSH config to indicate why its doing this, I’m totally confused. From other computers not on wireguard it works just fine
What sort of rejection are you getting? You might get some more info with “ssh -vvv”
Have you compared the host key, to make sure you’re actually hitting the correct instance of SSHD?
The internal of VPNs and networking are not my thing, but is that not the expected behaviour of a VPN (or maybe how it is configured)? If you are connected to the VPN then you will be routed to the private range, if you are not on the vpn you will get the public address.
If you turn off wire guard on your laptop, can you connect to the public IP?
How is DNS for wire guard, or the system, configured? Maybe resolving the private IPs before public?
You might just need an extra firewall rule in there somewhere to allow the connection.
Try watching the firewall’s live view while attempting the ssh connection to the public IP.
Nevermind, I just read it again. @mikejmcfarlane is correct. This is the expected behavior. When you VPN in first, you should be using internal addresses.
Review the system log files on both the Proxmox and opnsense router for any warning related to SSH and network traffic.
If you make the VPN connection and then attempt to SSH to the Proxmox host, regardless of the IP used to contact the host, shouldn’t you appear as being on a local subnet? So why rejected.
It’s also my interpretation of the original post that SSH with no VPN works fine which then suggests there are no firewall rules to restrict SSH to a particular interface or address.
So the rejected VPN → SSH → Public IP does seem strange to me.
Because when you’re on the local subnet it expects you to ssh to the LAN interface rather than the WAN, see below. I know it’s not the same scenario, but I suspect @iowa needs a similar firewall rule in place for this to work the way they expect it to:
@iowa, if you get a rule in place on the WAN interface to allow ssh from the wireguard client’s IP and it still doesn’t work, then you should check the wireguard interface’s rules next.
Just in case; Make sure the public IP you’re trying to hit is in the range of the wireguard peer’s allowed IPs (client config, peer section).
I’m assuming you have 0.0.0.0/0 there, because if you were only pushing traffic to the private network through wg then ssh to the public IP wouldn’t get routed through wg and would still work like it does when you aren’t on wg.