[strongSwan] Fun with IKEv2, ip route and ip xfrm policy

[Andreas Steffen]

Hello Niccolò,

pass and drop policy support for IKEv2 was introduced with
strongSwan 4.5.3. See the following example for the configuration
details:

http://www.strongswan.org/uml/testresults/ikev2/shunt-policies/

Regards

Andreas

On 02/26/2012 02:01 AM, Niccolò Belli wrote:
> I was going mad with Openswan and IKEv1, then I discovered that IKEv2
> *really* rocks and I start playing with Strongswan because of the NAT
> support.
>
> Server A is a server with a 16 ip public subnet and some networks attached.
>
> Server B is another server, but it's *behind nat* and it has two interfaces:
> eth0 has ip 192.168.20.1/24, this is network where lies the nat router
> eth1 has ip 172.16.1.1/24 (another private network)
>
> What I want to achieve:
> - Server B has a public ip (2.118.245.45)
> - Server B surfs the net using the public ip
> - Server B reaches server A and its networks
> - 172.16.1.0/24 reaches server B, server A and its networks
> - 192.168.20.0/24 reaches server B, but it doesn't reach server A and
> its networks
> - Server A reaches server B and 172.16.1.0/24.
>
> SERVER A
> conn server1-server2
> 	  keyexchange=ikev2
> 	  authby=psk
> 	  left=217.162.38.19
> 	  leftsubnet=0.0.0.0/0
> 	  right=%any
> 	  rightsubnet=172.16.1.0/24,2.118.245.45/32
> 	  type=tunnel
> 	  auto=add
>
> There is nothing else to do on server A, but server B is much more
> interesting.
>
> SERVER B
> conn server1-server2
> 	  keyexchange=ikev2
> 	  authby=psk
> 	  left=%defaultroute
> 	  leftsubnet=172.16.1.0/24,2.118.245.45/32
> 	  right=217.162.38.19
> 	  rightsubnet=0.0.0.0/0
> 	  type=tunnel
> 	  auto=start
>
> Server B needs some tweaks because there are the following problems:
>
> 1) 192.168.20.0/24 doesn't reach server B.
> SOLUTION:
> ip route add 192.168.20.0/24 via 192.168.20.150 dev eth0  proto static
> src 192.168.20.150 table 220
>
> 2) 172.16.1.0/24 doesn't reach server A.
> SOLUTION:
> ip route add 172.16.1.0/24 via 172.16.1.1 dev eth1  proto static  src
> 172.16.1.1 table 220
>
> 3) 172.16.1.0/24 doesn't reach server B.
> SOLUTION:
> (ip route add 172.16.1.0/24 via 172.16.1.1 dev eth1  proto static  src
> 172.16.1.1 table 220)
> ip xfrm policy add src 172.16.1.0/24 dst 172.16.1.0/24 dir in
> ip xfrm policy add src 172.16.1.0/24 dst 172.16.1.0/24 dir out
>
> 4) Server B tries to surf the net with the local ip (172.16.1.1) instead
> of the public ip (2.118.245.45).
> SOLUTION:
> ip addr add 2.118.245.45/32 dev eth0
> ip route del default via 192.168.20.1 dev eth0  proto static  src
> 172.16.1.1 table 220
> ip route add default via 192.168.20.1 dev eth0  proto static  src
> 2.118.245.45 table 220
>
> Everything works as expected now, but I'd like to automate the
> additional rules when server B connects to the vpn.
>
> It should be possible to avoid at least the "ip xfrm policy" rules using
> a type=passthrough route in strongswan, but when I tried it didn't work.
> Does strongswan support type=passthrough with IKEv2?
> Also, what about the additional routes? How can I create them when
> establishing the vpn connection?
>
> I hope my efforts will help someone else because there isn't much
> documentation on the net.
>
> Cheers,
> Niccolò Belli
>

======================================================================
Andreas Steffen                         andreas.steffen at strongswan.org
strongSwan - the Linux VPN Solution!                www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==