IPSEC Tunnel with OpenSwan on Ubuntu <-> CISCO Router

Question

I have setup a tunnel between a UBUNTU SERVER linux box and a CISCO ROUTER.

This is what's the topology looks like:

host 1 ------ UBUNTU SERVER IPSEC <---> CISCO ROUTER ------ host 2
   |                    |                      |               |
   |                    |                      |               |
192.168.64.0/24      1.2.3.4                4.3.2.1      10.10.20.0/24

Here's my problem: the tunnel is setup and running correctly. I can definitely ping from the CISCO ROUTER to any host on the 192.168.64.0/24 network. But I can not ping from the 192.168.64.0/24 network to any host on the 10.10.20.0/24 network.

Here's some info:

ipsec.conf:

conn my_vpn
auto=start
authby=secret
ike=aes256-md5
phase2=esp
phase2alg=aes256-md5
type=tunnel
left=1.2.3.4
leftsubnet=192.168.64.0/24
    leftnexthop=%defaultroute
leftupdown="ipsec _updown --route yes"
keyingtries=3
keyexchange=ike
pfs=no
    right=4.3.2.1
    rightsubnet=10.10.20.0/24   

ipsec look command output:

XFRM state:
src 4.3.2.1 dst 1.2.3.4
    proto esp spi 0x0f9898dd reqid 16385 mode tunnel
    replay-window 32 flag af-unspec
    auth-trunc hmac(md5) 0xSOMEVALUE
    enc cbc(aes) 0xSOMEOHTERVALUE
src 1.2.3.4 dst 4.3.2.1
    proto esp spi 0x667b62d8 reqid 16385 mode tunnel
    replay-window 32 flag af-unspec
    auth-trunc hmac(md5) 0xSOMEVALUE
    enc cbc(aes) 0xSOMEOHTERVALUE
XFRM policy:
src 192.168.64.0/24 dst 10.10.20.0/24 
    dir out priority 2344 
    tmpl src 1.2.3.4 dst 4.3.2.1
        proto esp reqid 16385 mode tunnel
src 10.10.20.0/24 dst 192.168.64.0/24 
    dir fwd priority 2344 
    tmpl src 4.3.2.1 dst 1.2.3.4
        proto esp reqid 16385 mode tunnel
src 10.10.20.0/24 dst 192.168.64.0/24 
    dir in priority 2344 
    tmpl src 4.3.2.1 dst 1.2.3.4
        proto esp reqid 16385 mode tunnel
src ::/0 dst ::/0 
    socket out priority 0 
src ::/0 dst ::/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
XFRM done
IPSEC mangle TABLES
iptables: No chain/target/match by that name.
ip6tables: No chain/target/match by that name.
NEW_IPSEC_CONN mangle TABLES
iptables: No chain/target/match by that name.
ip6tables: No chain/target/match by that name.
ROUTING TABLES
default dev ppp0  scope link 
10.10.20.0/24 via 1.2.3.GW dev ppp0 
1.2.3.GW dev ppp0  proto kernel  scope link  src 1.2.3.4

Where 1.2.3.GW is 1.2.3.4's gateway.

ipsec verify command output:

Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.37/K3.2.0-38-generic-pae (netkey)
Checking for IPsec support in kernel                            [OK]
 SAref kernel support                                           [N/A]
 NETKEY:  Testing XFRM related proc values                      [OK]
    [OK]
    [OK]
Checking that pluto is running                                  [OK]
 Pluto listening for IKE on udp 500                             [OK]
 Pluto listening for NAT-T on udp 4500                          [FAILED]
Two or more interfaces found, checking IP forwarding            [FAILED]
Checking NAT and MASQUERADEing                                  [OK]
Checking for 'ip' command                                       [OK]
Checking /bin/sh is not /bin/dash                               [WARNING]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]

I must add: UBUNTU has a ppp0 connection which has its public IP address: 1.2.3.4.

Static route information:

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 ppp0
10.10.20.0      1.2.3.GW        255.255.255.0   UG        0 0          0 ppp0

Any ideas?

Solution

I have had this problem before -- and if your tunnel is up correctly and the Cisco side is pinging through into the 192.168 network, it means your tunnel is up and passing traffic.

If you can't ping back to the Cisco or the 10.10 segment, the problem is not the tunnel.

The problem is -- most likely -- that you are using the Ubuntu box as your firewall for the 192.168 to get to the internet, and as such iptables is set to masquerade network traffic.

The default setup would be something like the following nat rule, assuming eth1 is the public interface:

iptables -A POSTROUTING -o eth1 -j MASQUERADE

The problem is, ipsec traffic also goes out eth1, so you try to masquerade that as well.

Insert a rule before the masquerade rule, specifying that ipsec traffic should not be masqueraded but simply accepted, and strongswan will do the rest:

iptables -I POSTROUTING 1 -d 10.10.20.0/24 -o eth1 -j ACCEPT

so running iptables -L -v -n -t nat should give you the following:

Chain PREROUTING (policy ACCEPT 8875K packets, 566M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 4898K packets, 325M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 1089K packets, 82M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 1412 packets, 119K bytes)
 pkts bytes target     prot opt in     out     source               destination
    4   336 ACCEPT     all  --  *      eth1    0.0.0.0/0            10.10.20.0/24
 101M 6481M MASQUERADE  all  --  *      eth1    0.0.0.0/0            0.0.0.0/0

Notice the accept line precedes the masquerade line -- it matches first and the packets will not be altered.

Comments

[Jason1891]

if you traceroute from the 192.168 sub to the 10.10 where does it die?

[maths]

It dies after two hops. On my ISP. I don't know if traffic is actually being routed through the tunnel. Don't know how to check that either.

[Jason1891]

I feel like we're missing a route to the 10.10 subnet, can you confirm static routes?

[maths]

updated the question with static route information.