NAT to WiFi interface not working with simple SDN

[Colin 't Hart]

I've been trying to setup a laptop with Proxmox for working on the road.

I have no bridge configured, only a WiFi interface. The laptop is a member of my home development cluster, and everything seems to work perfectly.
The WiFi interface on the laptop and the vmbr0 interfaces on the other cluster members are in the 192.168.1.0/24 subnet.

I setup a simple SDN zone with a 192.168.2.0/24 subnet. A VM on one of the other nodes works perfectly.
I can SSH into that VM from the host node, and traffic from inside the VM can go out to the internet.

On my laptop, both a container and a VM can't reach the internet, though I can SSH in from my laptop.

What should I be checking? I note that the iptables configuration is using SNAT and not MASQUERADE. But what I read elsewhere indicates that these work the same -- one allows you to specify an interface to MASQUERADE, the other allows you to specify an IP address as the Source for the NAT.

Some config:
On a node that works:

colin@echidna:~$ cat /etc/network/interfaces.d/sdn
#version:9

auto vnet0
iface vnet0
    address 192.168.2.1/24
    post-up iptables -t nat -A POSTROUTING -s '192.168.2.0/24' -o vmbr0 -j SNAT --to-source 192.168.1.50
    post-down iptables -t nat -D POSTROUTING -s '192.168.2.0/24' -o vmbr0 -j SNAT --to-source 192.168.1.50
    post-up iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
    post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1
    bridge_ports none
    bridge_stp off
    bridge_fd 0
    ip-forward on

On the laptop that doesn't work:

colin@lip:~$ cat /etc/network/interfaces.d/sdn
#version:9

auto vnet0
iface vnet0
    address 192.168.2.1/24
    post-up iptables -t nat -A POSTROUTING -s '192.168.2.0/24' -o wlp2s0 -j SNAT --to-source 192.168.1.62
    post-down iptables -t nat -D POSTROUTING -s '192.168.2.0/24' -o wlp2s0 -j SNAT --to-source 192.168.1.62
    post-up iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
    post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1
    bridge_ports none
    bridge_stp off
    bridge_fd 0
    ip-forward on

 

[Colin 't Hart]

The only thing that is needed is to edit /etc/sysctl.conf and uncomment net.ipv4.ip_forward=1. For some reason this is needed on WiFi machines but not on machines with Ethernet as their primary interface. Go figure.

 

[leesteken]

The only thing that is needed is to edit /etc/sysctl.conf and uncomment net.ipv4.ip_forward=1. For some reason this is needed on WiFi machines but not on machines with Ethernet as their primary interface. Go figure.

Enabling forwarding is indeed required for a NAT configuration: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#sysadmin_network_masquerading (echo 1 > /proc/sys/net/ipv4/ip_forward).

EDIT: There is also a sub-forum specializing in networking: https://forum.proxmox.com/forums/proxmox-ve-networking-and-firewall.17/

 

[Colin 't Hart]

Enabling forwarding is indeed required for a NAT configuration: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#sysadmin_network_masquerading (echo 1 > /proc/sys/net/ipv4/ip_forward).

EDIT: There is also a sub-forum specializing in networking: https://forum.proxmox.com/forums/proxmox-ve-networking-and-firewall.17/

I think you missed the bit where it's working on my Ethernet-only machines without enabling forwarding using /proc/sys/net/ipv4/ip_forward -- which I presume is what the ip-forward on in the generated /etc/network/interfaces.d/sdn is supposed to achieve.

 

[BobhWasatch]

I think you missed the bit where it's working on my Ethernet-only machines without enabling forwarding using /proc/sys/net/ipv4/ip_forward -- which I presume is what the ip-forward on in the generated /etc/network/interfaces.d/sdn is supposed to achieve.

The "whatever reason" is hidden in this statement: ..the vmbr0 interfaces on the other cluster members...

The Ethernet case is normally bridged. Everything is basically connected to a managed switch, in your case vmbr0. There is no IP routing going on, the kernel does not care about the IP addresses in the Ethernet payload, it just forwards Ethernet frames based on the source and destination MAC addresses. The Ethernet payload may not even be IP at all, it could be IPX or DecNet or something. You therefore don't need IP forwarding to be turned on.

The WiFi case is different. You can't use bridging with that. So you are using routing. The kernel must look at the IP addresses in the Ethernet payload to figure out where to send them. It won't do that unless IP forwarding is on.