IPSEC transport, LAN ip cannot ping remote peer via NAT

hrodenburg

Hi all,

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.

The topology:

(192.168.1.0/24)–-(.10)pfsense 2.0 RC3 AMD64–---[internet]–---(b.b.b.b)Linux box–-(192.168.2.0/24)

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.

Regards,
Hugo

Metu69salemi

sounds like it has no route to tunnel anymore, can you try to add route to tunnel?

hrodenburg

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?

Metu69salemi

You can count me off, it was only thing what crossed my mind. cause i had similar problem with watchguard at work

hrodenburg

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.