Strongswan forwarding traffic between two IPsec tunnels where one is a host

Question

I'm facing a similar question as described here, but the solution did not work in my scenario.

I have

a VPN server A with a static external IP address AA.AA.AA.AA, an internal IP of 192.168.1.1 and an internal subnet of 192.168.1.0/24
a VPN server B with a dynamic external IP address BB.BB.BB.BB, an internal IP of 192.168.2.254 and an internal subnet of 192.168.2.0/24
a mobile device with a dynamic external IP address MM.MM.MM.MM and an IP of 192.168.250.129 when connected to the VPN

Between A and B the two subnets are transparently routed over the VPN, which works fine.

The mobile device connects to A and receives an IP address from the 192.168.250.128/25 subnet. The mobile device can communicate fine with all devices on the 192.168.1.0/24 subnet (and the other way around as well), but not with any device from the 192.168.2.0/24.

On A, I can see the packets arriving:

hanjo@A:~$ sudo tcpdump -n net 192.168.250.128/25
19:28:31.367911 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 0, length 64
19:28:32.469991 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 1, length 64
19:28:33.410002 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 2, length 64
19:28:34.389997 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 3, length 64
19:28:35.449973 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 4, length 64

On B, no packets are captured.

Interestingly, sending data the other direction, i.e. from a host on the 192.168.2.0/24 subnet to the mobile device seems to be working better.

Capture from B:

hanjo@B:~$ sudo tcpdump -n net 192.168.250.0/24
20:44:27.201713 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 55134, seq 0, length 64
20:44:28.202222 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 55134, seq 1, length 64
20:44:29.202355 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 55134, seq 2, length 64
20:44:30.202603 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 55134, seq 3, length 64

Capture from A:

hanjo@A:~$ sudo tcpdump -n net 192.168.250.128/25
20:42:28.897441 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 39774, seq 0, length 64
20:42:28.897990 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 0, length 64
20:42:29.897510 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 39774, seq 1, length 64
20:42:29.897962 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 1, length 64
20:42:30.897469 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 39774, seq 2, length 64
20:42:30.897918 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 2, length 64
20:42:31.897458 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 39774, seq 3, length 64
20:42:31.897911 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 3, length 64

However, as you can see, no echo reply is received.

This is my Strongswan configuration:

A's ipsec.conf:

conn B-tunnel
    left=AA.AA.AA.AA
    leftid="@A"
    right=B.dyndns
    rightid="@B"
    leftsubnet=192.168.1.0/24,192.168.250.0/24
    rightsubnet=192.168.2.0/24
    keyexchange=ikev2
    type=tunnel
    authby=secret
    auto=route

conn rw-v2
    keyexchange=ikev2
    left=AA.AA.AA.AA
    leftid="@A"
    right=%any
    leftsubnet=192.168.1.0/24,192.168.2.0/24
    rightsourceip=192.168.250.128/25
    rightdns=192.168.1.1
    authby=secret

conn mobile
    also=rw-v2
    auto=add
    rightid="@mobile"

B's ipsec.conf:

conn A-tunnel
    left=192.168.2.254
    leftsubnet=192.168.2.0/24
    leftid=@B
    right=AA.AA.AA.AA
    rightsubnet=192.168.1.0/24,192.168.250.0/24
    rightid=@A
    authby=secret
    type=tunnel
    auto=start

Additional information from A:

hanjo@A:~$ sudo ipsec statusall
Status of IKE charon daemon (weakSwan 5.2.2, Linux 3.10.20, mips64):
  uptime: 7 hours, since Jan 08 14:50:14 2017
  malloc: sbrk 586896, mmap 0, used 376264, free 210632
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 44
  loaded plugins: charon ldap sqlite pkcs11 aes des sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs8 pem openssl agent xcbc cmac ctr ccm gcm curl attr kernel-netlink resolve socket-default stroke vici updown eap-identity eap-md5 eap-mschapv2 eap-radius eap-tls xauth-generic xauth-eap addrblock
Virtual IP pools (size/online/offline):
  192.168.250.128/25: 126/1/1
Listening IP addresses:
  AA.AA.AA.AA
  192.168.1.1
Connections:
B-tunnel:  AA.AA.AA.AA...B.dyndns  IKEv2, dpddelay=30s
B-tunnel:   local:  [A] uses pre-shared key authentication
B-tunnel:   remote: [B] uses pre-shared key authentication
B-tunnel:   child:  192.168.1.0/24 192.168.250.0/24 === 192.168.2.0/24 TUNNEL, dpdaction=restart
      mobile:  AA.AA.AA.AA...%any  IKEv2, dpddelay=15s
      mobile:   local:  [A] uses pre-shared key authentication
      mobile:   remote: [mobile] uses pre-shared key authentication
      mobile:   child:  192.168.1.0/24 192.168.2.0/24 === dynamic TUNNEL, dpdaction=clear
