IP rule help -cant exempt directly connected routes from VPN 0.0.0.0/0
Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
IP rule help -cant exempt directly connected routes from VPN 0.0.0.0/0
Hi,
I've having issues with linux policy routing. I've got two possible default routes. One is whichever interface gets DHCP for WAN and the other is a Strongswan VTI. I want all traffic to go out the VTI except a couple IPs and directly connected routes. I've been able to do this for the public IPs I want to exempt, the problem is when I do it, the rule supersedes the directly connected interfaces which get DHCP for WAN connections. The routes on the directly connected interfaces will change(as will the default next hop), so I can't define statically with a route statement.
Here are my rules:
0: from all lookup local
220: from all lookup 220
1000: from all to 8.8.8.8 lookup main
1001: from all to 4.2.2.1 lookup main
1500: from all lookup vpn-routes
32766: from all lookup main
32767: from all lookup default
~# ip route sho tab vpn-routes
default via 172.21.0.1 dev vti1
~# ip route sho tab main
default via 192.168.10.2 dev eth0 proto static src 192.168.10.129 # This is DHCP and will change
10.100.0.0/24 dev eth1 proto kernel scope link src 10.100.0.114
10.100.0.1 dev eth1 proto static scope link src 10.100.0.114
172.21.0.0/23 dev vti1 scope link
172.30.5.45 via 192.168.68.1 dev tap0
172.30.5.83 via 192.168.68.1 dev tap0
172.30.5.166 via 192.168.68.1 dev tap0
172.30.5.200 via 192.168.68.1 dev tap0
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.129
192.168.10.2 dev eth0 proto static scope link src 192.168.10.129
192.168.68.0/23 dev tap0 proto kernel scope link src 192.168.68.7
192.168.204.0/24 dev eth2 proto kernel scope link src 192.168.204.129 # This is DHCP and will change
I'm new to policy routing on linux, any thoughts would be appreciated. Thanks.
I dont see how that fixes the problem. The primary wan can't cease being a gateway. In fact initially it is needed. I need a few addresses to connect outside the tunnel, one being the tunnel peer address. But the tunnel needs a gateway to initiate the tunnel. There are no static IPs. The WAN is DHCP. Maybe I just dont follow what you are saying. Perhaps explain further? I mean pretty please.
I assume your issue is that default gateway got on WAN DHCP change your configuration. So my suggestion is that using nogateway option on WAN DHCP ignore the gateway configuration, always keep your configuration.
If your problem is that you're no longer able to communicate with hosts on connected networks once a StrongSwan VPN tunnel with a 0.0.0.0/0 "right" network definition is activated, then I'm afraid it's a policy issue.
I'm seeing the exact same behaviour with a router running OpenWRT. If I use 0.0.0.0/0 as the remote network, StrongSwan will happily add a transform policy for all IP traffic, meaning the local LAN instantly becomes unreachable.
Unfortunately, "installpolicy=no" cannot always be used as a workaround, as there may not be a way to add the correct policies manually. For instance, the ip command in OpenWRT just doesn't support the "xfrm" option, although it's listed in the help text. It should work on Ubuntu, though, so you could have StrongSwan call a script to add/remove the relevant transform policies whenever the tunnel is activated and deactivated.
Every other IPsec implementation I've encountered makes sure connected networks are exempt from IPsec ESP tunnels. Tunnels to remote networks defined as 0.0.0.0/0 work fine on Cisco/D-Link/ZyXEL gear, so I consider this a bug in StrongSwan.
If you are using OpenWRT, perhaps you should take a look at the 'multiwan' package. You can configure the default gateway and specific set of rules to redirect traffic under certain conditions you can specify.
Nini09. No that's not the issue. The issue is when I install an ip rule it supersedes directly connected interfaces, which is a little crazy IMO. This is not done via DHCP
Ser Olmy. Your closer. It in fact does not install policies. VTIs don't use policies in that way as I understand. There is nothing in iptables or ip route table 220. It's all controlled via routing tables and the associated ip rules. The reason I say this is before I install the ip rule and corresponding table, it works perfectly.
lsalab, Good idea! Unfortunately I will be using other distros as well.
I could also shell script it, but I would strongly prefer to use the built in linux PBR. Also it just doesn't seem right that adding a default route would take precedence over directly connected network with a way around it.
In that case, you could try to create different routing tables and specify manually which table should linux use depending on the conditions you set. Take a look at iproute2, here's a good resource on getting this thing going:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.