(SOLVED) IPSEC behind pfsense NAT not working

mrhaamann

Hi all,
we are in the process of migrating all IPSEC channels to a Linux box behind the pfsense firewall (still 2.2.6 release),
because upgrade of pfsense is not possible due to a well known bug in pfsense 2.4.x with ipsec and openbgp on one machine.

The decision was taken to move all the IPSEC stuff to a separate machine.
Some channels have been moved successfully, but now we are running into a situation which is unexpected:

The product on linux for ipsec is strongswan (different version, but setup is mostly 1:1 with the settings from
pfsense).
When we initiate a tunnel in IKEv1, an outgoing packet with UDP 500 (ISAKMP) is sent. The issue here is,
that it is not answered.
A packet trace on the pfsense shows that the packet is not NATed but goes on the WAN line with internal address.
Other packets (both IKEv1 and IKEv2) are transformed correctly to the WAN IP adress.
Outgoing NAT is manual, we have two rules:
LAN -> Any -> Destination Port 500 -> WAN IP -> Static Port true
LAN -> Any -> no specific Port -> WAN IP -> Static Port false
All outgoing packets and incoming packets are accepted by firewall rules, no denies.

Incoming NAT has been setup to accept the Ports 500/4500 UDP and forward to the linux machine.
Also, forward ESP to the Linux machine.

The Linux box has setup an iptables construct which allows only the intended connections.

ping to the public endpoint of the ipsec peer is successful from the box, even a netcat
udp packet with port 500 is treated correctly according to the package dump !

We even stopped the whole ipsec on pfsense to make sure nothing is modified from the local service.

This happens with different endpoints and I cannot see why.
Anybody to imagine what happens here ?

Any hints are welcome. We will reboot the box tonight to make sure there is no internal problem.

Thx for you thoughts, Marcus

Derelict

Upgrade and switch to frr for bgp.

mrhaamann

Thx, this was one option, but we need to separate the IPSEC for other reasons, too.
There is not much effort in upgrade and then encountering the same issues as before
(we cannot make sure the same phenomenon is not occuring in later release).

The problem here was that the IPSEC tunnel was disabled and shutdown on the pfsense and in the next step, the tunnel
was started on the linux system.
Nothing wrong so far, we checked all the ipsec status, even shutdown the ipsec service.
But the outgoing initial packages were not NATed.

After hours of research, the solution was found:

The solution is in the UDP protocol, which is connectionless (but not stateless).
In the firewall states, the old UDP connection (500:500) was still present from the before-active IPSEC connection and
after kicking out this state, a new connection initiated from the linux box was accepted successfully.

The useful point came from https://forum.pfsense.org/index.php?topic=45255.60 (having the same issue with SIP UDP states)

Thank you all !

Marcus