routing linux-networking ipsec strongswan – Fix IPsec Tunnel Established But No Traffic or Ping

ipseclinux-networkingroutingstrongswan

I have already searched for hours on this and many other sites and even though people have had similar issues, I haven't found one that can fix my problem.

I am trying to configure an IPsec tunnel from my computer to a virtual machine on a server using strongswan (by swanctl.conf). I have previously made the IPsec connection but from another device. I am using the same configuration (swanctl.conf)
but something else does not seem to fit. My machine (10.3.72.29) gets a virtual ip (172.13.14.2) and establishes a connection to the server's device (10.3.218.62) with its own virtual ip (192.168.122.2)

My current configuration:

My PC (Initiator) swanctl.conf:

connections {
   ch_vti0 {
      send_cert = always
      encap = yes
      vips = 0.0.0.0
      remote_addrs = 10.3.218.62
      local {
         round = 1
         id = 10.3.72.29
         auth = psk
         certs = 
       }
      remote {
         auth = psk
         id = 10.3.218.62
         certs = 
       }
      children {
        ch_vti0 { 
            mark_in = 42 
            mark_out = 42 
            remote_ts = 192.168.122.2/24
            local_ts = dynamic
            inactivity = 300s
            mode = tunnel
            esp_proposals =  3des-sha1-modp2048
            updown = /usr/local/etc/swanctl/updown.sh 0
         }
      }
      version = 1 
      proposals =  des-md5-modp768, des-md5-modp1024, des-md5-modp1536
   }  }
secrets {
        eap-xauth {
        eap_id = test1
        id = test1
        secret = password
   }
        xauth-local {
        id = test1
        secret = password
        }
        ike-sec {
        id = %any
        secret = test
        }
        ike-local {
        id = 10.3.72.29
        secret = test
        }
}

The server's virtual machine swanctl.conf:

connections {
   ch_vti0 {
      send_cert = always
      encap = yes
      pools = pools_users
      #aggressive = yes
      local {
         round = 1
         id = 10.3.218.62
         auth = psk
         certs = 
       }
      remote {
         auth = psk
         id = %any
         certs = 
       }
      children {
        ch_vti0 { 
            local_ts = 192.168.122.2/24
            inactivity = 120s
            mode = tunnel
            esp_proposals =  3des-sha1-modp2048
            updown = /usr/local/libexec/ipsec/_updown iptables
         }
      }
      version = 0
      proposals =  des-md5-modp768, des-md5-modp1024, des-md5-modp1536
   }  }
pools {
        pools_users {
                addrs = 172.13.14.2/24
        }
}
secrets {
        eap-xauth {
        eap_id = test1
        id = test1
        secret = password
   }
        xauth-local {
        id = test1
        secret = password
        }
        ike-sec {
        id = %any
        secret = test
        }
        ike-local {
        id = 10.3.218.62
        secret = test
        }
}

If anyone is wondering the updown.sh script creates the vti0 interface and routes

Result from ipsec statusall on my PC:

Listening IP addresses:
  10.3.72.29
  fdc8:c2cb:4586:cc11::8f00:5a9
  172.13.14.2
Connections:
     ch_vti0:  %any...10.3.218.62  IKEv1
     ch_vti0:   local:  [10.3.72.29] uses pre-shared key authentication
     ch_vti0:   remote: [10.3.218.62] uses pre-shared key authentication
     ch_vti0:   child:  dynamic === 192.168.122.0/24 TUNNEL
