[strongSwan] Roadwarriors can't ping eachother

[Noel Kuntze]

Hi,

Check your iptables rules.

Kind regards

Noel

On 09.09.2017 14:06, Bas van Dijk wrote:
> Dear list,
>
> (I accidentally sent a previous message <https://groups.google.com/forum/#%21topic/strongswan-users/2ytikPcg7jA> to the read-only strongswan-users at googlegroups.com <mailto:strongswan-users at googlegroups.com>. So let's try the real list.)
>
> I'm working on another NixOS strongswan test. This time I have two roadwarriors alice and carol that set up a connection to gateway moon. They request a virtual IP. The gateway moon assigns virtual IP addresses from a pool per roadwarrior containing a single IP address. Authentication is based on X.509 certificates. In order to test the tunnel alice and carol ping each other. The test configuration can be found in:
>
> https://github.com/LumiGuide/nixpkgs/blob/strongswan-swanctl-pubkey-test/nixos/tests/strongswan-swanctl-pubkey.nix
>
> The roadwarriors alice and carol can successfully establish a CHILD_SA with the gateway moon. The problem is that the roadwarriors can't ping eachother. 
>
> This is a tcpdump on alice while initiating the CHILD_SA and trying to ping carol:
>
> [alice] $ tcpdump -s 0 -n -i nflog:5
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on nflog:5, link-type NFLOG (Linux netfilter log messages), capture size 262144 bytes
> # swanctl -i --child alice
> 11:05:07.318185 IP 192.168.1.1.500 > 192.168.1.3.500: isakmp: parent_sa ikev2_init[I]
> 11:05:07.318291 IP 192.168.1.3.500 > 192.168.1.1.500: isakmp: parent_sa ikev2_init[R]
> 11:05:07.318296 IP 192.168.1.1.4500 > 192.168.1.3.4500: NONESP-encap: isakmp: child_sa  ikev2_auth[I]
> 11:05:07.318308 IP 192.168.1.1.4500 > 192.168.1.3.4500: NONESP-encap: isakmp: child_sa  ikev2_auth[I]
> 11:05:08.346181 IP 192.168.1.3.4500 > 192.168.1.1.4500: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
> 11:05:08.346196 IP 192.168.1.3.4500 > 192.168.1.1.4500: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
> # ping -c 1 10.0.0.2
> 11:05:15.898172 IP 192.168.1.1 > 10.0.0.2 <http://10.0.0.2>: ICMP echo request, id 1120, seq 1, length 64
> 11:05:15.898200 IP 192.168.1.1 > 10.0.0.2 <http://10.0.0.2>: ICMP echo request, id 1120, seq 1, length 64
> 11:05:15.898205 IP 192.168.1.1 > 192.168.1.3 <http://192.168.1.3>: ESP(spi=0xc6877d56,seq=0x1), length 136
>
> So it looks like the ping packet gets encapsulated and send to moon. This is the dump on moon:
>
> [moon] $ tcpdump -s 0 -n -i nflog:5
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on nflog:5, link-type NFLOG (Linux netfilter log messages), capture size 262144 bytes
> 11:05:07.170190 IP 192.168.1.1.500 > 192.168.1.3.500: isakmp: parent_sa ikev2_init[I]
> 11:05:07.170218 IP 192.168.1.3.500 > 192.168.1.1.500: isakmp: parent_sa ikev2_init[R]
> 11:05:07.170221 IP 192.168.1.1.4500 > 192.168.1.3.4500: NONESP-encap: isakmp: child_sa  ikev2_auth[I]
> 11:05:07.170227 IP 192.168.1.1.4500 > 192.168.1.3.4500: NONESP-encap: isakmp: child_sa  ikev2_auth[I]
> 11:05:08.225827 IP 192.168.1.3.4500 > 192.168.1.1.4500: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
> 11:05:08.225843 IP 192.168.1.3.4500 > 192.168.1.1.4500: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
>
> 11:05:15.777787 IP 192.168.1.1 > 192.168.1.3 <http://192.168.1.3>: ESP(spi=0xc6877d56,seq=0x1), length 136
>
> So moon receives the encapsulated ping message from alice but it never reroutes it to carol. Is this caused by a bad routing configuration? These are the routes on alice and her auto-generated swanctl configuration:
>
> [alice] $ ip route list table 220
> 10.0.0.0/24 <http://10.0.0.0/24> via 192.168.1.3 dev eth1 proto static src 192.168.1.1 
>
> [alice] $ cat /etc/swanctl/swanctl.conf
> connections {
>   alice {
>     children {
>       alice {
>         remote_ts = 10.0.0.0/24 <http://10.0.0.0/24>
>         start_action = trap
>         updown = /nix/store/jdcviy5z25xamq35g8k9qbdpskkx3w9g-strongswan-5.6.0/libexec/ipsec/_updown iptables
>       }
>     }
>     local-main {
>       auth = pubkey
>       certs = aliceCert.der
>       id = alice
>     }
>     remote-main {
>       auth = pubkey
>       id = moon
>     }
>     remote_addrs = moon
>     version = 2
>     vips = 0.0.0.0
>   }
> }
>
> Routing table 220 is empty on moon. Is that how it's supposed to be? This is its auto-generated swanctl configuration:
>
> [moon] $ cat /etc/swanctl/swanctl.conf 
> connections {
>   alice {
>     children {
>       alice {
>         local_ts = 10.0.0.0/24 <http://10.0.0.0/24>
>         updown = /nix/store/jdcviy5z25xamq35g8k9qbdpskkx3w9g-strongswan-5.6.0/libexec/ipsec/_updown iptables
>       }
>     }
>     local-main {
>       auth = pubkey
>       certs = moonCert.der
>       id = moon
>     }
>     pools = alice
>     remote-main {
>       auth = pubkey
>       id = alice
>     }
>     version = 2
>   }
>   carol {
>     children {
>       carol {
>         local_ts = 10.0.0.0/24 <http://10.0.0.0/24>
>         updown = /nix/store/jdcviy5z25xamq35g8k9qbdpskkx3w9g-strongswan-5.6.0/libexec/ipsec/_updown iptables
>       }
>     }
>     local-main {
>       auth = pubkey
>       certs = moonCert.der
>       id = moon
>     }
>     pools = carol
>     remote-main {
>       auth = pubkey
>       id = carol
>     }
>     version = 2
>   }
> }
> pools {
>   alice {
>     addrs = 10.0.0.1
>   }
>   carol {
>     addrs = 10.0.0.2
>   }
> }
>
> I'm sure I'm not configuring something correctly. Can somebody point me in the right direction to get this test succeeding?
>
> Regards,
>
> Bas
>
>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170909/96e1e430/attachment-0001.sig>