If I am configured for multi-isp routing with track and balance and using tcrules to force all originating traffic out one of the interfaces rather than really load balancing them and then if I have an openvpn tunnel that goes (down and then back) up it seems the ISP specific routing tables lose the openvpn added route and therefore try to route via the default interface. i.e. # ip route ls table CGCO 24.226.1.121 dev eth1 scope link 72.38.184.1 dev eth1 scope link src 72.38.184.236 192.168.200.1 dev ppp0 proto kernel scope link src 66.11.173.224 192.168.0.0/24 via 10.75.22.137 dev eth0 proto zebra 10.75.22.0/24 dev eth0 proto kernel scope link src 10.75.22.254 10.75.23.0/24 via 10.33.66.2 dev tun0 192.168.154.0/24 via 10.75.22.1 dev eth0 proto zebra metric 20 172.16.235.0/24 via 10.75.22.1 dev eth0 proto zebra metric 20 72.38.184.0/23 dev eth1 proto kernel scope link src 72.38.184.236 169.254.0.0/16 dev eth1 scope link default via 72.38.184.1 dev eth1 10.75.23.0/24 via 10.33.66.2 dev tun0 is a route through openvpn. Now I stop openvpn: # ip route ls table CGCO 24.226.1.121 dev eth1 scope link 72.38.184.1 dev eth1 scope link src 72.38.184.236 192.168.200.1 dev ppp0 proto kernel scope link src 66.11.173.224 192.168.0.0/24 via 10.75.22.137 dev eth0 proto zebra 10.75.22.0/24 dev eth0 proto kernel scope link src 10.75.22.254 192.168.154.0/24 via 10.75.22.1 dev eth0 proto zebra metric 20 172.16.235.0/24 via 10.75.22.1 dev eth0 proto zebra metric 20 72.38.184.0/23 dev eth1 proto kernel scope link src 72.38.184.236 169.254.0.0/16 dev eth1 scope link default via 72.38.184.1 dev eth1 10.75.23.0/24 route is gone. Not surprising. Now restart openvpn: # ip route ls table CGCO 24.226.1.121 dev eth1 scope link 72.38.184.1 dev eth1 scope link src 72.38.184.236 192.168.200.1 dev ppp0 proto kernel scope link src 66.11.173.224 192.168.0.0/24 via 10.75.22.137 dev eth0 proto zebra 10.75.22.0/24 dev eth0 proto kernel scope link src 10.75.22.254 192.168.154.0/24 via 10.75.22.1 dev eth0 proto zebra metric 20 172.16.235.0/24 via 10.75.22.1 dev eth0 proto zebra metric 20 72.38.184.0/23 dev eth1 proto kernel scope link src 72.38.184.236 169.254.0.0/16 dev eth1 scope link default via 72.38.184.1 dev eth1 The result of this is (tcpdump on eth1) of course: 00:07:01.643348 IP 10.75.22.1 > 10.75.23.254: ICMP echo request, id 29246, seq 601, length 64 00:07:02.642972 IP 10.75.22.1 > 10.75.23.254: ICMP echo request, id 29246, seq 602, length 64 00:07:03.643018 IP 10.75.22.1 > 10.75.23.254: ICMP echo request, id 29246, seq 603, length 64 00:07:04.643082 IP 10.75.22.1 > 10.75.23.254: ICMP echo request, id 29246, seq 604, length 64 and of course the ping is failing. And if I add the route back manually... # ip route add 10.75.23.0/24 via 10.33.66.2 dev tun0 table CGCO like magic, pinging is working again. None of this is really all that surprising. I''m just wondering what others are doing to solve it. b. -- My other computer is your Microsoft Windows server. Brian J. Murrell ------------------------------------------------------------------------- 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
Brian J. Murrell wrote:> like magic, pinging is working again. > > None of this is really all that surprising. I''m just wondering what > others are doing to solve it.So in other words, "multi-isp screws up routing" doesn''t describe your problem at all. Your problem is how to handle VPN interfaces in a multi-ISP environment -- the route_rules file was designed exactly for that purpose 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). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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
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.> the route_rules file was designed exactly for that purposeHrm. 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. :-) b. -- My other computer is your Microsoft Windows server. Brian J. Murrell ------------------------------------------------------------------------- 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
Brian J. Murrell wrote:> On Wed, 2007-02-07 at 07:23 -0800, Tom Eastep wrote:> > 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 Shorewall Multi-ISP documentation clearly states that what Shorewall provides is based on static routing and doesn''t even attempt to deal with dynamic change. It you don''t like it, you are free to use something else. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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
On Wed, 2007-02-07 at 12:10 -0800, Tom Eastep wrote:> > The Shorewall Multi-ISP documentation clearly states that what Shorewall > provides is based on static routing and doesn''t even attempt to deal > with dynamic change.Yeah.> It you don''t like it, you are free to use something > else.Of course. I have just been thinking over the last week or two on how to bring the two closer together. On a somewhat related note there is this statement in the multi-isp document: If you are using /etc/shorewall/providers because you have multiple internet connections, we recommend that you specify ''balance'' even if you don''t need it. You can still use entries in /etc/shorewall/tcrules to force traffic to one provider or another. What''s the reasoning behind this? I''m assuming that if I don''t use balance, I don''t get a default route through all providers? b. -- My other computer is your Microsoft Windows server. Brian J. Murrell ------------------------------------------------------------------------- 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
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 ------------------------------------------------------------------------- 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
Brian J. Murrell wrote:> On Wed, 2007-02-07 at 12:10 -0800, Tom Eastep wrote: >> The Shorewall Multi-ISP documentation clearly states that what Shorewall >> provides is based on static routing and doesn''t even attempt to deal >> with dynamic change. > > Yeah. > >> It you don''t like it, you are free to use something >> else. > > Of course. > > I have just been thinking over the last week or two on how to bring the > two closer together.The thing is, routing protocols have been around for a long time and together with routing daemons, provide a means for modifying your routing dynamically. If you want a less expensive option, you could also use a OpenVPN features like --route-up to add the route to your provider-specific table when the a connection is made.> > On a somewhat related note there is this statement in the multi-isp > document: > > If you are using /etc/shorewall/providers because you have > multiple internet connections, we recommend that you specify > ''balance'' even if you don''t need it. You can still use entries > in /etc/shorewall/tcrules to force traffic to one provider or > another. > > What''s the reasoning behind this? I''m assuming that if I don''t use > balance, I don''t get a default route through all providers?That piece of advice goes on to say: If you don''t heed this advice then be prepared to read FAQ 57 and FAQ 58 Have you done that? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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
On Wed, 2007-02-07 at 12:34 -0800, Tom Eastep wrote:> > The thing is, routing protocols have been around for a long time and > together with routing daemons, provide a means for modifying your routing > dynamically.Right. I guess, just as shorewall provides a nice front-end for iptables, I just wonder if there is room to encapsulate the configuration for this routing within shorewall too.> If you want a less expensive option, you could also use a OpenVPN features > like --route-up to add the route to your provider-specific table when the a > connection is made.Yeah, that is one of the options I am mulling over. :-)> That piece of advice goes on to say: > > If you don''t heed this advice then be prepared to read FAQ 57 and > FAQ 58Right. 58 is just a solution. 57 seems to indicate the kind of problem one could run into: If you don''t do that so that your main routing table only has one default route, then you must disable route filtering. Do not specify the routefilter option on the other interface(s) in /etc/shorewall/interfaces and disable any IP Address Spoofing protection that your distribution supplies. I guess the situation that having routefiltering and/or IP Address Spoofing protection enabled and causing problems is escaping me. The only situation I can think of is where a locally generated packet gets it''s source IP assigned the non-default interface address, but there are already masq''ing rules in place to fix that up.> Have you done that?I had and have been using the 58 method. b. -- My other computer is your Microsoft Windows server. Brian J. Murrell ------------------------------------------------------------------------- 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
Brian J. Murrell wrote:> > I guess the situation that having routefiltering and/or IP Address > Spoofing protection enabled and causing problems is escaping me. The > only situation I can think of is where a locally generated packet gets > it''s source IP assigned the non-default interface address, but there are > already masq''ing rules in place to fix that up.The problem is with incoming packets from the internet. If there isn''t a ''main'' default route through the incoming interface then the packets may be dropped as martians. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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
On Wed, Feb 07, 2007 at 03:58:08PM -0500, Brian J. Murrell wrote:> On Wed, 2007-02-07 at 12:34 -0800, Tom Eastep wrote: > > > > The thing is, routing protocols have been around for a long time and > > together with routing daemons, provide a means for modifying your routing > > dynamically. > > Right. I guess, just as shorewall provides a nice front-end for > iptables, I just wonder if there is room to encapsulate the > configuration for this routing within shorewall too.It''s an almost completely unrelated problem to what shorewall does, and quagga already does the job of capturing non-trivial routing setups in a set of config files quite neatly, so the answer is likely "no". (I don''t know offhand whether quagga would solve your problem, because frankly I haven''t been paying any attention to it - but it''s solved all my dynamic routing problems to date, despite being intended for far more complex scenarios, so if it doesn''t currently work in this case, any development attention would be better aimed in that direction) ------------------------------------------------------------------------- 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
On Wed, 2007-02-07 at 22:32 +0000, Andrew Suffield wrote:> > It''s an almost completely unrelated problem to what shorewall does, > and quagga already does the job of capturing non-trivial routing > setups in a set of config files quite neatly, so the answer is likely > "no".I do use quagga as well. Does it solve the problem however of ensuring that packets leave by the interface which they arrived? The only way I know of achieving this is by the connection marking that shorewall employs.> (I don''t know offhand whether quagga would solve your problem, because > frankly I haven''t been paying any attention to it - but it''s solved > all my dynamic routing problems to date, despite being intended for > far more complex scenarios, so if it doesn''t currently work in this > case, any development attention would be better aimed in that > direction)Do you have two ISP connections, each with their own "consumer-level" IP address? i.e. I am specifically not referring to a single routable address space routed via traditional (true) multi-homing where you use the same address through both providers. b. -- My other computer is your Microsoft Windows server. Brian J. Murrell ------------------------------------------------------------------------- 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
Wow.. It''s been a while... 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. >I''m just wondering how/why that route got added to the provider''s tables in the first place. You must not have an entry in the "copy from" column of the providers file (and you restarted shorewall after a vpn connection was made), which functions to limit the routes that are added from the dup''d table, to only those interfaces that are listed, to the providers'' routing tables. That is the only way that I know of which allows a route on tun0 to end up in a providers routing table.>> 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. >Unless you''re going to pass vpn traffic from tun0 to the internet, is that route even required? I have a tun interface for my vpn and no routes for tun0 are in my provider''s routing tables. Once the routing rules are added to the route_rules file, those rules should stick though a disconnect, unless the vpn up/down scripts plays with them.> 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. :-) > > b.It will, but if you have a tun0 route in both provider''s tables, nothing will work at all... Good luck, Jerry ------------------------------------------------------------------------- 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
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. > >> 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. >OTOH, I challenge you to give us a good reason for replicating your tun0 route in multiple tables rather than simply using the single copy of that route that is is automatically added to the main table by OpenVPN. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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
On Wed, 2007-02-07 at 20:32 -0800, Tom Eastep wrote:> > OTOH, I challenge you to give us a good reason for replicating your tun0 > route in multiple tables rather than simply using the single copy of > that route that is is automatically added to the main table by OpenVPN.OK. 1. I start shorewall (no openvpn yet) and provider specific routing tables are copied from main. 2. Now I start openvpn, which adds a route to the main table for the other end of the tunnel: * 10.75.23.0/24 via 10.33.66.2 dev tun0 3. Now traffic starts flowing to 10.75.23.1 I. First packet in the connection will use the main routing table and be routed to the remote correctly II. Remote will send back it''s reply in that connection and it''s arrival will mark the packet and connection according to the provider it''s received on III. Local will send it''s second packet to remote but since it''s on the connection marked for the provider it will be routed via the provider''s table (which does not have the route added in step 2) and it will end up going via the default route rather than the tun0 route. As I understand it and as my debugging has led me to believe. I think my supposition is correct because I can fix the above situation by adding that route that was added in step 2 to the provider tables. b. -- My other computer is your Microsoft Windows server. Brian J. Murrell ------------------------------------------------------------------------- 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
Brian J. Murrell wrote:> On Wed, 2007-02-07 at 20:32 -0800, Tom Eastep wrote: >> OTOH, I challenge you to give us a good reason for replicating your tun0 >> route in multiple tables rather than simply using the single copy of >> that route that is is automatically added to the main table by OpenVPN. > > OK. > > 1. I start shorewall (no openvpn yet) and provider specific routing > tables are copied from main. > 2. Now I start openvpn, which adds a route to the main table for > the other end of the tunnel: > * 10.75.23.0/24 via 10.33.66.2 dev tun0 > 3. Now traffic starts flowing to 10.75.23.1 > I. First packet in the connection will use the main routing > table and be routed to the remote correctly > II. Remote will send back it''s reply in that connection and > it''s arrival will mark the packet and connection > according to the provider it''s received on > III. Local will send it''s second packet to remote but since > it''s on the connection marked for the provider it will > be routed via the provider''s table (which does not have > the route added in step 2) and it will end up going via > the default route rather than the tun0 route. >Yup, part III is about right, that is why you need to point to a table (main) that has the route available, that is the whole point of the route_rules file.> As I understand it and as my debugging has led me to believe. I think > my supposition is correct because I can fix the above situation by > adding that route that was added in step 2 to the provider tables.Now instead of adding a route to the providers table, add an "ip rule" instead. "ip rule add to 10.75.23.0/24 pref 9999 lookup main" and retest. That is more or less an entry that could be created with the route_rules file. Working now? Jerry ------------------------------------------------------------------------- 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
On Wed, 2007-02-07 at 23:36 -0600, Jerry Vonau wrote:> > Yup, part III is about right, that is why you need to point to a table > (main) that has the route available, that is the whole point of the > route_rules file.Ahhh.> Now instead of adding a route to the providers table, add an "ip rule" > instead. "ip rule add to 10.75.23.0/24 pref 9999 lookup main" and > retest.Yeah, that does the trick.> That is more or less an entry that could be created with the > route_rules file.Now the example route_rules entry: # #SOURCE DEST PROVIDER PRIORITY # - 10.8.0.0/24 main 1000 make sense. It seems I can do exactly what you suggested above with the 9999 ip rule entry with that route_rules and not tie it to a provider. Thanx for helping me see that more clearly!> Working now?About to test the same route_rule as I did manually. I am sure it will work now. b. -- My other computer is your Microsoft Windows server. Brian J. Murrell ------------------------------------------------------------------------- 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