Routed Connections:
B-tunnel{5}:  ROUTED, TUNNEL
B-tunnel{5}:   192.168.1.0/24 192.168.250.0/24 === 192.168.2.0/24
Security Associations (6 up, 0 connecting):
      mobile[55]: ESTABLISHED 104 seconds ago, AA.AA.AA.AA[A]...MM.MM.MM.MM[mobile]
      mobile[55]: IKEv2 SPIs: 4dc26b00764d7fbf_i f00fd36247594b6a_r*, pre-shared key reauthentication in 106 minutes
      mobile[55]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
      mobile{36}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c1012a86_i 08a38525_o
      mobile{36}:  AES_CBC_256/HMAC_SHA1_96, 15163 bytes_i (100 pkts, 66s ago), 55569 bytes_o (78 pkts, 87s ago), rekeying in 44 minutes
      mobile{36}:   192.168.1.0/24 192.168.2.0/24 === 192.168.250.129/32
B-tunnel[19]: ESTABLISHED 6 hours ago, AA.AA.AA.AA[A]...BB.BB.BB.BB[B]
B-tunnel[19]: IKEv2 SPIs: 97ef622accd69b0a_i* b1cd574224dcba1c_r, rekeying in 80 minutes, pre-shared key reauthentication in 70 minutes
B-tunnel[19]: IKE proposal: AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_8192
B-tunnel{5}:  INSTALLED, TUNNEL, ESP in UDP SPIs: cbd873b7_i cebce241_o
B-tunnel{5}:  AES_CBC_256/HMAC_SHA2_512_256, 518363 bytes_i (3670 pkts, 0s ago), 274095 bytes_o (3733 pkts, 0s ago), rekeying in 21 minutes
B-tunnel{5}:   192.168.1.0/24 192.168.250.0/24 === 192.168.2.0/24

hanjo@A:~$ sudo ip xfrm policy
src 192.168.250.129/32 dst 192.168.2.0/24 
    dir fwd priority 2851 
    tmpl src MM.MM.MM.MM dst AA.AA.AA.AA
        proto esp reqid 36 mode tunnel
src 192.168.250.129/32 dst 192.168.2.0/24 
    dir in priority 2851 
    tmpl src MM.MM.MM.MM dst AA.AA.AA.AA
        proto esp reqid 36 mode tunnel
src 192.168.2.0/24 dst 192.168.250.129/32 
    dir out priority 2851 
    tmpl src AA.AA.AA.AA dst MM.MM.MM.MM
        proto esp reqid 36 mode tunnel
src 192.168.250.129/32 dst 192.168.1.0/24 
    dir fwd priority 2851 
    tmpl src MM.MM.MM.MM dst AA.AA.AA.AA
        proto esp reqid 36 mode tunnel
src 192.168.250.129/32 dst 192.168.1.0/24 
    dir in priority 2851 
    tmpl src MM.MM.MM.MM dst AA.AA.AA.AA
        proto esp reqid 36 mode tunnel
src 192.168.1.0/24 dst 192.168.250.129/32 
    dir out priority 2851 
    tmpl src AA.AA.AA.AA dst MM.MM.MM.MM
        proto esp reqid 36 mode tunnel
src 192.168.2.0/24 dst 192.168.250.0/24 
    dir fwd priority 2883 
    tmpl src BB.BB.BB.BB dst AA.AA.AA.AA
        proto esp reqid 5 mode tunnel
src 192.168.2.0/24 dst 192.168.250.0/24 
    dir in priority 2883 
    tmpl src BB.BB.BB.BB dst AA.AA.AA.AA
        proto esp reqid 5 mode tunnel
src 192.168.250.0/24 dst 192.168.2.0/24 
    dir out priority 2883 
    tmpl src AA.AA.AA.AA dst BB.BB.BB.BB
        proto esp reqid 5 mode tunnel
src 192.168.2.0/24 dst 192.168.1.0/24 
    dir fwd priority 2883 
    tmpl src BB.BB.BB.BB dst AA.AA.AA.AA
        proto esp reqid 5 mode tunnel
src 192.168.2.0/24 dst 192.168.1.0/24 
    dir in priority 2883 
    tmpl src BB.BB.BB.BB dst AA.AA.AA.AA
        proto esp reqid 5 mode tunnel
src 192.168.1.0/24 dst 192.168.2.0/24 
    dir out priority 2883 
    tmpl src AA.AA.AA.AA dst BB.BB.BB.BB
        proto esp reqid 5 mode tunnel
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 

hanjo@A:~$ sudo ip route
default via AA.AA.AA.1 dev eth0  proto zebra 
AA.AA.AA.0/30 dev eth0  proto kernel  scope link 
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.1 

hanjo@A:~$ sudo ip route show table 220
192.168.2.0/24 via AA.AA.AA.1 dev eth0  proto static  src 192.168.1.1 
192.168.250.129 via AA.AA.AA.1 dev eth0  proto static  src 192.168.1.1

Additional information from B:

