IPSEC transport, LAN ip cannot ping remote peer via NAT
Being new on this forum I will briefly introduce myself. I'm quite a newbie with pfSense, but maintain Linux (and Windows) servers for many years now. Including ipsec connections between Linux and Cisco routers. Recently I finally got spare time to experiment with pfSense. No experience with the
previously 1.2 release, but the 2.0 release looks amazing! I start to love it already!
However, I encouter the following issue. I'm still not sure this is by design or me making a mistake. Hopefully someone can help me out here.
a.a.a.a = static public ip on the pfsense box
b.b.b.b = static public ip on the linux box
The pfsense configuration is quite basic. I configured an IPSEC transport policy between the pfsense box and the linux box using pre-shared keys (main mode, AES, SHA, PFSgroup2). The policy starts without errors. I can succesfully ping from the pfsense box to the public ip of the linux box. Tcpdump on the linux box shows ESP packets as expected:
17:57:02.906183 IP a.a.a.a > b.b.b.b: ESP(spi=0x3287b48e,seq=0x5), length 116
17:57:02.906274 IP b.b.b.b > a.a.a.a: ESP(spi=0x0e42e878,seq=0x5), length 116
I configured basic NAT on the pfsense box so clients within the 192.168.1.0/24 range has access to the internet. Pinging several public ip's works without problems.
However, if I try to ping b.b.b.b (the public ip of the linux box) it won't succeed.
Monitoring with tcpdump on the Linux box reveals that unencrypted packets arrive from a.a.a.a (the public ip of the pfsense box).
18:01:12.313036 IP a.a.a.a > b.b.b.b: ICMP echo request, id 64215, seq 29433, length 40
18:01:17.611850 IP a.a.a.a > b.b.b.b: ICMP echo request, id 64215, seq 29689, length 40
This is not expected since I configured an IPSEC policy between the hosts a.a.a.a and b.b.b.b. Somehow unencrypted traffic arrives at the Linux box from the pfsense box where it bypassed the encryption process.
The Linux router refuses to answer these ping requests because it's configured with an ipsec policy for that host an the traffic arrives in "plain text".
I've build several setups like this with Linux/Cisco, but never seen this behaviour. Is this me doing something wrong? Or is this expected behaviour?
Hopefully someone can answer this question.
sounds like it has no route to tunnel anymore, can you try to add route to tunnel?
Thanks for the quick reply.
However, I don't see what there can be wrong with the routing. The setup is quite simple, the routers are default gateway for both the private subnets.
What also fails is pinging from the lan interface of the pfsense box (selecting the LAN interface in Diagnostics->ping). It also generates unencrypted traffic on the destination box. Pinging other public ip adresses succeeds.
The routes on the pfsense box are these:
netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default a.a.a.131 UGS 0 2984 em1 a.a.a.128/26 link#2 U 0 59457 em1 a.a.a.186 link#2 UHS 0 0 lo0 127.0.0.1 link#3 UH 0 318 lo0 192.168.1.0/24 link#1 U 0 63806 em0 192.168.1.10 link#1 UHS 0 0 lo0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 fe80::%em0/64 link#1 U em0 fe80::88b8:8aff:fe59:daa4%em0 link#1 UHS lo0 fe80::%em1/64 link#2 U em1 fe80::5809:20ff:fe55:d273%em1 link#2 UHS lo0 fe80::%lo0/64 link#3 U lo0 fe80::1%lo0 link#3 UHS lo0 ff01:1::/32 fe80::88b8:8aff:fe59:daa4%em0 U em0 ff01:2::/32 fe80::5809:20ff:fe55:d273%em1 U em1 ff01:3::/32 ::1 U lo0 ff02::%em0/32 fe80::88b8:8aff:fe59:daa4%em0 U em0 ff02::%em1/32 fe80::5809:20ff:fe55:d273%em1 U em1 ff02::%lo0/32 ::1 U lo0
Should there be specific routes for IPSEC? (And thus separate devices?)
I'm more familiar with Linux than FreeBSD, so I'm not sure how FreeBSD has it's implementation of IPSEC. But when using an (recent) Linux setup, it uses NETKEY and you have no separate IPSEC devices anymore, only ipsec policies. With older implementations which used KLIPS, you've got seperate ipsec0,1,2 devices with there own routes for the encrypted traffic.
It looks to me that pfSense uses the first (like NETKEY) approach.
Anyone has a clue?
You can count me off, it was only thing what crossed my mind. cause i had similar problem with watchguard at work
Today I installed version 1.2.3 which behaves the same way as the 2.0 version does. Except that it does not allow the creation of a transport policy and I had to use a tunnel policy.
I think it's related to how freebsd's / racoon's implementation of ipsec is. I will try figuring it out if this can be fixed. I'm not very experienced with freebsd/racoon (yet… ;D)
Once I managed to get it working, I will post an update.