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
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