Security Associations (1 up, 0 connecting):
     ch_vti0[1]: ESTABLISHED 13 minutes ago, 10.3.72.29[10.3.72.29]...10.3.218.62[10.3.218.62]
     ch_vti0[1]: IKEv1 SPIs: 7fa996a60f87e923_i* 4faa8dbdd74a5927_r, rekeying in 3 hours
     ch_vti0[1]: IKE proposal: DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_768
     ch_vti0{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c393a4bb_i c392a387_o
     ch_vti0{1}:  3DES_CBC/HMAC_SHA1_96/MODP_2048, 65772 bytes_i (783 pkts, 0s ago), 0 bytes_o, rekeying in 42 minutes
     ch_vti0{1}:   172.13.14.2/32 === 192.168.122.0/24

Server's device:

Listening IP addresses:
  192.168.122.2
  10.3.218.62
  fdc8:c2cb:4586:cc12::e49c:faf8
Connections:
     ch_vti0:  %any...%any  IKEv1/2
     ch_vti0:   local:  [10.3.218.62] uses pre-shared key authentication
     ch_vti0:   remote: [%any] uses pre-shared key authentication
     ch_vti0:   child:  192.168.122.0/24 === dynamic TUNNEL
Security Associations (1 up, 0 connecting):
     ch_vti0[1]: ESTABLISHED 14 minutes ago, 10.3.218.62[10.3.218.62]...10.3.72.29[10.3.72.29]
     ch_vti0[1]: IKEv1 SPIs: 7fa996a60f87e923_i 4faa8dbdd74a5927_r*, rekeying in 3 hours
     ch_vti0[1]: IKE proposal: DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_768
     ch_vti0{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c392a387_i c393a4bb_o
     ch_vti0{1}:  3DES_CBC/HMAC_SHA1_96/MODP_2048, 0 bytes_i, 68880 bytes_o (820 pkts, 0s ago), rekeying in 44 minutes
     ch_vti0{1}:   192.168.122.0/24 === 172.13.14.2/32

Routes on my pc:

root@malz:/usr/local/etc/swanctl# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.3.127.1      0.0.0.0         UG    100    0        0 enp2s0
10.3.0.0        0.0.0.0         255.255.0.0     U     100    0        0 enp2s0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 vti0

Routes on server's device:

root@server-automation-2:/etc/swanctl# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.3.127.1      0.0.0.0         UG    0      0        0 ens4
10.3.0.0        0.0.0.0         255.255.0.0     U     0      0        0 ens4
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 ens3

I have allowed the ports that IPsec uses(500,4500,4500/udp,500/udp), tried disabling the firewalls on both of them, Cleared the iptables and allowed everything:

iptables -F
iptables -I INPUT -j ACCEPT
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

I have also checked the sysctl parameters for droping packets (especially those about icmp requests)

If I try to catch the packets with tcpdump
I can see I do receive them from the server's device (ping icmp packets)
but my PC doesn't respond

If I try to send packets the server's device doesn't catch them and my PC's IPsec interface TX error packets increase.
From ifconfig:

vti0: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1480
        inet 172.13.14.2  netmask 255.255.255.255  destination 172.13.14.2
        inet6 fe80::5efe:a03:481d  prefixlen 64  scopeid 0x20<link>
        tunnel   txqueuelen 1000  (IPIP Tunnel)
        RX packets 1063  bytes 89292 (89.2 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 57  dropped 0 overruns 0  carrier 57  collisions 0

In conclusion, I have set up the ipsec connection between the two machines but I can't figure out why one of them can't transmit packages and doesn't respond to the others pings.
I am fairly certain the cause of all this isn't the ipsec configuration, because I have already previously mentioned I have tested it before and it works with the exact same conf file (excluding changing ips)

If anyone can give me even a hint I would really appreciate it.

Best Answer

Steps of troubleshooting (from bottom to top):

Run the tcpdump. You should see clear and encrypted packets (ESP).
Check the ip connectivity between ends of the ipsec tunnel.
Check the routing. By default the strongswan install the additional routes into a separate routing table. Run ip -4 r ls table 220. Investigate the output. To check the actual routes use the ip route get <dst> command. Don't use the route -n command - it returns the uncompleted view.
Check the output of ip -s -s xfrm state list and ip -s -s -d xfrm policy list. It shows the system SADB (Security Associations Data Base) and policy DB. Your vti interface has some carrier errors. Carrier error on the vti interface means:
- no suitable ipsec policy has found. Check the ip x p get ... command.
- no suitable route has found. Check the ip route get ... command.
- no suitable SA has found. Check the ip x s ls command.
Check the firewall. The iptables command by default works with the filter table, but there are other tables (raw, nat, mangle). Better use the iptables-save -c command to list the full rule set. After the changing of the nat rules clear the conntrack table with the conntrack -F command. The ipsec traffic passes the firewall chains twice: one pass as encrypted, other pass as clear. So investigate the rules. Also you can insert the NFLOG target rules to capture the traffic with tcpdump -ni nflog... command.

Related Solutions

Linux – Configure ipsec vpn tunnel (network to network with IKE with preshared key) on Centos 6 with openswan

To do it with OpenS/WAN, you want something like this in /etc/ipsec.conf:

conn linksys-1
        # Left endpoint, subnet behind it, next hop toward right
        keyingtries=0
        left=a.b.c.4
        leftsubnet=a.b.c.4/32
        leftnexthop=%defaultroute
        # Right endpoint, subnet behind it, next hop toward left
        right=d.168.1.67
        rightsubnet=e.199.1.0/24
        type=tunnel
        authby=secret
        #auth=esp
        keylife=59m
        ikelifetime=59m
        #esp=3des-md5-96
        pfs=no
        #compress=no
        #keyexchange=ike
        auto=start

and something like this in /etc/ipsec.secrets:

a.b.c.4 d.168.1.67: PSK "secret-goes-here"

This is assuming that the exterior ip address of the linksys is d.168.1.67, that the network behind it is e.199.1.0/24, that the public ip address of the C6 system is a.b.c.4, and that it only wants itself routed down the tunnel.

Don't forget not to make the elementary mistake of testing the tunnel by pinging the linksys from the C6 system. The linksys itself is not included in the tunnel; only traffic to hosts inside the e.199.1.0/24 network will be properly encrypted and tunneled.

This isn't supposed to be a complete guide, but hopefully it gives you a point from which to start that's a little further on than a blank canvas.

Edit: why did you show the linksys config if you want to connect the C6 box to the checkpoint one? Do you want to replace the linksys with the C6 box? If so, then what I wrote still applies, just substitute the IP addresses accordingly; essentially, left is your IP address, leftsubnet is the network at your end (probably just the same thing again, with a /32 appended), right is the far end's address, and rightsubnet is the far end's routed (often private) netblock. The two addresses, left and right, must appear in the ipsec.secrets file.

If you're not replacing the linksys but configuring the C6 box in addition, you will also need to reconfigure the checkpoint box, and that's beyond the scope of this answer.

PfSense/strongSwan “deleting half open IKE_SA after timeout” – IPSec connection Android 4.4 to pfSense 2.2.1 fails

I've been having this exact same issue.

As per this [IKEv1 can't connect from Android's default vpn client], there is a bug in the current Android VPN IKEv1 client that happens if aggressive mode is selected and a "IPsec identifier" is used to configure the Android client.

The solution is to clear the "IPsec identifier" entry from the android client and in Phase 1 proposal the negotiation mode should be Main.

In my setup the Phase 1 proposal (Authentication) : Authentication method is Mutual PSK + Xauth and not just Mutual PSK.

Best Answer

Related Solutions

Linux – Configure ipsec vpn tunnel (network to network with IKE with preshared key) on Centos 6 with openswan

PfSense/strongSwan “deleting half open IKE_SA after timeout” – IPSec connection Android 4.4 to pfSense 2.2.1 fails

Related Topic