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
