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

[Niccolò Belli]

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