[Swan] subnet-to-subnet config

Sun Feb 10 00:15:24 UTC 2019

Hi,

> >> 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.

I think I understand the basic idea, but the 192.168.1.0/24 network is
well-established with quite a few systems behind it. The configuration
of the server is done from that LAN. That makes it difficult to
configure a subnet to be dependent upon the VPN always being running.
The server also provides DNS, DHCP, SMB, and other LAN functions to
the local network.

I got it (mostly) working using subnetS now, but it would be good to
understand how it works with just one network. There are multiple
networks on the LAN on both sides, but really only 192.168.1.0/24 is
necessary. I notice "ipsec trafficstatus" always shows zeros when
using subnetS?

I can ping 192.168.11.1 from 192.168.1.7, yet the trafficstatus remains zero.

> 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.

I think I'm somewhat confused without having actual network addresses
being used in your example. Can I ask you to review my config again to
determine why left/rightsubnet= isn't working?

Below is my config for both sides. I've included the routing table for
both servers here, including the routes as they're currently
configured. I'll have to remove them from the fedora config prior to
starting this and letting libreswan configure them.

On wyckoff (68.192.248.18, right, remote)
# ip route show table main
default via 68.192.248.1 dev enp4s0 proto dhcp metric 100
68.192.248.0/22 dev enp4s0 proto kernel scope link src 68.192.248.18 metric 100
192.168.10.0/24 dev enp2s0 proto kernel scope link src 192.168.10.1 metric 101
192.168.11.0/24 dev enp2s0 proto kernel scope link src 192.168.11.1 metric 101

conn orion-wyckoff
        ikev2=insist
        authby=rsasig
        auto=start
        interfaces=%defaultroute
        dpddelay=10
        dpdtimeout=90
        dpdaction=clear
        rightsourceip=192.168.11.1
        rightid=@wyckoff-orion
        right=wyckoff.crabdance.com
        # rsakey AwEAAd4Ee
        rightrsasigkey=0sAwEAAd4Ee...
        leftid=@orion-wyckoff
        left=orion.guardiandigital.com
        leftsourceip=192.168.1.1
        # rsakey AwEAAeSMF
        leftrsasigkey=0sAwEAAeSMF...

On orion (68.195.193.42, left, local)
# ip route show table main
default via 68.195.193.41 dev br0
68.195.193.40/29 dev br0 proto kernel scope link src 68.195.193.42
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1
192.168.6.0/24 dev eth1 proto kernel scope link src 192.168.6.1
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown

conn orion-wyckoff
        ikev2=insist
        authby=rsasig
        auto=add
        # dead peer detection to detect vanishing clients
        interfaces=%defaultroute
        dpddelay=10
        dpdtimeout=90
        dpdaction=clear
        rightsourceip=192.168.11.1
        rightid=@wyckoff-orion
        right=wyckoff.crabdance.com
        #right=%any
        #rightnexthop=%defaultroute
        # rsakey AwEAAd4Ee
        rightrsasigkey=0sAwEAAd4Ee...
        leftsourceip=192.168.1.1
        leftid=@orion-wyckoff
        left=orion.guardiandigital.com
        #leftnexthop=%defaultroute
        # rsakey AwEAAeSMF
        leftrsasigkey=0sAwEAAeSMF...

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

This is a little confusing because there is an ipsec gateway at both ends...

> 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)

It also assumes there's a route created for 192.168.1.0/24 on the
192.168.11.0/24 side, correct?

> 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.

I believe I have done this. I'm using 192.168.1.1 as the gateway for
that network.

> > 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?

I don't think so, but hopefully my config above will help to clarify
that, and you're able to help me make sense of it.

> 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.

Yes, understood.

> 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.

That's not happening here. There are two physical interfaces on both gateways.

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

Yes, I've done this as well.

> > 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)

The gateway (192.168.XX.1) for all of those networks are on the
gateways themselves.

I still cannot ping 192.168.11.1 from the local gateway and
192.168.1.1 from the remote gateway using left/rightsubnetS=. However,
I can ping normally one remote network from the other.