[strongSwan] Roadwarriors can't ping eachother
Noel Kuntze
noel.kuntze+strongswan-users-ml at thermi.consulting
Sat Sep 9 15:57:32 CEST 2017
Hi Bas,
Please provide the outputs of `iptables-save -c` on all hosts
and the output of `sysctl -A | grep rp_filter`. `iptables -S` is not useful.
Kind regards
Noel
On 09.09.2017 15:50, Bas van Dijk wrote:
> Hi Noel,
>
> These are the firewall rules of all hosts after establishing the tunnels (all the NFLOG rules will be removed eventually, they're currently used for debugging):
>
> [alice] $ iptables -S
> -P INPUT ACCEPT
> -P FORWARD ACCEPT
> -P OUTPUT ACCEPT
> -N nixos-fw
> -N nixos-fw-accept
> -N nixos-fw-log-refuse
> -N nixos-fw-refuse
> -A INPUT -s 10.0.0.0/24 <http://10.0.0.0/24> -d 10.0.0.1/32 <http://10.0.0.1/32> -i eth1 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
> -A INPUT -m addrtype ! --dst-type LOCAL -m policy --dir in --pol ipsec -j NFLOG --nflog-group 5
> -A INPUT -m addrtype --dst-type LOCAL -m policy --dir in --pol ipsec -j NFLOG --nflog-group 5
> -A INPUT -p udp -m multiport --dports 500,4500 -j NFLOG --nflog-group 5
> -A INPUT -p ah -j NFLOG --nflog-group 5
> -A INPUT -p esp -j NFLOG --nflog-group 5
> -A INPUT -j nixos-fw
> -A FORWARD -s 10.0.0.0/24 <http://10.0.0.0/24> -d 10.0.0.1/32 <http://10.0.0.1/32> -i eth1 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
> -A FORWARD -s 10.0.0.1/32 <http://10.0.0.1/32> -d 10.0.0.0/24 <http://10.0.0.0/24> -o eth1 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
> -A OUTPUT -s 10.0.0.1/32 <http://10.0.0.1/32> -d 10.0.0.0/24 <http://10.0.0.0/24> -o eth1 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
> -A OUTPUT -m policy --dir out --pol ipsec -j NFLOG --nflog-group 5
> -A OUTPUT -p udp -m multiport --dports 500,4500 -j NFLOG --nflog-group 5
> -A OUTPUT -p ah -j NFLOG --nflog-group 5
> -A OUTPUT -p esp -j NFLOG --nflog-group 5
> -A nixos-fw -i lo -j nixos-fw-accept
> -A nixos-fw -m conntrack --ctstate RELATED,ESTABLISHED -j nixos-fw-accept
> -A nixos-fw -p icmp -m icmp --icmp-type 8 -j nixos-fw-accept
> -A nixos-fw -j nixos-fw-log-refuse
> -A nixos-fw-accept -j ACCEPT
> -A nixos-fw-log-refuse -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "rejected connection: " --log-level 6
> -A nixos-fw-log-refuse -m pkttype ! --pkt-type unicast -j nixos-fw-refuse
> -A nixos-fw-log-refuse -j nixos-fw-refuse
> -A nixos-fw-refuse -j DROP
>
> [carol] $ iptables -S
> -P INPUT ACCEPT
> -P FORWARD ACCEPT
> -P OUTPUT ACCEPT
> -N nixos-fw
> -N nixos-fw-accept
> -N nixos-fw-log-refuse
> -N nixos-fw-refuse
> -A INPUT -s 10.0.0.0/24 <http://10.0.0.0/24> -d 10.0.0.2/32 <http://10.0.0.2/32> -i eth1 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
> -A INPUT -m addrtype ! --dst-type LOCAL -m policy --dir in --pol ipsec -j NFLOG --nflog-group 5
> -A INPUT -m addrtype --dst-type LOCAL -m policy --dir in --pol ipsec -j NFLOG --nflog-group 5
> -A INPUT -p udp -m multiport --dports 500,4500 -j NFLOG --nflog-group 5
> -A INPUT -p ah -j NFLOG --nflog-group 5
> -A INPUT -p esp -j NFLOG --nflog-group 5
> -A INPUT -j nixos-fw
> -A FORWARD -s 10.0.0.0/24 <http://10.0.0.0/24> -d 10.0.0.2/32 <http://10.0.0.2/32> -i eth1 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
> -A FORWARD -s 10.0.0.2/32 <http://10.0.0.2/32> -d 10.0.0.0/24 <http://10.0.0.0/24> -o eth1 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
> -A OUTPUT -s 10.0.0.2/32 <http://10.0.0.2/32> -d 10.0.0.0/24 <http://10.0.0.0/24> -o eth1 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
> -A OUTPUT -m policy --dir out --pol ipsec -j NFLOG --nflog-group 5
> -A OUTPUT -p udp -m multiport --dports 500,4500 -j NFLOG --nflog-group 5
> -A OUTPUT -p ah -j NFLOG --nflog-group 5
> -A OUTPUT -p esp -j NFLOG --nflog-group 5
> -A nixos-fw -i lo -j nixos-fw-accept
> -A nixos-fw -m conntrack --ctstate RELATED,ESTABLISHED -j nixos-fw-accept
> -A nixos-fw -p icmp -m icmp --icmp-type 8 -j nixos-fw-accept
> -A nixos-fw -j nixos-fw-log-refuse
> -A nixos-fw-accept -j ACCEPT
> -A nixos-fw-log-refuse -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "rejected connection: " --log-level 6
> -A nixos-fw-log-refuse -m pkttype ! --pkt-type unicast -j nixos-fw-refuse
> -A nixos-fw-log-refuse -j nixos-fw-refuse
> -A nixos-fw-refuse -j DROP
>
> [moon] $ iptables -S
> -P INPUT ACCEPT
> -P FORWARD ACCEPT
> -P OUTPUT ACCEPT
> -N nixos-fw
> -N nixos-fw-accept
> -N nixos-fw-log-refuse
> -N nixos-fw-refuse
> -A INPUT -m addrtype ! --dst-type LOCAL -m policy --dir in --pol ipsec -j NFLOG --nflog-group 5
> -A INPUT -m addrtype --dst-type LOCAL -m policy --dir in --pol ipsec -j NFLOG --nflog-group 5
> -A INPUT -p udp -m multiport --dports 500,4500 -j NFLOG --nflog-group 5
> -A INPUT -p ah -j NFLOG --nflog-group 5
> -A INPUT -p esp -j NFLOG --nflog-group 5
> -A INPUT -j nixos-fw
> -A FORWARD -s 10.0.0.2/32 <http://10.0.0.2/32> -d 10.0.0.0/24 <http://10.0.0.0/24> -i eth1 -m policy --dir in --pol ipsec --reqid 2 --proto esp -j ACCEPT
> -A FORWARD -s 10.0.0.0/24 <http://10.0.0.0/24> -d 10.0.0.2/32 <http://10.0.0.2/32> -o eth1 -m policy --dir out --pol ipsec --reqid 2 --proto esp -j ACCEPT
> -A FORWARD -s 10.0.0.1/32 <http://10.0.0.1/32> -d 10.0.0.0/24 <http://10.0.0.0/24> -i eth1 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
> -A FORWARD -s 10.0.0.0/24 <http://10.0.0.0/24> -d 10.0.0.1/32 <http://10.0.0.1/32> -o eth1 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
> -A OUTPUT -m policy --dir out --pol ipsec -j NFLOG --nflog-group 5
> -A OUTPUT -p udp -m multiport --dports 500,4500 -j NFLOG --nflog-group 5
> -A OUTPUT -p ah -j NFLOG --nflog-group 5
> -A OUTPUT -p esp -j NFLOG --nflog-group 5
> -A nixos-fw -i lo -j nixos-fw-accept
> -A nixos-fw -m conntrack --ctstate RELATED,ESTABLISHED -j nixos-fw-accept
> -A nixos-fw -p udp -m udp --dport 4500 -j nixos-fw-accept
> -A nixos-fw -p udp -m udp --dport 500 -j nixos-fw-accept
> -A nixos-fw -p icmp -m icmp --icmp-type 8 -j nixos-fw-accept
> -A nixos-fw -j nixos-fw-log-refuse
> -A nixos-fw-accept -j ACCEPT
> -A nixos-fw-log-refuse -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "rejected connection: " --log-level 6
> -A nixos-fw-log-refuse -m pkttype ! --pkt-type unicast -j nixos-fw-refuse
> -A nixos-fw-log-refuse -j nixos-fw-refuse
> -A nixos-fw-refuse -j DROP
>
>
> On 9 September 2017 at 15:34, Noel Kuntze <noel.kuntze+strongswan-users-ml at thermi.consulting <mailto:noel.kuntze+strongswan-users-ml at thermi.consulting>> wrote:
>
> Hi,
>
> Check your iptables rules.
>
> Kind regards
>
> Noel
>
> On 09.09.2017 14 <tel:09.09.2017%2014>:06, Bas van Dijk wrote:
> > Dear list,
> >
> > (I accidentally sent a previous message <https://groups.google.com/forum/#%21topic/strongswan-users/2ytikPcg7jA <https://groups.google.com/forum/#%21topic/strongswan-users/2ytikPcg7jA>> to the read-only strongswan-users at googlegroups.com <mailto:strongswan-users at googlegroups.com> <mailto: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 <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> <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> <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> <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> <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/89de35fe/attachment.sig>
More information about the Users
mailing list