On Wed, 2007-02-07 at 15:02 -0500, Brian J. Murrell wrote: > On Wed, 2007-02-07 at 07:23 -0800, Tom Eastep wrote: > > > > Your problem is how to handle VPN interfaces in a multi-ISP environment -- > > Not quite even. It's how to make the DUPLICATEd routing tables receive > the same updates that the table it's duplicated from receive. i.e. when > the main table gets a new route for an instantiated openvpn connection, > the duplicated tables need to know too.
That's just the way ip route works, it doesn't magically know to add routes to other tables when you add one to main. Have you considered just adding those routes as well to your openvpn startup scripts? > > > the route_rules file was designed exactly for that purpose > > Hrm. As I read it, it's for dedicating a certain traffic pattern to an > Internet interface. I guess this is one way to solve this problem, but > it's more rigid than just allowing the the routing engine to solve the > problem. > > > and there's even > > an example in the file itself dealing with OpenVPN (copied from "Example 2" > > in the route_rules section of the Multi-ISP document). > > Yes, again, though it's quite rigid. My example of how I can manually > solve the problem, but doing a: > > # ip route add 10.75.23.0/24 via 10.33.66.2 dev tun0 table CGCO > > is more flexible because it allows the current routing policy to make > the decisions and should even deal with a sudden change in default > routing transparently. As I understand route_rules, it would not. > > Why would I want this flexibility? Failover/redundancy. I could tell > my peers they could connect to either of my Internet addresses for > openvpn service and as long a the outbound routing decision is made in > the routing table, connections should work on either ISP interface > transparently. I think. :-) > The solution you are looking for is multi-homed + BGP. If that isn't an option (and if it were, you wouldn't be here), you can do something like I am doing. I am using ipsec, but the concept is much the same. I do host to host encryption between the end point, and each of the external IPs on my end (three different ISPs in my case). Then I pop up one GRE tunnel for each and add appropriate routes. Now only one GRE tunnel will actually work at any given time, but the up/down state for a GRE tunnel is actually significant (and correct), unlike most vpn tunnels. So you can do a multipath route across the various GRE tunnels, and it will only go over whichever one is up. PS watch your MTU, otherwise running a tunnel inside of a tunnel will eat your cat. Thanks, Bryan Vukich
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
