# strongSwan server with Windows 7 clients doesn't route traffic

I have a server running strongSwan on an Amazon EC2 instance that I want to connect to with Windows 7. The strongSwan server is on a private network (IP address 172.16.1.15 on the network 172.16.0.0/17) and has traffic forwarded to its private address from a public IP address - this is what Amazon calls "Elastic IP".

I want to assign the clients addresses from another private subnet - 10.127.0.0/22 - and route traffic between the two private subnets. Note that the 172.16.0.0/17 subnet is managed by Amazon, but the 10.127.0.0/22 subnet isn't managed by anything right now (other than my ipsec.conf).

My Windows clients do connect to the VPN, but cannot connect to any hosts on the private network. My theory is that it is related to a problem with either the client routing or a lack of some iptables invocation on the server, but I'm not very knowledgeable in either domain and I've gotten stuck.

• I have installed Ubuntu 12.04 and strongswan-ikev2 on the server.
• ipsec version reports Linux strongSwan U4.5.2/K3.2.0-52-virtual
• Note that both the client and server are behind NAT (the client because it is on a local office network, and the server because it is in Amazon's cloud). I have unblocked UDP ports 500 and 4500 in the Amazon dashboard, and on the client's firewall.
• I have enabled IPv4 forwarding on the server: echo 1 > /proc/sys/net/ipv4/ip_forward
• I have gone into Amazon's VPC administrative UI for the 172.16.0.0/17 subnet and allowed all traffic to/from the 10.127.0.0/23 subnet.
• This is /etc/ipsec.conf:

config setup
plutostart=no

conn %default
keyexchange=ikev2
dpdaction=clear
dpddelay=300s
rekey=no

conn dlpvpn
left=172.16.1.15
leftauth=pubkey
leftcert=openssl-cert.pem
leftid=vpn.example.com
leftsubnet=172.16.0.0/17
right=%any
rightsourceip=10.127.0.0/22
rightauth=eap-mschapv2
rightsendcert=never
eap_identity=%any

• This is /etc/ipsec.secrets:

: RSA openssl-key.rsa

• This is /etc/strongswan.conf:

charon {
dns1 = 172.16.3.246
}

• I want to use split tunneling - where only traffic for the private 172.16.0.0/17 network goes over the VPN, and traffic bound for the Internet uses the client's local gateway. To do this, I have unchecked "Use default gateway on remote network", and checked "Disable class based route addition" on the Windows client.

• The connection completes sucessfully. ipconfig /all shows:

PPP adapter strongswan:

Description . . . . . . . . . . . : strongswan
IPv4 Address. . . . . . . . . . . : 10.127.0.1(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . :
DNS Servers . . . . . . . . . . . : 172.16.3.246

• However, I can't ping any host on the 172.16.0.0/17 network. In fact, if I do an nslookup, it attempts to contact the DNS server I specified in strongswan.conf, but Wireshark on that DNS server shows that it received nothing. I can't even ping the 172.16.1.15 address of the strongSwan server itself.

• It's my understanding that route rules must be added manually on Windows. However, what do they need to be? The only answer that I could come up with was to try adding the route for the 172.16.0.0/17 network to use the VPN server's address as the gateway using the command route add 172.16.0.0/17 172.16.1.15 if 45. However, that didn't change anything - traffic from my VPN client did not make it to the 172.16.0.0/17 network.

I'd appreciate any help. Thanks.

-
You should definitely specify leftsubnet=172.16.0.0/17 otherwise no IPsec policy is installed and no traffic to that subnet is allowed (only 172.16.1.15 would be reachable, not sure why it doesn't in your case, perhaps a Windows issue). You could first try the default, i.e. leftsubnet=0.0.0.0/0, and then move to split tunneling later. –  ecdsa Sep 5 '13 at 9:21
Hmm, OK. I just tried setting it to 0.0.0.0/0 and that doesn't change the behavior at all. I also tried setting a route manually on the Windows client after changing that setting and restarting ipsec with route add 172.16.0.0 mask 255.255.254.0 172.16.1.15, which also resulted in no behavior change. –  Micah R Ledbetter Sep 5 '13 at 15:21

I finally have this working, thanks to help from @ecdsa here and some help from the #strongswan irc channel.

1. My VPN client's route rules were incomplete. I needed to add both of these rules:

route add 172.16.1.15/32 10.127.0.1

The first one adds a route for the VPN server's private IP address, specifying my client's VPN-assigned IP address as the gateway to it (route print will then display this as being on-link AKA local to that interface). The second one does what I was trying to do with the route rule in my question - it adds a route for the whole private network, specifying the VPN server as the gateway.
2. I needed to specify leftsubnet=172.16.0.0/17 on the server, or else IPsec policy wouldn't permit traffic to the subnet no matter what the routes were.
3. I needed to specify leftfirewall=yes on the server so that it would insert appropriate rules into iptables.