Masquerading configured on host, LAN hosts can't access Proxmox guests from lan

adrian_vg

Well-Known Member
Mar 8, 2020
81
43
58
Sweden
Hello all!

Just recently started with Proxmox for my home lab.

I managed to configure my proxmox server and have the guests sit on a private network.
The guests can ping the internet.
From the proxmox host I can ssh to the guests.
I can't however ssh from my office computer to the guests.

A visual scheme:

Internet
|
Router with NAT
|
Proxmox host, 192.168.0.9 -------------------------Office computer, 192.168.0.100, can access proxmox server and the internet.
Can access internet and proxmox guests
|
Proxmox guests, 10.10.10.x X------------------------------------^Office computer can't access proxmox guests on 10.10.10.x
Can access internet and proxmox host


Basically I need some hints on how to make the office computer access the proxmox guests directly, if at all possible.

My proxmox host /etc/network/interfaces/:

root@dragonborn:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eno1
#"real" ip address on skynet-tng.internal
iface eno1 inet static
address 192.168.0.9
netmask 255.255.255.0
gateway 192.168.0.1

iface eno2 inet manual

iface eno3 inet manual

iface eno4 inet manual

auto vmbr0
#private sub network
iface vmbr0 inet static
address 10.10.10.1
netmask 255.255.255.0
bridge_ports none
bridge_stp off
bridge_fd 0

post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o eno1 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o eno1 -j MASQUERADE




Thanks for any hints in advance!
 
Your config looks correct, what I assume is happening is that you didn't configure a route to your 10.10.10.0/24 network on your "office computer". Think about it like this:
  • Your PVE is configured correctly, and (since you set ip_forward) will act as a router between all networks it knows about
  • The masquerading allows your guests to access the internet
  • Your guests can access the PVE host since all packets are obviously routed through "vmbr0", which belongs to the PVE host, which knows about itself and can route packets there
  • Your office PC knows about the network 192.168.0.0/24 and can directly access hosts in it - this includes your router to the internet and your PVE host
  • Howver, it does *not* know how to access hosts in 10.10.10.0/24 - it simply doesn't know about that network
Now, since your PVE host is already configured as a router, it should theoretically be as simply as adding a static route on your office PC, e.g.:

Code:
ip route add 10.10.10.0/24 via 192.168.0.9

Run ip route to verify the command worked. Then, a ping or traceroute to your VM guests should work, since your PC will send packets to the MAC address of 192.168.0.9 (your PVE host, which is directly attached and can therefore act as a next-hop to your PC), which will then know about 10.10.10.0/24 and correctly forward the packets.

A good way to test such setups is via tcpdump -v -i any icmp and then running some pings to see the packets traverse your network.
 
  • Like
Reactions: adrian_vg
Hello and thanks Stefan_R!

I touched static routing while trouble-shooting the issue on my office computer, but wasn't sure if that was the right way to go, then got stuck not knowing if this was a problem on my Proxmox host or something else.

Excellent "visualization" from you, I think I can go forward setting this up with your hints as a base.

Appreciate this very, much - thanks!

//AvG
 
Last edited:
Come to think of it, couldn't this static route be added in my router, so that all connected devices on the 192.168.0.x-net could benefit from it?
Is this a good idea, securitywise etc?

//AvG
 
Come to think of it, couldn't this static route be added in my router, so that all connected devices on the 192.168.0.x-net could benefit from it?
Is this a good idea, securitywise etc?

Of course, routing is what routers are for ;) There shouldn't be any security implications, in fact, it would allow you to do neat things like VLAN (or simply physical) network segregation and then putting up firewall rules on your router/firewall to govern who gets access to which device/VM/container/whatever.

Especially in homelabs and smaller setups there might be a slight issue with performance though. Since this is an internal connection, you might want to use the full bandwidth for file transfers etc..., and some lower-power routers might not be able to keep up with this. Testing your use-cases specifically is key here.

You can also do both, use a lower-powered router for general devices and a static route for those needing switched performance levels - the sky is the limit in networking.