[Swan] net-to-net for road warriors

[Alex]

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?

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?