Hi All, As you know, I've discussed here a number of times in the past about the problems with the MultiISP support in shorewall, specifically in the way routing is set up.
I wonder if we can restructure the route rules to better accommodate the
after-shorewall-has-started-route-manipulation problem.
To provide a real-world use case, imagine a MultiISP shorewall and
openvpn configuration where the multiple ISP links are tracked and
balanced. This all works fine as long as nothing comes along and adds
routes to the "main" routing table after shorewall has made it's
per-provider copy of it. So this means of course that openvpn, if it's
going to install client subnet routes, needs to be run first. It also
means that if openvpn gets some updated configuration, shorewall needs
to be restarted to get the additions in it's per-provider routing
tables.
So, can we rearrange the route rules, possibly adding more rules and
tables to somehow eliminate this need to copy the main table for the
per-provider tables and taking advantage of the fact that all of the
routing tools out there, unless they are capable and have been told
otherwise, add to the "main" table.
I'm still trying to wrap my head around it, but I'm thinking of
something along the lines of not having any default routing at all in
the main table (all interface plumbing processes like PPP, DHCP, etc.
need to be told not to plumb default routes), having the main table
before the per-provider tables and having the per provider tables be not
much more, if anything at all than default routes through their
interfaces and then a catchall default table at the end.
So the route rules would look like:
0: from all lookup local
32766: from all lookup main
40000: from all fwmark 0x100 lookup ISP1
40001: from all fwmark 0x200 lookup ISP2
50000: from 167.3.32.3 lookup ISP1
50256: from 166.1.37.24 lookup ISP2
65535: from all lookup default
table ISP1 would look like:
167.3.32.3 dev eth0.1 scope link
default via 167.3.208.1 dev eth0.1
table ISP2 would be the same, but for it's provider
table main would be the standard default routing table, with NO default
routes:
213.197.29.32 via 167.3.208.1 dev eth0.1
213.204.193.2 via 167.3.208.1 dev eth0.1
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
192.168.200.1 dev ppp0 proto kernel scope link src 166.1.37.24
10.8.0.0/24 via 10.8.0.2 dev tun0
192.168.1.0/24 via 10.75.22.1 dev br-lan proto zebra metric 20 equalize
192.168.0.0/24 via 10.75.22.5 dev br-lan proto zebra equalize
10.75.22.0/24 dev br-lan proto kernel scope link src 10.75.22.199
10.75.23.0/24 via 10.8.0.2 dev tun0
167.3.208.0/20 dev eth0.1 proto kernel scope link src 167.3.32.3
169.254.0.0/16 via 10.75.22.223 dev br-lan proto zebra metric 20 equalize
and then routing table "default" would have the load balancing routes:
default
nexthop via 167.3.208.1 dev eth0.1 weight 1
nexthop via 192.168.200.1 dev ppp0 weight 1
Does something like this have any chance of working or am I totally on
crack?
The one big caveat is of course, that processes which plumb interfaces
such as DHCP, PPP, etc. CANNOT plumb default routes and Shorewall has to
take care of that. That's how I run my MultiISP router now anyway
though, so it's doable.
It also seems that the 50* route rules are not needed/useful with this
setup. TBH, I'm not sure why they are needed even before my proposed
changes. Maybe their purpose will be the downfall of my proposal.
Thots?
b.
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
