Re: [Swan] subnet-to-subnet config
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
Re: [Swan] subnet-to-subnet config
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=60809=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 ___ Swan mailing list Swan@lists.libreswan.org
Re: [Swan] subnet-to-subnet config
Hi, > Hi, I'm trying to build a subnet-to-subnet VPN with libreswan-3.27 on > fedora28 and having some trouble. Should the subnets already exist on > the remote networks, or does libreswan create them? When I use the > config below, the networks disappear from the routing table and the > servers become unreachable. > > I've followed the directions on the subnet-to-subnet page: > https://libreswan.org/wiki/Subnet_to_subnet_VPN > > conn orion-wyckoff-subnets > also=orion-wyckoff > rightsubnet=192.168.11.0/24 > leftsubnet=192.168.1.0/24 > auto=start > > conn orion-wyckoff > ikev2=insist > authby=rsasig > auto=start > # dead peer detection to detect vanishing clients (?) > dpddelay=10 > dpdtimeout=90 > dpdaction=clear > rightid=@wyckoff-orion > right=wyckoff.crabdance.com > # rsakey AwEAAd4Ee > rightrsasigkey=0sAwEAAd4EeKjbFI7m... > leftid=@orion-wyckoff > left=orion.example.com > # rsakey AwEAAeSMF > leftrsasigkey=0sAwEAAeSMFxvoJaP... > > The rightsubnet (192.168.11.0/24) exists on the right network > (wyckoff.crabdance.com). The leftsubnet (192.168.1.0/24) already > exists on the left network (orion.example.com). > > wyckoff.crabdance.com > # route > Kernel IP routing table > Destination Gateway Genmask Flags Metric RefUse Iface > default ool-44c0f801.dy 0.0.0.0 UG10000 enp4s0 > 68.192.248.00.0.0.0 255.255.252.0 U 10000 enp4s0 > 192.168.10.00.0.0.0 255.255.255.0 U 10100 enp2s0 > 192.168.11.00.0.0.0 255.255.255.0 U 10100 enp2s0 > > orion.example.com: > # route > Kernel IP routing table > Destination Gateway Genmask Flags Metric RefUse Iface > default ool-44c3c129.st 0.0.0.0 UG0 00 br0 > 68.195.193.40 0.0.0.0 255.255.255.248 U 0 00 br0 > 192.168.1.0 0.0.0.0 255.255.255.0 U 0 00 eth1 > 192.168.6.0 0.0.0.0 255.255.255.0 U 0 00 eth1 > 192.168.122.0 0.0.0.0 255.255.255.0 U 0 00 virbr0 > > Will this config also make the endpoints accessible to each other? > > 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? 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. It also consequently makes the whole system unusable because it screws up the routes. 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. 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=60809=20 ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] subnet-to-subnet config
On 08/02/2019 21:20, Alex wrote: Hi, I'm trying to build a subnet-to-subnet VPN with libreswan-3.27 on fedora28 and having some trouble. Should the subnets already exist on the remote networks, or does libreswan create them? When I use the config below, the networks disappear from the routing table and the servers become unreachable. I've followed the directions on the subnet-to-subnet page: https://libreswan.org/wiki/Subnet_to_subnet_VPN conn orion-wyckoff-subnets also=orion-wyckoff rightsubnet=192.168.11.0/24 leftsubnet=192.168.1.0/24 auto=start conn orion-wyckoff ikev2=insist authby=rsasig auto=start # dead peer detection to detect vanishing clients (?) dpddelay=10 dpdtimeout=90 dpdaction=clear rightid=@wyckoff-orion right=wyckoff.crabdance.com # rsakey AwEAAd4Ee rightrsasigkey=0sAwEAAd4EeKjbFI7m... leftid=@orion-wyckoff left=orion.example.com # rsakey AwEAAeSMF leftrsasigkey=0sAwEAAeSMFxvoJaP... The rightsubnet (192.168.11.0/24) exists on the right network (wyckoff.crabdance.com). The leftsubnet (192.168.1.0/24) already exists on the left network (orion.example.com). wyckoff.crabdance.com # route Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface default ool-44c0f801.dy 0.0.0.0 UG10000 enp4s0 68.192.248.00.0.0.0 255.255.252.0 U 10000 enp4s0 192.168.10.00.0.0.0 255.255.255.0 U 10100 enp2s0 192.168.11.00.0.0.0 255.255.255.0 U 10100 enp2s0 orion.example.com: # route Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface default ool-44c3c129.st 0.0.0.0 UG0 00 br0 68.195.193.40 0.0.0.0 255.255.255.248 U 0 00 br0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 00 eth1 192.168.6.0 0.0.0.0 255.255.255.0 U 0 00 eth1 192.168.122.0 0.0.0.0 255.255.255.0 U 0 00 virbr0 Will this config also make the endpoints accessible to each other? 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. Nick ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
