[strongSwan] overlapping IP ranges and strongswan default ip xfrm policy behavior

Nicholas Jenkins nick at notashutin.com
Sun Feb 23 05:07:39 CET 2020


Hi, I’m new here.

 

I  built a distributed hub-and-spoke family network using Strongswan – thank you for making that possible!

 

I assigned site-local (LAN) network addressing for family as: 192.168.[0|4|8|12|16|20|24].0/22 

I then set the VPN as 192.168.0.0/17 (not /16, because I found that one of the ISP’s involved assigned 192.168.129.0/24 to router…)

So, yes, the LAN address is then an overlapping range/overlapping subnet to the WAN VPN (e.g. 192.168.16.0/22 ====== 192.168.0.0/17)… but in traditional routing, this is not an issue, as the host simply routes traffic based upon the most  specific route that meets the need (in this case, keeping local traffic local, and WAN traffic on WAN).

 

Ok… so the problem I faced was that “ip xfrm policy” would see  traffic from src=LAN address to dest=LAN address as also matching the criteria for LAN->WAN, because LAN address is a subset of WAN.  So, although WAN/VPN communications worked just fine, traffic between VPN gateway + LAN would not work at all…

After a lot of reading, I realized that there were several solutions, including:

1.	Use multiple, individual ranges, instead of 192.168.0.0/17 for remote VPN subnet
2.	Use VTI to change this into a route-based VPN
3.	Set “ip xfrm policy” to NOT transform for 192.168.16.0/22…exclude the local LAN address space

 

I chose option 3, and it works great.

I modified the /usr/sbin/ipsec script into my own script to set ip xfrm policy (/usr/sbin/custom-ip-xfrm), and I created a /etc/systemd/system/custom-ip-xfrm.service that I set [Unit] to “After=strongswan.service” to run the /usr/sbin script on boot

In this way, I set an “in”, and an “out” ip xfrm policy rule to not xfrm the local subnet, after strongswan has started.

The important lines of custom-ip-xfrm are:

ip xfrm policy add src ${LOCAL_SUBNET} dst ${LOCAL_SUBNET} dir in priority 0

ip xfrm policy add src ${LOCAL_SUBNET} dst ${LOCAL_SUBNET} dir out priority 0

in the script, LOCAL_SUBNET will be something like “192.168.16.0/22”

 

I mention this, because I think it is odd that:

A.	These rules (perhaps with less aggressive priority) aren’t automatically set by Strongswan, regardless of my specific use case, by default, when it is setting ip xfrm policy? (i.e. guarantee local communications with the LAN work without xfrm, unless intentionally over-ridden for IPSec with LAN host, for example.)
B.	The ipsec.conf “left/right=” term doesn’t have an exclude option… it is only “inclusive”, and can handle several ranges (for inclusion), but no ranges for exclusion (e.g. 192.168.0.0/17-192.168.16.0/22)
C.	I didn’t find any detailed articles about solving the ip xfrm issue created by overlapping subnets…just a vague reference to “overlapping subnets”.

 

My goal for this note was 2-fold:

I)                 Get details about a problem overlapping subnets can create + how to solve this one into the notes for future generations 😊

II)               To ask if A/B should be opened as an “issue”, or if the fact there are work-arounds should focus my efforts on helping with documentation?

 

Thank you for reading this far… feedback is appreciated.

 

Best Regards,

-NICK 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200222/d0e45a69/attachment.html>


More information about the Users mailing list