I'm facing a similar question as described here, but the solution did not work in my scenario.I havea 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/24a 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/24a mobile device with a dynamic external IP address MM.MM.MM.MM and an IP of 192.168.250.129 when connected to the VPNBetween 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/2519:28:31.367911 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 0, length 6419:28:32.469991 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 1, length 6419:28:33.410002 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 2, length 6419:28:34.389997 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 3, length 6419:28:35.449973 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 4, length 64On 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/2420:44:27.201713 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 55134, seq 0, length 6420:44:28.202222 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 55134, seq 1, length 6420:44:29.202355 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 55134, seq 2, length 6420:44:30.202603 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 55134, seq 3, length 64Capture from A:hanjo@A:~$ sudo tcpdump -n net 192.168.250.128/2520:42:28.897441 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 39774, seq 0, length 6420:42:28.897990 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 0, length 6420:42:29.897510 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 39774, seq 1, length 6420:42:29.897962 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 1, length 6420:42:30.897469 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 39774, seq 2, length 6420:42:30.897918 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 2, length 6420:42:31.897458 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 39774, seq 3, length 6420:42:31.897911 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 3, length 64However, 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=routeconn 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=secretconn mobile    also=rw-v2    auto=add    rightid=@mobileB'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=startAdditional information from A:hanjo@A:~$ sudo ipsec statusallStatus 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 addrblockVirtual IP pools (size/online/offline):  192.168.250.128/25: 126/1/1Listening IP addresses:  AA.AA.AA.AA  192.168.1.1Connections:B-tunnel:  AA.AA.AA.AA...B.dyndns  IKEv2, dpddelay=30sB-tunnel:   local:  [A] uses pre-shared key authenticationB-tunnel:   remote: [B] uses pre-shared key authenticationB-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=clearRouted Connections:B-tunnel{5}:  ROUTED, TUNNELB-tunnel{5}:   192.168.1.0/24 192.168.250.0/24 === 192.168.2.0/24Security 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/32B-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 minutesB-tunnel[19]: IKE proposal: AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_8192B-tunnel{5}:  INSTALLED, TUNNEL, ESP in UDP SPIs: cbd873b7_i cebce241_oB-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 minutesB-tunnel{5}:   192.168.1.0/24 192.168.250.0/24 === 192.168.2.0/24hanjo@A:~$ sudo ip xfrm policysrc 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 tunnelsrc 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 tunnelsrc 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 tunnelsrc 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 tunnelsrc 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 tunnelsrc 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 tunnelsrc 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 tunnelsrc 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 tunnelsrc 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 tunnelsrc 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 tunnelsrc 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 tunnelsrc 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 tunnelsrc 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 routedefault 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 220192.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 statusallStatus 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 unityVirtual IP pools (size/online/offline):Listening IP addresses:  192.168.2.254Connections:    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=restartSecurity 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/24hanjo@B:~$ sudo ip xfrm policysrc 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 tunnelsrc 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 tunnelsrc 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 tunnelsrc 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 tunnelsrc 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 tunnelsrc 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 tunnelsrc 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 routedefault 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 220192.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?
Strongswan forwarding traffic between two IPsec tunnels where one is a host
routing;vpn;strongswan
This looks wrong:20:42:28.897990 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 0, length 64Why 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