Home / server / Questions / 616063
Accepted
Mei
Asked: 2014-07-29 09:44:59 +0800 CST

pfSense Cluster not working with Manual NAT

  • 772

I have two pfSense clusters, one is 2.1.4 and one is 2.1.3.

The directions suggest that Manual Outbound NAT is required, but the 2.1.3 cluster is working just fine using Automatic NAT, servers and all (including SSH and OpenVPN).

The 2.1.4 cluster is using Manual Outbound NAT and is causing grief. The NAT has three automatically added rules - labeled thusly:

  • Auto created rule for ISAKMP - LAN to WAN
  • Auto created rule for LAN to WAN
  • Auto created rule for localhost to WAN

These were also created for both our internal network (192.168.6.0/24) and our Dev Network (10.2.0.0/8). There are two manual rules:

  • IPs from the OpenVPN clients (192.168.7.0/24) to the outside are NAT
  • IPs from the Internet Net to the Dev Net are NAT

This firewall cluster was a test cluster - then the primary was broken out for a single system production firewall - and is now returned to being a cluster.... and has a number of IP changes along the way.

Things are now NAT to the Cluster address, but OpenVPN still uses the primary's address. What am I missing? Should I return to Automatic NAT? If, on the other hand, I move the 2.1.4 Cluster to Manual NAT (to handle communicating to the secondary via the VPN) am I going to be causing problems?

EDIT I should note that everything else seems to be working - including SSH to the cluster address, and outgoing HTTP shows the cluster address, and so on. SSH of course is port 22 - and OpenVPN is 1194 (over 1024). The OpenVPN client works (site to site VPN). It seems to be just the outgoing traffic from the OpenVPN server on port 1194 that is not NAT.

I tried running OpenVPN on port 23 with the appropriate firewall rules - and it still sent out the replies from the WAN address, not the cluster address.

UPDATE I did mention what was wrong, but not properly explicitly. This is what I expect:

  1. Packet arrives destined for cluster IP on port 1194.
  2. Packet is accepted by the OpenVPN Server.
  3. Packet is sent back to source from cluster IP on port 1194.

This is what I am seeing:

  1. Packet arrives destined for cluster IP on port 1194.
  2. Packet is accepted by the OpenVPN Server.
  3. Packet is sent back to source from primary IP on port 1194.

You suggested checking the IP that the OpenVPN server is bound to; was ANY and changed to Cluster IP; haven't tested it yet.

openvpn

1 Answers

  1. Best Answer

    The problem was actually much simpler than it sounded. The OpenVPN server was configured to listen on the interface any; when I changed the interface to the cluster IP, things started working. (Interface is one of the drop downs in the OpenVPN server configuration tab.)

    This solved two problems that had come up.

    Firstly, it listened to "all" interfaces but not the cluster IP as that wasn't included in its definition of "all". Changing the interface to listen on to cluster IP made the server listen solely on that interface, but that is the desired behavior anyway.

    Secondly, when the interface is listed as any the system doesn't see OpenVPN as part of the failover. Thus OpenVPN on all cluster nodes tries to run. Converting to listen on the cluster IP, this causes the system to recognize that OpenVPN is to be failed over and it works properly on all nodes.

    Problem solved. Hooray!

    • 1