<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>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?<br>
<br>
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. <br>
BTW, they know we're doing IPSec VPN tunning because we told them we were.<br>
<br>
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?<br>
<br>
Other interesting things to note:<br>
<br>
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.<br>
<br>
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. :-/<br>
<br>
Any thoughts on how we could provide you useful information to continue this debug?<br>
<br>
Dan<br>
<br>
<br>
<br>
Sent with Good (www.good.com)<br>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> users-bounces@lists.strongswan.org <users-bounces@lists.strongswan.org> on behalf of Noel Kuntze <noel@familie-kuntze.de><br>
<b>Sent:</b> Monday, October 20, 2014 3:35:52 PM<br>
<b>To:</b> users@lists.strongswan.org<br>
<b>Subject:</b> Re: [strongSwan] Network Traffic Not Moving Between Left and Right...</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
Hello Daniel,<br>
<br>
You need to except traffic that is going to be encapsulated from NAT.<br>
Change "iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE"<br>
to "iptables -t nat -A POSTROUTING -o eth0 -m policy --pol none --dir out -j MASQUERADE"<br>
<br>
Also, don't use bash scripts to configure your firewall. Use iptables-restore and iptables-save.<br>
To configure kernel settings, use sysctl and adjust or create new files /etc/sysctl.d/ or /etc/sysctl.conf.<br>
<br>
Mit freundlichen Grüßen/Regards,<br>
Noel Kuntze<br>
<br>
GPG Key ID: 0x63EC6658<br>
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658<br>
<br>
Am 20.10.2014 um 21:24 schrieb Levine, Daniel J.:<br>
><br>
> Hi,<br>
><br>
> <br>
><br>
> 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:
<a href="http://www.foteviken.de/?p=2175">http://www.foteviken.de/?p=2175</a><br>
><br>
> <br>
><br>
> #!/bin/bash<br>
><br>
> <br>
><br>
> iptables -F<br>
><br>
> iptables -t nat -F<br>
><br>
> iptables -t mangle -F<br>
><br>
> <br>
><br>
> iptables -X<br>
><br>
> iptables -t nat -X<br>
><br>
> iptables -t mangle -X<br>
><br>
> <br>
><br>
> echo "1" > /proc/sys/net/ipv4/ip_forward<br>
><br>
> <br>
><br>
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE<br>
><br>
> <br>
><br>
> 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:<br>
><br>
> <br>
><br>
> Udp/4500<br>
><br>
> Udp/500<br>
><br>
> Protocol/50<br>
><br>
> Protocol/51<br>
><br>
> <br>
><br>
> 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…<br>
><br>
> <br>
><br>
> 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:<br>
><br>
> <br>
><br>
> 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<br>
><br>
> 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<br>
><br>
> 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<br>
><br>
> 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<br>
><br>
> 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<br>
><br>
> 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<br>
><br>
> <br>
><br>
> We get no response to the ping. This works in our sandbox implementation.<br>
><br>
> <br>
><br>
> 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.<br>
><br>
> <br>
><br>
> Running route route in both configurations shows what we’d expect with the expected differences because of the different DMZ side.<br>
><br>
> <br>
><br>
> 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).<br>
><br>
> <br>
><br>
> How does one debug this?<br>
><br>
> <br>
><br>
> I can provide more output and configuration information, if necessary. But we are using the mentioned configuration on the StrongSwan server pretty much verbatim.<br>
><br>
> <br>
><br>
> Thanks for your help!<br>
><br>
> <br>
><br>
> Dan<br>
><br>
><br>
><br>
> _______________________________________________<br>
> Users mailing list<br>
> Users@lists.strongswan.org<br>
> <a href="https://lists.strongswan.org/mailman/listinfo/users">https://lists.strongswan.org/mailman/listinfo/users</a><br>
<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2<br>
<br>
iQIcBAEBCAAGBQJURWQYAAoJEDg5KY9j7GZY67gP/ROPlBH46n44SMGgAPkvrrzC<br>
PpIjCsSlO2YxKJQATa7Wx8ZPFF5w6e14WLyPQdJ6I+nfiOKS1SRIqYDx2D47elN3<br>
proiYySfVr54kT8kpUHWkt+4Ve2u/Z7XTAxq9Wsg+JktCHntCpYxjU49qz9sA2l4<br>
4Jp/De9CQEz/8ALYMWep2SCxPZIMA1uMivHTBS9YY374cWiuRicmVa7i+r2qJJTk<br>
4iIJ1a9LrVxK2UZht82v8hCEYaw/hKXz4Klhi93Itb7Ag9F8FlooHhQEKx3WjIoz<br>
AdiSFrEBn1eJABo4q4GaJKm/w7gUd8jf8ZJPnwWODEBWHAlWgljpU5PBS8yej1+X<br>
DTOm0kZGgNgz9xdw1Uyy9q/oQ6nalsnFIWgnlNof5qn6nTVuWN8YhD+/TXU0nkVk<br>
PfzkzA8LtF0Bz0U24jMkdbfk1Y+sALJCS1Kj57Ako0ETCrHu58iSc7qjqyP5LcWx<br>
JWj50RxfN0WdDIlomUJXzkbCtSdwJ/xnRFWho1VRk1gemx08wYDTTlkbIm4+pji/<br>
esibUsTzl23RyU8mlojZBdX2O75j7z3ORSM8q0HxDh6otxIIZUga+i1yAAcLD1/c<br>
kuxh/Usm82UcrJKojzklPSWxU485zhZB/D6uYj9MY9dCyNnYZQzfinCq6tdsye98<br>
dUtoNOFVGTbToWPLwk0e<br>
=s0DD<br>
-----END PGP SIGNATURE-----<br>
<br>
_______________________________________________<br>
Users mailing list<br>
Users@lists.strongswan.org<br>
<a href="https://lists.strongswan.org/mailman/listinfo/users">https://lists.strongswan.org/mailman/listinfo/users</a></div>
</span></font>
</body>
</html>