On 27/01/2019 21:30, Alex wrote:
Hi,
On Sun, Jan 27, 2019 at 1:28 PM Paul Wouters <[email protected]> wrote:
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.
Is there a more comprehensive guide of some sort that's available to
more completely describe what you've written above?
I believe I know what a source IP is, but isn't it relative to the
side you're on? I'm not entirely sure I understand how it applies to
my example. If I'm trying to reach 192.168.1.2 from the remote gateway
with the dynamic IP (68.192.251.223), wouldn't it know enough to
figure out that it has to go through to the other gateway to get to
the 192.168.1.0/24 network on its own?
The source IP problem is only relevant if one of the gateways is talking
to the remote LAN or gateway. Traffic from the gateway (not through the
gateway) will naturally go out directly through the WAN interface and so
not through libreswan. To stop that, if you have a single LAN subnet
attached to the gateway, you specify the gateway LAN IP as your
(left/right)sourceip, but Paul is saying this does not work with
multiple LANs. You never need to know the remote source IP.
Is this configuration so atypical that it's a special circumstance and
the existing example isn't enough on its own?
https://libreswan.org/wiki/Subnet_to_subnet_VPN
This is all really to connect the asterisk systems together on
192.168.1.2 from the remote office behind the 68.192.251.223 network.
Is asterisk going to have a problem doing this on its own?
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
