[Swan] subnet-to-subnet config

[Paul Wouters]

On Sat, 9 Feb 2019, Alex wrote:

>> conn orion-wyckoff-subnets
>>         also=orion-wyckoff
>>         rightsubnet=192.168.11.0/24
>>         leftsubnet=192.168.1.0/24

>> Add left/rightsourceip. Note you only need it for the local end but there is no harm adding it for both ends. For subnet/subnet connections the routing table is not used (check out "ip xfrm policy" and "ip xfrm state"). You only get the routing entry if you use left/rightsourceip and is only relevant for traffic to or from the endpoint rather than through it.
>
> So if I do add the left/rightsourceip parameters, the routes should
> not already exist on the endpoints, correct?

Correct. the specification of sourceip causes it to add routes.
Basically, your host, say on IP address 1.2.3.4, needs to connect
to the VPN to reach 192.168.1.0/24 across the VPN. It will forward
all traffic between its own (192.168.11.0/24) and the remote
192.168.1.0/24. This is a strict policy. If your gateway receives
a packet from 192.168.1.13 destinated 192.168.1.66, it will match
and encrypt and forward that traffic.

The tricky issue is when your gateway itself generates a packet for
the remote subnet 192.168.1.66. The linux kernel picks the "nearest"
IP to use as source ip. So it will pick your public ip 1.2.3.4. This
IP is NOT part of the IPsec policy for the tunnel which only covers
traffic from 192.168.1.0/24 to 192.168.11.0/24. So the gateway should
be told to use its own IP from the LAN, not its public IP. The
leftsourceip= option does this.

so it basically runs (say 2.3.4.5 is your default gateway on the the
ipsec gateway:

ip route add 192.168.11.0/24 via 2.3.4.5 src 192.168.1.254

(also assuming the LAN ip is 192.168.1.254)

This route does not affect the existing forwarding from the LAN over
the IPsec that already happened. But for packets created from the
gateway itself any destination IP with 192.168.11.0/24 will not pick
1.2.3.4 but 192.168.1.254.

On the other gateway, you have the same issue in mirror form with its
own LAN.

> I see that it adds the routes, but it also creates a bunch of martian
> source messages because the network already exists on the host.

That seems like perhaps you mixed up leftsourceip/rightsourceip on the other end?

martians happen when you see IP with a source address that appears on
the wrong interface. If you have IP 12.12.12.0/24 on your LAN and you
receive packet with source 12.12.12.33 on your WAN interface, the system
triggers the alarm of martian invasion.

There is one legitimate scenario where this could happen: if your IPsec
gateway has 1 interface or if the "uplink" and the "LAN" reside on the
same interface. This is often the case when the VPN server is behind
NAT, and only really has 1 interface with the LAN packets. Linux
receives an encrypted packet from one interface, decrypts it, and then
gets confused that the packet needs to go out the same interface.

This is why we recommend to disable rp_filter and source route options
via sysctl.conf in those scenarios:

net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
# when using 1 interface for two networks when using NETKEY, the kernel
# kernel thinks it can be clever by sending a redirect (cause it cannot
# tell an encrypted packet came in, but a decrypted packet came out),
# so it sends a bogus ICMP redirect
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.conf.default.log_martians = 0
net.ipv4.conf.all.log_martians = 0

> One thing I didn't mention previously is that the right side (remote)
> is a dynamic IP on a cable modem with a hostname through afraid.org. I
> had originally thought this was a type of roadwarrior setup, but
> apparently not. I'm now not sure of the role that plays, if any.

That should not matter.

> I also tried to reach the remote side by specifying the interface when
> running ping from the local side:
> # ping 192.168.11.1 -I 68.195.193.42
>
> This thread seems to indicate the left/rightsourceip are switched so
> it refers to the network on the opposite side? So if 192.168.11.0/24
> is on the right (remote) side and 192.168.1.0/24 is on the local
> (left) side, rightsourceip should be 192.168.1.0/24 and leftsourceip
> should be 192.168.11.0/24?
> https://www.centos.org/forums/viewtopic.php?f=16&t=60809&start=20

No, you must ensure that the leftsourceip= specified is the gateway's
actual internal IP address, and this ip address must be part of the
leftsubnet= you specify. When using multiple subnetS=, do not use
leftsourceip= (you likely would not have an IP address on the server
in all those local subnets anyway)

Paul