3

I need to understand and resolve my issue. I know openswan works because when I connect from home network with an internal ip address of 10.0.0.97 to work's VPN, I'm able to ping but when I use the public xFinity wifi it indicates that the tunnel is up but I can't ping the internal hosts of my VPN.

When I'm successfully connected to the public Xfinity wifi, my IP is:

inet addr:10.232.204.146  Bcast:10.255.255.255  Mask:255.224.0.0

Here is route -n

root@ubuntu:/etc# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref      Use Iface
0.0.0.0         10.224.0.1      0.0.0.0         UG    0      0        0 wlan0
0.0.0.0         10.224.0.1      0.0.0.0         UG    0      0        0 wlan0
10.224.0.0      0.0.0.0         255.224.0.0     U     9      0        0 wlan0

When I"m at this point, I can ping and browse the internet fine.

When I start ipsec/openswan. I get.

root@ubuntu:/etc# /etc/init.d/ipsec status
IPsec running  - pluto pid: 4483
pluto pid 4483
1 tunnels up

But I can't ping my internal servers that have 192.168.1.xxx IPs.

Here is my ipsec.conf

    config setup

    dumpdir=/var/run/pluto/
    #
    # NAT-TRAVERSAL support, see README.NAT-Traversal
    #        nat_traversal=yes
    # exclude networks used on server side by adding %v4:!a.b.c.0/24
    # It seems that T-Mobile in the US and Rogers/Fido in Canada are
    # using 25/8 as "private" address space on their 3G network.
    # This range has not been announced via BGP (at least upto 2010-12-21)
    virtual_private=%v4:10.0.0.0/8,%v4:192.168.1.0/24,%v4:172.16.0.0/12,%v4:25.0.0.0/8,%v6:fd00::/8,%v6:fe80::/10
    # OE is now off by default. Uncomment and change to on, to enable.
    oe=off
    # which IPsec stack to use. auto will try netkey, then klips then mast
    #protostack=netkey
    # Use this to log to a file, or disable logging on embedded systems (like openwrt)
    plutostderrlog=/var/log/pluto
    plutodebug="all"
    protostack=netkey

    conn work
    authby=secret
    auto=start
    type=tunnel
    left=10.232.204.146
    leftsubnet=10.0.0.0/8
    right=99.xx.xx.xx
    rightsubnet=192.168.1.0/24
    ike=aes256-sha1,aes128-sha1,3des-sha1
    leftxauthusername=xxxxx

Here is my ipsec.secrets

@massivedude : XAUTH  "password"
10.232.204.146   vpnserver-01   : PSK "YouWillNeverKnow"

By the way, even though the tunnel is up and I can't ping internal hosts, I can still ping yahoo.com and google.com

Any help will be appreciated.

4
  • What device is on the other end of the tunnel, and what is its configuration?
    – EEAA
    Commented Dec 28, 2016 at 19:23
  • It's a ZyWall 110 FW/VPN Server. It's IPSEC section is configured to aes256-sha1
    – BioRod
    Commented Dec 28, 2016 at 19:28
  • After establishing the tunnel, what is your route -n? Also, it's been a loooong time since I've set up a *swan connection, but since Comcast is using "carrier grade" NAT, I think you need to uncomment that "nat_traversal = yes" when using their 10.0.0.0/8 network.
    – DerfK
    Commented Dec 28, 2016 at 19:41
  • @DerfK nat_traversal = yes worked. Can you post this as an answer so I can give you credit.
    – BioRod
    Commented Dec 28, 2016 at 20:03

1 Answer 1

3

Because Comcast uses NAT for their entire network (your 10.0.0.0/8 address here) you will need to enable nat_traversal for this connection when using Comcast.

The reason for this is because IPSEC packets include a hash of the entire packet including the source address. But NAT changes the source address from 10.232.204.146 to some public IP you don't know, so now the hash no longer matches the packet, and the other end will discard the packet because it has been tampered with (likewise packets from the other end will have the destination address changed from whatever public IP to 10.232.204.146 and get discarded).

NAT Traversal changes how the packets are sent. Instead of sending the packet directly, the encrypted packet is wrapped inside a regular UDP packet which is not hashed. NAT can then change the IP addresses on the UDP packet to ensure it gets to where it needs to go, while the original encrypted packet is unchanged and can still be validated.

I believe there is additional overhead in wrapping packets like this, so it is best to only turn it on when necessary.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .