[strongSwan] strongswan - freeBSD - ipfw for nat
Sebastian Jäschke
jtkoerting at mac.com
Mon Sep 29 22:16:04 CEST 2014
Hi list!
I was reading and testing around with my setup for a long time, but I didn't get it. So I need to ask ;)
I'm trying to establish an VPN tunnel between a single freeBSD machine (one network card, public IP address) and an Linux-Box with openSwan installed as the gateway in front of a private network.
192.168.101.10 is the private source ip of the freeBSD box and 10.192.0.0/10 the private network behind the openSwan Gateway.
a.a.a.a is the public IP of the freeBSD box and b.b.b.b the public IP of the openSwan Gateway
+-----------------+ +-----------------+
| | | |
| freeBSD | | openSwan |
| Box | a.a.a.a b.b.b.b | Gateway | 10.192.0.0/10
| +----------------------------------------------------> Network
| 192.168.101.10 | | |
| | vpn tunnel | |
+-----------------+ +-----------------+
I'm using this settings. ipfw and natd is freeBSD specific, but I wonder if I miss something in the strongSwan settings, so just read this as if I have a linux iptables setting to translate the source a.a.a.a to 192.168.101.10 if the packages is targeted to 10.192.0.0/10.
This works in general, as the kernel trap that strongswan installed (auto=route) is initiating the VPN tunnel and traffic goes into the 10... network and even comes back. BUT it does not translate back to the a.a.a.a address which originated the ip traffic.
- natd.conf looks like this:
CODE: SELECT ALL
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: SELECT ALL
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: SELECT ALL
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!):
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~@. at .~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... at ...S.P.W...
0x0020: 4500 003c 6a7e 4000 4006 9fbb c0a8 650a E..<j~@. at .....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.. at W...S.P.
0x0020: 4500 0040 7a76 0000 7e06 91bf 0acf 0001 E.. at zv..~.......
0x0030: c0a8 650a 0185 74a0 ea00 d2cf 63a0 bbf3 ..e...t.....c...
0x0040: b012 4000 7332 0000 0204 0566 0103 0300 .. at .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..... at .
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.).
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!
Jimmy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20140929/9a6a8adc/attachment-0001.html>
More information about the Users
mailing list