hanjo@B:~$ sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.2.1, Linux 4.4.23+, armv6l):
  uptime: 24 hours, since Jan 07 22:19:36 2017
  malloc: sbrk 663552, mmap 0, used 246232, free 417320
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 12
  loaded plugins: charon aes rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default farp stroke updown eap-identity eap-aka eap-md5 eap-gtc eap-mschapv2 eap-radius eap-tls eap-ttls eap-tnc xauth-generic xauth-eap xauth-pam tnc-tnccs dhcp lookip error-notify certexpire led addrblock unity
Virtual IP pools (size/online/offline):
Listening IP addresses:
  192.168.2.254
Connections:
    A-tunnel:  192.168.2.254,0.0.0.0/0,::/0...AA.AA.AA.AA,0.0.0.0/0,::/0  IKEv2, dpddelay=30s
    A-tunnel:   local:  [B] uses pre-shared key authentication
    A-tunnel:   remote: [A] uses pre-shared key authentication
    A-tunnel:   child:  192.168.2.0/24 === 192.168.1.0/24 192.168.250.0/24 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
       A-tunnel[11]: ESTABLISHED 6 hours ago, 192.168.2.254[B]...AA.AA.AA.AA[A]
       A-tunnel[11]: IKEv2 SPIs: 0a9bd6cc2a62ef97_i 1cbadc244257cdb1_r*, pre-shared key reauthentication in 79 minutes
       A-tunnel[11]: IKE proposal: AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_8192
       A-tunnel{12}:  INSTALLED, TUNNEL, ESP in UDP SPIs: cebce241_i cbd873b7_o
       A-tunnel{12}:  AES_CBC_256/HMAC_SHA2_512_256, 275930 bytes_i (3754 pkts, 0s ago), 523881 bytes_o (3728 pkts, 0s ago), rekeying in 22 minutes
       A-tunnel{12}:   192.168.2.0/24 === 192.168.1.0/24 192.168.250.0/24

hanjo@B:~$ sudo ip xfrm policy
src 192.168.250.0/24 dst 192.168.2.0/24 
    dir fwd priority 2883 
    tmpl src AA.AA.AA.AA dst 192.168.2.254
        proto esp reqid 12 mode tunnel
src 192.168.250.0/24 dst 192.168.2.0/24 
    dir in priority 2883 
    tmpl src AA.AA.AA.AA dst 192.168.2.254
        proto esp reqid 12 mode tunnel
src 192.168.2.0/24 dst 192.168.250.0/24 
    dir out priority 2883 
    tmpl src 192.168.2.254 dst AA.AA.AA.AA
        proto esp reqid 12 mode tunnel
src 192.168.1.0/24 dst 192.168.2.0/24 
    dir fwd priority 2883 
    tmpl src AA.AA.AA.AA dst 192.168.2.254
        proto esp reqid 12 mode tunnel
src 192.168.1.0/24 dst 192.168.2.0/24 
    dir in priority 2883 
    tmpl src AA.AA.AA.AA dst 192.168.2.254
        proto esp reqid 12 mode tunnel
src 192.168.2.0/24 dst 192.168.1.0/24 
    dir out priority 2883 
    tmpl src 192.168.2.254 dst AA.AA.AA.AA
        proto esp reqid 12 mode tunnel
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 

hanjo@B:~$ sudo ip route
default via 192.168.2.1 dev eth0 
192.168.2.0/24 dev eth0  proto kernel  scope link  src 192.168.2.254 

hanjo@B:~$ sudo ip route show table 220
192.168.1.0/24 via 192.168.2.1 dev eth0  proto static  src 192.168.2.254 
192.168.250.0/24 via 192.168.2.1 dev eth0  proto static  src 192.168.2.254

Any idea what could be the problem?

ecdsa · Accepted Answer · 2017-01-16 11:35:14Z

This looks wrong:

20:42:28.897990 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 0, length 64

Why would there be an ICMP from the public IP of A to the mobile client when A is simply forwarding B's traffic? What you'd expect is an ESP packet with A's public IP but definitely not an ICMP.

Is there perhaps a NAT rule on A? If so, make sure to use the policy module to exempt traffic that matches an IPsec policy from the actual NAT rule. Basically add something like this before the actual NAT rule (also explained on the strongSwan wiki):

iptables -t nat -A POSTROUTING -s 192.168.1.0/24,192.168.2.0/24,192.168.250.0/24 -o eth0 -m policy --dir out --pol ipsec -j ACCEPT

This is it - thanks a lot. I should have seen it from the tcpdump, looks very suspicious now. — hanjo, Commented Jan 19, 2017 at 18:28

Stack Exchange Network

Strongswan forwarding traffic between two IPsec tunnels where one is a host

1 Answer 1

You must log in to answer this question.

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

Linked

Hot Network Questions

Strongswan forwarding traffic between two IPsec tunnels where one is a host

1 Answer 1

You must log in to answer this question.

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

Linked

Related

Hot Network Questions

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