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: [email protected] <[email protected]> on behalf of Noel Kuntze <[email protected]> Sent: Monday, October 20, 2014 3:35:52 PM To: [email protected] 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 > [email protected] > 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 [email protected] https://lists.strongswan.org/mailman/listinfo/users
_______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
