[Swan] net-to-net for road warriors

[Nick Howitt]

On 27/01/2019 21:30, Alex wrote:
> Hi,
>
> On Sun, Jan 27, 2019 at 1:28 PM Paul Wouters <paul at nohats.ca> 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
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan