[Swan] net-to-net for road warriors

Paul Wouters paul at nohats.ca
Sun Jan 27 18:28:50 UTC 2019


On Sun, 27 Jan 2019, Alex wrote:

> Yes, the tunnels have come up, but it appears no data is passing through them:
>
> # ipsec whack --trafficstatus
> 006 #6: "wyckofftun/1x1", type=ESP, add_time=1548605279, inBytes=0,
> outBytes=0, id='@wyckoff'
> 006 #7: "wyckofftun/1x2", type=ESP, add_time=1548605279, inBytes=0,
> outBytes=0, id='@wyckoff'
>
> Should the endpoints be included in the left/rightsubnets= lines? I've
> tried both ways. The above is without them.

The issue to be aware of is that for source ip, the linux kernel picks
the "nearest IP". So for a net-to-net scenario, it usualy means the
kernel picks the public instead of the private IP on the gateway itself.

If you need to be able to reach the subnets behind the far gateway from
the local gateway, the best is to get the routing done properly on
the local gateway (and visa versa). The updown script can do this for
simple conns, using sourceip=, but for more complicated scenarios
you might need to do something yourself. You have some options:

1) if the gateways have a private IP in only one network range of the
    many ones it is routing for, you can split that one net-to-net into
    its own conn section, and use leftsourceip= / rightsourceip=
2) customize _updown.netkey to add the routes (with src argument)
3) pre-install the proper routes (with src argument)

But it could also be that routes are fine, but your NAT or MASQUERADE
is modifying packets before the IPsec layer picks up the packets for
tunneling.

Also check /proc/net/xfrm_stats for non-zero values, which usually
indicate a problem

Also check if your machine has forwarding enabled via sysctl or
iptables.

Check dmesg for martian messages

Verify you have disabled rp_filter

Use ping -I with source address to confirm the tunnel independant of
the routing you have.

Paul


More information about the Swan mailing list