Openswan tunnel up, but works only in one direction

Question

I've successfully established an IPsec connection, but it works only partially. One side does not send out packets through the tunnel. It seems as if the network topology is unclear to this side.

Any help is highly appreciated! Thanks!!

This is the network scheme:

"office"(192.168.73.0/24) == "vpn"(192.168.73.1) == "router"(6.6.6.6) <====> "server"(7.7.7.7) == "VM_LAN"(192.168.133.0/24)

6.6.6.6 and 7.7.7.7 are symbolic public IPs, i.e. "router" and "server" both are directly connected to the internet.

"vpn" and "server" both run CentOS 6. "router" is a cable modem, doing the NAT and port forwarding.

The connection is established.

On "vpn" I can ping "server"'s internal IP:

[root@vpn]# ping 192.168.133.1
PING 192.168.133.1 (192.168.133.1) 56(84) bytes of data.
64 bytes from 192.168.133.1: icmp_seq=1 ttl=64 time=74.8 ms

On "server" I can't ping "vpn", there's not even a packet sent out.

The following is a dump from "server" showing above ping packet coming in. I use the same command to test if packets are sent from "server" to "vpn", when pinging from "server", but no packets show up.

[root@server]# tcpdump port 500 or port 4500
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:40:21.793577 IP 6.6.6.6.ipsec-nat-t > 7.7.7.7.ipsec-nat-t: UDP-encap: ESP(spi=0x712a1d37,seq=0x2), length 132
14:40:21.793650 IP 7.7.7.7.ipsec-nat-t > 6.6.6.6.ipsec-nat-t: UDP-encap: ESP(spi=0x840e6b76,seq=0x2), length 132

ipsec verify seems ok:

[root@server]# ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.32/K2.6.32-358.2.1.el6.x86_64 (netkey)
Checking for IPsec support in kernel                            [OK]
 SAref kernel support                                           [N/A]
 NETKEY:  Testing for disabled ICMP send_redirects              [OK]
NETKEY detected, testing for disabled ICMP accept_redirects     [OK]
Checking that pluto is running                                  [OK]
 Pluto listening for IKE on udp 500                             [OK]
 Pluto listening for NAT-T on udp 4500                          [OK]
Checking for 'ip' command                                       [OK]
Checking /bin/sh is not /bin/dash                               [OK]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]

iptables is disabled:

[root@server]# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination


[root@server]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
7.7.7.7         0.0.0.0         255.255.255.255 UH    0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
0.0.0.0         7.7.7.1         0.0.0.0         UG    0      0        0 eth0

My ipsec.conf:

config setup
    # Debug-logging controls:  "none" for (almost) none, "all" for lots.
    # klipsdebug=none
    # plutodebug="control parsing"
     plutodebug="all"
    # For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
    protostack=netkey
    nat_traversal=yes
    virtual_private="%v4:192.168.73.0/24"
    oe=off
    # Enable this if you see "failed to find any available worker"
    # nhelpers=0

conn aaa-office
    authby=secret
    left=7.7.7.7
    leftsubnet=192.168.133.0/24
    right=6.6.6.6
    rightsubnet=192.168.73.0/24
    rightid=192.168.73.8
    auto=add

Solution 1

I'll answer myself and hope that this info will be usable for others with the same issue.

The root cause was that packets from "server" weren't routed through the tunnel. Using ip xfrm policy I could see that the policy for routing through the tunnel is that packets need to origin from 192.168.133.0/24.

A ping from "server" to "vpn" resulted in these packets though:

17:29:16.549349 IP 7.7.7.7 > 192.168.73.8: ICMP echo request, id 43864, seq 1, length 64

So when doing the ping, the source IP naturally used was the public IP of the server. This wasn't the case for the "vpn" machine, since this machine was already in the subnet. The issue resolved when I added following statement to the configuration file of "server":

leftsourceip=192.168.133.1

Now things work as expected and I can reach the subnet behind "vpn" from "server".

Solution 2

I don't know openswan, but: in a VPN tunnel, make sure you have a either a route based VPN or policy based. ie. if it is based on a route, there should be a route that says "takes this tunnel interface to get to 192.168.73.1's network". If it is policy based then there should be a policy that says "source traffic from x sent to destination y = tunnel across VPN tunnel"

Sorry...removed a lot...poor reading comprehension...I see the info on your server's LAN interface/IP now and realize that you are trying to ping from that source IP of 192.168.133.1.

I would still verify that a policy or route in openswan is set on the server's side for the 192.168.133.0/24 traffic source destined for 192.168.73.0/24 and make sure it uses the tunnel. It looks like that traffic isn't using the Tunnel but instead doing something like:

192.168.133.1 -- - trying to ping 192.168.73.1 (which would fail)

Comments

[Hauke Laging]

What is the output of ip addr, ip route and iptables -L OUTPUT -n on server?

[Hauke Laging]

IMHO the last sentence ("Instead, the 7.7.7.7 probably ends up getting NAT'd out the default outside interface to the internet and therefore can't ping/find 192.168.73.2.") doesn't make sense. Why should you route a public IP through a VPN? pinging 192.168.73.2 does certainly not fail because 7.7.7.7 is reached without the tunnel.

[kralyk]

Ah...true didn't notice that was the public IP. So no NAT, but it still won't ping 192.168.73.2 directly...I'll update my answer.