Solved [Solved] NAT IPSec Traffic (pf or ipfw)

Hi everyone,

I'm trying a lot to get a nat running within the IPSec Tunnel (using enc0). I tried it this ways:
- pf
- ipfw (kernel NAT)
- ipfw (with natd)

The problem is, that it works only with ICMP packets and not with e.g. SSH or LDAP (even if the tcpdump of all commands look like there is no translation back to the local IP, the ICMP ping is working).

As I can see in other posts about NAT IPSec traffic it seems there is a bug in 10-RELEASE with pf and NAT in IPSec, would this affect even the ipfw/natd combination?

This is my setup:

- FreeBSD 10.0p9
- One network card which has the public IP (this is an internet machine) and the local IP (192.168.101.10) for the inner IPSec connections:

Code:
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4019b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,VLAN_HWTSO>
        inet a.a.a.a netmask 0xfffff800 broadcast a.a.b.255
        inet 192.168.101.10 netmask 0xffffff00 broadcast 192.168.101.255

- natd.conf looks like this:

Code:
use_sockets yes
same_ports yes
unregistered_only no
alias_address 192.168.101.10
log yes
log_ipfw_denied yes

- ipfw.rules looks like this (pass by default):

Code:
10000     0       0 divert 8668 ip from a.a.a.a to 10.192.0.0/10 via em0
65535 52385 7348455 allow ip from any to any

- ipsec.conf (Strongswan) looks like this:
Code:
conn net-net
        mobike=no
        left=a.a.a.a
        leftsourceip=192.168.101.10
        leftsubnet=192.168.101.0/24
        right=b.b.b.b
        rightsubnet=10.192.0.0/10
        rightid=@snet-xxxxxxxxxxxxxxxx.com
        authby=secret
        auto=route

A sample output of tcpdump on the enc0 shows that the (in this case ldapsearch) request is going out (well masqeraded) and comes back in the tunnel directing the former source IP 192.168.101.10 but this traffic is not translated into the real IP before the outgoing NAT happens (there is no traffic (except ESP) on em0!):

Code:
18:02:51.998687 (authentic,confidential): SPI 0x321a366c: 192.168.101.10.29856 > 10.207.0.1.389: Flags [S], seq 1671478258, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 20002092 ecr 0], length 0
        0x0000:  0200 0000 321a 366c 000c 0000 4500 003c  ....2.6l....E..<
        0x0010:  6a7e 4000 4006 7e62 c0a8 650a 0acf 0001  j~@.@.~b..e.....
        0x0020:  74a0 0185 63a0 bbf2 0000 0000 a002 ffff  t...c...........
        0x0030:  4b69 0000 0204 05b4 0103 0306 0402 080a  Ki..............
        0x0040:  0131 352c 0000 0000                      .15,....
18:02:51.998692 (authentic,confidential): SPI 0x321a366c: a.a.a.a > b.b.b.b: 192.168.101.10.29856 > 10.207.0.1.389: Flags [S], seq 1671478258, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 20002092 ecr 0], length 0 (ipip-proto-4)
        0x0000:  0200 0000 321a 366c 000c 0000 4500 0050  ....2.6l....E..P
        0x0010:  6a7f 0000 4004 0000 538a 508a 57f5 06bb  j...@...S.P.W...
        0x0020:  4500 003c 6a7e 4000 4006 9fbb c0a8 650a  E..<j~@.@.....e.
        0x0030:  0acf 0001 74a0 0185 63a0 bbf2 0000 0000  ....t...c.......
        0x0040:  a002 ffff 4b69 0000 0204 05b4 0103 0306  ....Ki..........
        0x0050:  0402 080a 0131 352c 0000 0000            .....15,....
18:02:52.074175 (authentic,confidential): SPI 0xc0bb7152: b.b.b.b > a.a.a.a: 10.207.0.1.389 > 192.168.101.10.29856: Flags [S.], seq 3925922511, ack 1671478259, win 16384, options [mss 1382,nop,wscale 0,nop,nop,TS val 0 ecr 0,nop,nop,sackOK], length 0 (ipip-proto-4)
        0x0000:  0200 0000 c0bb 7152 000c 0000 4500 0054  ......qR....E..T
        0x0010:  a5a1 0000 3104 e140 57f5 06bb 538a 508a  ....1..@W...S.P.
        0x0020:  4500 0040 7a76 0000 7e06 91bf 0acf 0001  E..@zv..~.......
        0x0030:  c0a8 650a 0185 74a0 ea00 d2cf 63a0 bbf3  ..e...t.....c...
        0x0040:  b012 4000 7332 0000 0204 0566 0103 0300  ..@.s2.....f....
        0x0050:  0101 080a 0000 0000 0000 0000 0101 0402  ................
18:02:52.074246 (authentic,confidential): SPI 0xc0bb7152: 10.207.0.1.389 > 192.168.101.10.29856: Flags [S.], seq 3925922511, ack 1671478259, win 16384, options [mss 1382,nop,wscale 0,nop,nop,TS val 0 ecr 0,nop,nop,sackOK], length 0
        0x0000:  0200 0000 c0bb 7152 000c 0000 4500 0040  ......qR....E..@
        0x0010:  7a76 0000 7e06 91bf 0acf 0001 c0a8 650a  zv..~.........e.
        0x0020:  0185 74a0 ea00 d2cf 63a0 bbf3 b012 4000  ..t.....c.....@.
        0x0030:  7332 0000 0204 0566 0103 0300 0101 080a  s2.....f........
        0x0040:  0000 0000 0000 0000 0101 0402            ............

So, I'm really lost on this, because it looks fine, execept the tunnel traffic is never translated back from 192.168.101.10 to a.a.a.a which was the originator.
Is this a strongswan thing to 'bring the traffic' out of the tunnel, like it was strongswan 'putting' it in the tunnel after the masquerading happened on em0?

One more thing: I'm able to ipfw the outgoing traffic in enc0, but it seems the incoming traffic is never matching any ipfw rules ( ipfw show lists no packages on incoming direction, even if I can see them in dumping the enc0 traffic.).

Code:
ipfw show
10010     0       0 divert 8668 ip from any to any in via enc0
65535 63129 9068196 allow ip from any to any

I would be really happy for any hint on this issue.

Many thanks in advance!
icecoke
 
Re: NAT IPSec Traffic (pf or ipfw)

There is a bug in 10.0-RELEASE with how how the kernel is tagging the mbuf allocated with IPsec packets as it gets tagged to skip firewalling. Hence PF/IPFW/IPF can't NAT what it can't see. The short answer is that you need to upgrade to the latest 10.1-BETA or use an older branch of FreeBSD.

Long answers:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185876 - The PR with the technical details.
https://forums.freebsd.org/viewtopic.php?f=7&t=45691 - Same issue and the troubleshooting that helped find it.
 
Re: NAT IPSec Traffic (pf or ipfw)

junovitch said:

Thanks a lot @junovitch !

I thought this bug did affect all IPSec traffic, not only the incoming. And I thought my problem was not touched, as I can 'see' the IPSec traffic in enc0.
I will try the patch on 10-0-RELEASE as I can't move all of our systems to BETA or STABLE.

Again thank you for the hint!
 
Last edited by a moderator:
Re: NAT IPSec Traffic (pf or ipfw)

Hi again,

just wanted to drop the info for other coming into this issue. The patch provided in the link of junovitch did it, also for a 10.0-RELEASE.

icecoke
 
Back
Top