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