[strongSwan] Network Traffic Not Moving Between Left and Right...

Mon Oct 20 21:35:52 CEST 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello Daniel,

You need to except traffic that is going to be encapsulated from NAT.
Change "iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE"
to            "iptables -t nat -A POSTROUTING -o eth0 -m policy --pol none --dir out -j MASQUERADE"

Also, don't use bash scripts to configure your firewall. Use iptables-restore and iptables-save.
To configure kernel settings, use sysctl and adjust or create new files /etc/sysctl.d/ or /etc/sysctl.conf.

Mit freundlichen Grüßen/Regards,
Noel Kuntze

GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Am 20.10.2014 um 21:24 schrieb Levine, Daniel J.:
>
> Hi,
>
> 
>
> I have a successful implementation of ikev2/rw-eap-peap-mschapv2 implemented (10.2.0.0 is remote network, 10.1.0.0 is local network, 10.3.0.0 is VPN tunnel network) in a sandbox with a wireless router acting as a stand-in for the “internet” and my road-warrior devices are Android phones running the StrongSwan client.  The only thing we needed to really do to get it working was to run the nat.sh script found here: http://www.foteviken.de/?p=2175
>
> 
>
> #!/bin/bash
>
> 
>
> iptables -F
>
> iptables -t nat -F
>
> iptables -t mangle -F
>
> 
>
> iptables -X
>
> iptables -t nat -X
>
> iptables -t mangle -X
>
> 
>
> echo "1" > /proc/sys/net/ipv4/ip_forward
>
> 
>
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
>
> 
>
> So things were working great in our little sandbox environment.  So then we decided to move out to a bigger network.  We got our IT people to hook the StrongSwan host up in our DMZ and allow the necessary traffic to and from it:
>
> 
>
> Udp/4500
>
> Udp/500
>
> Protocol/50
>
> Protocol/51
>
> 
>
> We needed to change our DMZ side Ethernet interface to use our statically assigned IP address and a netmask slightly different from what we had been using 255.255.255.128 (we were using 255.255.255.0).  We also changed the IP address in /etc/hosts of the StrongSwan host to the new DMZ IP address.  Finally, we changed the left= line in ipsec.conf to use the new DMZ static IP address.  We restarted the StrongSwan system.  Then we tried to connect with StrongSwan app on the Android devices from a public Wifi hotspot and it established the tunnel!  So far so good.  Here’s the rub…
>
> 
>
> If we try to ping the phones over the VPN tunnels (10.3.0.1 and 10.3.0.2) from the 10.1.0.0 network, the ping seems to get lost finding the way to 10.3.0.x and comes out in the clear to the DMZ firewall, which probably blocks it/throws it away, since it doesn’t know how to get to 10.3.0.x from there.  Our IT people verified that they see 10.3.0.1 traffic when we do these pings, which I assume they should never see, since it should be getting wrapped up into a nice encrypted packet destined for the phone’s more-real IP address.  I assume StrongSwan knows how to get the data there, since VPN connection stays established (verified using ipsec statusall).  We assumed something was somehow not right in iptables and decided to see if we could see what was going on in there, so we added 2 TRACE lines for raw.  When we do ping –c 1 10.3.0.2, here’s what we see in kernel.log:
>
> 
>
> Jan  1 14:34:29 sc-vpn kernel: [ 9159.661673] TRACE: raw:OUTPUT:policy:2 IN= OUT=eth0 SRC=10.1.0.1 DST=10.3.0.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=64500 DF PROTO=ICMP TYPE=8 CODE=0 ID=3530 SEQ=1 UID=0 GID=0
>
> Jan  1 14:34:29 sc-vpn kernel: [ 9159.661701] TRACE: mangle:OUTPUT:policy:1 IN= OUT=eth0 SRC=10.1.0.1 DST=10.3.0.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=64500 DF PROTO=ICMP TYPE=8 CODE=0 ID=3530 SEQ=1 UID=0 GID=0
>
> Jan  1 14:34:29 sc-vpn kernel: [ 9159.661716] TRACE: nat:OUTPUT:policy:1 IN= OUT=eth0 SRC=10.1.0.1 DST=10.3.0.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=64500 DF PROTO=ICMP TYPE=8 CODE=0 ID=3530 SEQ=1 UID=0 GID=0
>
> Jan  1 14:34:29 sc-vpn kernel: [ 9159.661732] TRACE: filter:OUTPUT:policy:1 IN= OUT=eth0 SRC=10.1.0.1 DST=10.3.0.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=64500 DF PROTO=ICMP TYPE=8 CODE=0 ID=3530 SEQ=1 UID=0 GID=0
>
> Jan  1 14:34:29 sc-vpn kernel: [ 9159.661744] TRACE: mangle:POSTROUTING:policy:1 IN= OUT=eth0 SRC=10.1.0.1 DST=10.3.0.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=64500 DF PROTO=ICMP TYPE=8 CODE=0 ID=3530 SEQ=1 UID=0 GID=0
>
> Jan  1 14:34:29 sc-vpn kernel: [ 9159.661755] TRACE: nat:POSTROUTING:rule:1 IN= OUT=eth0 SRC=10.1.0.1 DST=10.3.0.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=64500 DF PROTO=ICMP TYPE=8 CODE=0 ID=3530 SEQ=1 UID=0 GID=0
>
> 
>
> We get no response to the ping.  This works in our sandbox implementation.
>
> 
>
> I should add that we do see 2 iptables rules that StrongSwan inserts (and removes) when each the phone establishes (terminates) a tunnel connection accepting traffic between 10.3.0.1 and 10.1.0.1 and 10.1.0.1 and 10.3.0.1 (as well as the second phone 10.3.0.2 and 10.1.0.1 and 10.1.0.1 and 10.3.0.2).  I can’t recall at the moment if those appear as subnets or actual single IPs.
>
> 
>
> Running route route in both configurations shows what we’d expect with the expected differences because of the different DMZ side.
>
> 
>
> I’m at a loss as to why traffic doesn’t want to go over the VPN connection to the client or come off of it (I’ve tested that as well).
>
> 
>
> How does one debug this?
>
> 
>
> I can provide more output and configuration information, if necessary.  But we are using the mentioned configuration on the StrongSwan server pretty much verbatim.
>
> 
>
> Thanks for your help!
>
> 
>
> Dan
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJURWQYAAoJEDg5KY9j7GZY67gP/ROPlBH46n44SMGgAPkvrrzC
PpIjCsSlO2YxKJQATa7Wx8ZPFF5w6e14WLyPQdJ6I+nfiOKS1SRIqYDx2D47elN3
proiYySfVr54kT8kpUHWkt+4Ve2u/Z7XTAxq9Wsg+JktCHntCpYxjU49qz9sA2l4
4Jp/De9CQEz/8ALYMWep2SCxPZIMA1uMivHTBS9YY374cWiuRicmVa7i+r2qJJTk
4iIJ1a9LrVxK2UZht82v8hCEYaw/hKXz4Klhi93Itb7Ag9F8FlooHhQEKx3WjIoz
AdiSFrEBn1eJABo4q4GaJKm/w7gUd8jf8ZJPnwWODEBWHAlWgljpU5PBS8yej1+X
DTOm0kZGgNgz9xdw1Uyy9q/oQ6nalsnFIWgnlNof5qn6nTVuWN8YhD+/TXU0nkVk
PfzkzA8LtF0Bz0U24jMkdbfk1Y+sALJCS1Kj57Ako0ETCrHu58iSc7qjqyP5LcWx
JWj50RxfN0WdDIlomUJXzkbCtSdwJ/xnRFWho1VRk1gemx08wYDTTlkbIm4+pji/
esibUsTzl23RyU8mlojZBdX2O75j7z3ORSM8q0HxDh6otxIIZUga+i1yAAcLD1/c
kuxh/Usm82UcrJKojzklPSWxU485zhZB/D6uYj9MY9dCyNnYZQzfinCq6tdsye98
dUtoNOFVGTbToWPLwk0e
=s0DD
-----END PGP SIGNATURE-----