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
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
