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 [email protected] > <mailto:[email protected]>. 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 > > >
signature.asc
Description: OpenPGP digital signature
