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

Tue Oct 21 03:57:05 CEST 2014

Thanks for the quick reply. For now, we changed the nat.sh script to do what you wanted.  Where is this part of the configuration documented on the wiki?

We do see different behavior that seems to be a change in the right direction with your change.  However we still don't get a ping response.  The traces show that the ping destination now turns the VPN 10.3.0.2 destination into the real internet IP address.  We were also able to see the encapsulated traffic go out to the real IP for the phone.  However no response came back from the phone.  I suppose it's possible that IT is interfering with the traffic, but it seems odd that they are interfering with these encrypted packets.
BTW, they know we're doing IPSec VPN tunning because we told them we were.

We can ping using the real IP address, but we can't ping 10.3.0.2 from 10.1.0.10.  We should be able to do this, right?

Other interesting things to note:

We tried to ssh over the VPN from the phone and although the connection couldn't be established, we saw the traffic go from 10.3.0.2 to 10.1.0.1 to 10.1.0.10 and a response reach 10.1.0.1 and become an encapsulated packet destined for the phone's real internet IP address.  But doesn't get received by the phone.

We also took this configuration, unplugged from the wall (IT DMZ), and connected to a wireless router offering the same IP space as the IT DMZ. With your changes our application seems to work over this sandbox VPN, but we still can't ping from 10.1.0.1 to 10.3.0.2.  Shouldn't we be able to do that?  I could swear that our original sandbox configuration could successfully do this same ping.  :-/

Any thoughts on how we could provide you useful information to continue this debug?

Dan

Sent with Good (www.good.com)
________________________________
From: users-bounces at lists.strongswan.org <users-bounces at lists.strongswan.org> on behalf of Noel Kuntze <noel at familie-kuntze.de>
Sent: Monday, October 20, 2014 3:35:52 PM
To: users at lists.strongswan.org
Subject: Re: [strongSwan] Network Traffic Not Moving Between Left and Right...

-----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-----

_______________________________________________
Users mailing list
Users at lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20141021/f3e89312/attachment-0001.html>