Can't get multi-network NAT port forwarding to work

carlpett

I have a small network behind a pfSense (2.0) box, installed on a VMWare ESXi 5.5 host. Up until yesterday I had only one internal network, 192.168.0.0/24, and everything worked quite nice. Now, however, I want to introduce another net, 172.16.10.0/24, which will be used for services exposed to the internet. I've set up an additional interface (called OPT1DMZ), and a server on this net. I have also added a NAT rule to forward ssh (port 22) on the WAN interface to the server I set up.

Sadly, this was not enough to just work. If I try to ssh to my external address, I get a timeout. I've run tcpdump on both the OPT1DMZ interface on the pfSense box, and the interface on the server. I can see that traffic arrives properly to the server, but I don't see the server responding with any outbound traffic.

Initially I thought I was missing some firewall rule to allow outbound from OPT1DMZ, but that doesn't seem to matter - I even added a pass-all-to-everywhere rule with logging turned on, but it doesn't turn up anything in the logs.

I'm uncertain where to continue looking. If I try to do pings to anything not on the 172.16.10-net I just get 100% package loss (ie, not Destination not reachable). My routing table on the server looks like this:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    2      0        0 enp2s0
0.0.0.0         172.16.10.1     0.0.0.0         UG    3      0        0 enp2s1
127.0.0.0       127.0.0.1       255.0.0.0       UG    0      0        0 lo
172.16.10.0     0.0.0.0         255.255.255.0   U     0      0        0 enp2s1
192.168.0.0     0.0.0.0         255.255.255.0   U     2      0        0 enp2s0

That is, enp2s0 is connected to the "first" net as well, for administrative access. Can that be the issue?

carlpett

Update, I did an ifconfig enp2s0 down, and now it is possible to set up an ssh connection. My guess is that it is due to the enp2s0 interface having a lower metric for 0.0.0.0, it will try to send the reply that way. Is this correct? What can I do to remedy this?