hello list (and martin) ;x i have now composed my final(?) policy routing design. the goals i had when beginning with this, for you that have not follow mine and martins thread, was to 1) only let 192.168.1/24 to see all routes, 2) not route between defined networks, except to and from 192.168.1/24 and 3) not defined networks should only be able to reach 192.168.1/24. this might sound simple. it wasnt for me. the solution i came up with, after days and days of thinking (and patience) was this: two routing tables, one called "ALL" that, suprisingly, held routes to all networks defined and a default route to internet. the other called "main", just for ease, that held one route to 192.168.1/24 and had a default prohibit. the one rule that exists just says "if src == 192.168.1/24 use table ALL". of course there is an additional rule, the standard one that says "from all lookup main" with a number of 32766. so, for you that doesnt understand my poor english, literally every network that passes, except from 192.168.1/24, will use the main table that just holds the route to 192.168.1/24 and the prohibit one. this so simple, something just has to be wrong. feel free to englighten me. please flame. best regards, tomas bonnedahl _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Newbe hoping this is the correct area to post. I''ve been reading the LARTC HOWTO, but at 110 pages, I am finding it difficult to know where to start. I hope you may be able to surgest a starting place to a couple of problems I am having. I am dealing with the slow end of a satelite ADSL. This is ''lumpy'', with huge latency (1 to 30 sec), 10% dropped packets, huge but intermittent bursts of packets, and generally a pile of poo. The supplier (BT) is of course no help, so we have to live with what we have. I have tried limiting the bandwidth with a Tocket Bucket Filter with almost no effect. What I think I need is to agressivelly schedule SSH and Telnet before all other TCP connections. Others I don''t care about. There are I see many scheduling options, can any member surgest how I might atchive this? The second problem I have is that my connection keeps terminating (Telnet, SSH) with ''Connection closed by foreign host'', with no message in logs. Always during streaming of data. Some part of the kernel is getting tired of waiting for the other end to respond, or possible a buffer overflow? Again, if any member may surgest how this can be countered with extream predudice, I would be extreamly greatful. Regards, Ben Clewett. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hi there, Tomas, Welcome back from your trip away! : the goals i had when beginning with this, for you that have not follow : mine and martins thread, was to : : 1) only let 192.168.1/24 to see all routes, : 2) not route between defined networks, except to and from 192.168.1/24 : 3) not defined networks should only be able to reach 192.168.1/24 : : this might sound simple. it wasnt for me. Policy routing is difficult to describe in any language. And thinking about it isn''t that easy either..... : two routing tables, one called "ALL" that, suprisingly, held routes to : all networks defined and a default route to internet. the other called : "main", just for ease, that held one route to 192.168.1/24 and had a : default prohibit. : : the one rule that exists just says "if src == 192.168.1/24 use table : ALL". of course there is an additional rule, the standard one that says : "from all lookup main" with a number of 32766. : : so, for you that doesnt understand my poor english, literally every : network that passes, except from 192.168.1/24, will use the main table : that just holds the route to 192.168.1/24 and the prohibit one. : : this so simple, something just has to be wrong. feel free to englighten : me. What an elegant solution, Tomas! I also could not believe how simple the solution appeared at first, so I wrote it down (my notes are below), and I find this a far simpler solution than anything either of us came up with before. It''s neat to see the RPDB harnessed in this way. Congratulations on your elegant solution, -Martin # -- RPDB addition # ip rule add from 192.168.1.0/24 lookup ALL # # -- implicit rule below # # ip rule add prio 32766 from all lookup main # # -- table ALL # ip route add table ALL $NETA via $ROUTERA ip route add table ALL $NETB via $ROUTERB ip route add table ALL $NETC via $ROUTERC ip route add table ALL default via $ROUTERINET # # -- table main # ip route add 192.168.1.0/24 dev eth0 ip route add default prohibit # -- all packets (to be routed) with source address of ANYWHERE # are only allowed to have destinations in 192.168.1.0/24 # -- all packets (to be routed) with source address of 192.168.1.0/24 # are allowed to connect to any network -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Thursday 06 March 2003 17:33, Ben Clewett wrote:> Newbe hoping this is the correct area to post. > > I''ve been reading the LARTC HOWTO, but at 110 pages, I am finding it > difficult to know where to start. I hope you may be able to surgest a > starting place to a couple of problems I am having. > > I am dealing with the slow end of a satelite ADSL. This is ''lumpy'', > with huge latency (1 to 30 sec), 10% dropped packets, huge but > intermittent bursts of packets, and generally a pile of poo. The > supplier (BT) is of course no help, so we have to live with what we have. > > I have tried limiting the bandwidth with a Tocket Bucket Filter with > almost no effect. > > What I think I need is to agressivelly schedule SSH and Telnet before > all other TCP connections. Others I don''t care about. There are I see > many scheduling options, can any member surgest how I might atchive this? > > The second problem I have is that my connection keeps terminating > (Telnet, SSH) with ''Connection closed by foreign host'', with no message > in logs. Always during streaming of data. Some part of the kernel is > getting tired of waiting for the other end to respond, or possible a > buffer overflow? Again, if any member may surgest how this can be > countered with extream predudice, I would be extreamly greatful.I think it''s best you create a htb setup with different classes. One of the classes needs a higher priority so the packets in that classes are send first. Next you need to put the ssh/telnet/syn/ack packets in that classes. All needed information can be found in the LARTC howto. And you can also find more info on www.docum.org. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Stef Coene wrote:> I think it''s best you create a htb setup with different classes. One of the > classes needs a higher priority so the packets in that classes are send > first. Next you need to put the ssh/telnet/syn/ack packets in that classes. > All needed information can be found in the LARTC howto. And you can also > find more info on www.docum.org.This is Hierarchical Token Bucket, explained in section 9.4.5 of the HOWTO document? I was rather hoping you were going to surgest something else, as this is not in my kernel... :) I will however check out the documentation in some more detail. There are a few unresolved questions I have on this pleasent protocol. Like I notice it claims to scale up to the available bandwidth in proporsion to the allocated bandwidth. I need to know how it calculates this bandwidth, as our link shows all the properties of the available bandwidth being proporsional to 1/S noise. Ie, unpredictable and un-averagable. I would like to know also whether HTB scales down, if bandwidth becomes throtted by our unpredictable pipe. And in either case, whether it''s possible to have a protected channel, like an admin channel, which doen''t scale up or down with the rest, staying at, say, 16kbit... All of which I will now try and find out. And then attempt to get it into my kernels at either end. :) Ben The biggest mistory of my link-from-hell is the ping. This shows either a latency of 800ms, or 1.5 seconds, or up to 30 seconds when the line goes on-hold for a while. About once every two minutes. Yet Telnet/SSH consistently give latency far far more than this, of about 10 to 60 seconds consistetly. If anybody can surgest a reason for this, I think this is likelly to be at the heart of any fix I can find... Regards again...> > Stef >_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Monday 10 March 2003 12:00, Ben Clewett wrote:> Stef Coene wrote: > > I think it''s best you create a htb setup with different classes. One of > > the classes needs a higher priority so the packets in that classes are > > send first. Next you need to put the ssh/telnet/syn/ack packets in that > > classes. All needed information can be found in the LARTC howto. And you > > can also find more info on www.docum.org. > > This is Hierarchical Token Bucket, explained in section 9.4.5 of the > HOWTO document? > > I was rather hoping you were going to surgest something else, as this is > not in my kernel... :)You can also use cbq. But htb is easier to configure. Or go for the 2.4.20 kernel. That has htb support.> I will however check out the documentation in some more detail. There > are a few unresolved questions I have on this pleasent protocol. > > Like I notice it claims to scale up to the available bandwidth in > proporsion to the allocated bandwidth. I need to know how it calculates > this bandwidth, as our link shows all the properties of the available > bandwidth being proporsional to 1/S noise. Ie, unpredictable and > un-averagable. > > I would like to know also whether HTB scales down, if bandwidth becomes > throtted by our unpredictable pipe. And in either case, whether it''s > possible to have a protected channel, like an admin channel, which > doen''t scale up or down with the rest, staying at, say, 16kbit...You can configure a protected channel with a minimum bandwidth.> All of which I will now try and find out. And then attempt to get it > into my kernels at either end. :) > > Ben > > The biggest mistory of my link-from-hell is the ping. This shows either > a latency of 800ms, or 1.5 seconds, or up to 30 seconds when the line > goes on-hold for a while. About once every two minutes. Yet Telnet/SSH > consistently give latency far far more than this, of about 10 to 60 > seconds consistetly.Have you tried screen? If you start screen, you get a virtual console. You can work in it like you normally do, but if your session is terminated, you can reconnect to the same screen session with "screen -r". Very handy if you have a faulty connection :)> If anybody can surgest a reason for this, I think this is likelly to be > at the heart of any fix I can find...I have no idea .. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
i have some additional information regarding this issue with policy routing. on the router that has policy routing implemented, read further down for more information on my gols, three ethernet interfaces exists. since the routing table ''main'' just consists of a route to 192.168.1/24 with a prohihbit 0/0, you cannot from the router reach a network that is located on some of the other interfaces than 192.168.1/24 exists on. this is because the src address in the packet will be the address of that interface which the packet will exit. according to the rules that exists in the RPDB, that address will use the routing table ''main'' which, in turn, does not have a route to that network. the solution to this would be to: 1. make (two) rules which says "if the src address of a packet is the adress of an interface, use table ''all''". (also note that im using the /32 address) 2. add, in routing table ''main'', routes to these /32 addresses. the first part here is used so that a packet could be _sent_ away correct, the second part is used so that a packets can come _back_ correct. im sure martin have some insight in this, perhaps a simpler solution? indeed, i did not think of this when implementing policy routing since i was only concerned with networks and not the router itself. i hope this will help someone struggeling with policy routing. best regards, tomas bonnedahl On Thu, Mar 06, 2003 at 04:31:42PM +0100, Tomas Bonnedahl wrote:> hello list (and martin) ;x > > i have now composed my final(?) policy routing design. > > the goals i had when beginning with this, for you that have not follow > mine and martins thread, was to 1) only let 192.168.1/24 to see all routes, > 2) not route between defined networks, except to and from 192.168.1/24 and 3) not > defined networks should only be able to reach 192.168.1/24. > > this might sound simple. it wasnt for me. > > the solution i came up with, after days and days of thinking (and patience) was > this: > > two routing tables, one called "ALL" that, suprisingly, held routes to all networks defined > and a default route to internet. the other called "main", just for ease, that held one route to > 192.168.1/24 and had a default prohibit. > > the one rule that exists just says "if src == 192.168.1/24 use table ALL". of course there is > an additional rule, the standard one that says "from all lookup main" with a number of 32766. > > so, for you that doesnt understand my poor english, literally every network that passes, except > from 192.168.1/24, will use the main table that just holds the route to 192.168.1/24 and the > prohibit one. > > > this so simple, something just has to be wrong. feel free to englighten me. > > > please flame. > > best regards, > tomas bonnedahl > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
hello again list. i have another solution to this that has some advantages over my last post. when dealing with packets and their ''coming-back'' i choosed to add routes to these networks in table ''main'', instead i can create two more rules (a total of four rules altogether) that looks like the first two but uses the to parameter unstead of the from. (they''ll just say "packets that is going to x, use table ''all''"). -tomas bonnedahl On Tue, Mar 11, 2003 at 05:32:51PM +0100, Tomas Bonnedahl wrote:> i have some additional information regarding this issue with policy routing. > > on the router that has policy routing implemented, read further down for > more information on my gols, three ethernet interfaces exists. > > since the routing table ''main'' just consists of a route to 192.168.1/24 > with a prohihbit 0/0, you cannot from the router reach a network > that is located on some of the other interfaces than 192.168.1/24 exists > on. this is because the src address in the packet will be the address of > that interface which the packet will exit. according to the rules that exists > in the RPDB, that address will use the routing table ''main'' which, in turn, > does not have a route to that network. > > the solution to this would be to: > 1. make (two) rules which says "if the src address of a packet is the adress > of an interface, use table ''all''". (also note that im using the /32 address) > 2. add, in routing table ''main'', routes to these /32 addresses. > > the first part here is used so that a packet could be _sent_ away correct, the > second part is used so that a packets can come _back_ correct. > > im sure martin have some insight in this, perhaps a simpler solution? > > indeed, i did not think of this when implementing policy routing since i was > only concerned with networks and not the router itself. > > i hope this will help someone struggeling with policy routing. > > > best regards, > tomas bonnedahl > > On Thu, Mar 06, 2003 at 04:31:42PM +0100, Tomas Bonnedahl wrote: > > hello list (and martin) ;x > > > > i have now composed my final(?) policy routing design. > > > > the goals i had when beginning with this, for you that have not follow > > mine and martins thread, was to 1) only let 192.168.1/24 to see all routes, > > 2) not route between defined networks, except to and from 192.168.1/24 and 3) not > > defined networks should only be able to reach 192.168.1/24. > > > > this might sound simple. it wasnt for me. > > > > the solution i came up with, after days and days of thinking (and patience) was > > this: > > > > two routing tables, one called "ALL" that, suprisingly, held routes to all networks defined > > and a default route to internet. the other called "main", just for ease, that held one route to > > 192.168.1/24 and had a default prohibit. > > > > the one rule that exists just says "if src == 192.168.1/24 use table ALL". of course there is > > an additional rule, the standard one that says "from all lookup main" with a number of 32766. > > > > so, for you that doesnt understand my poor english, literally every network that passes, except > > from 192.168.1/24, will use the main table that just holds the route to 192.168.1/24 and the > > prohibit one. > > > > > > this so simple, something just has to be wrong. feel free to englighten me. > > > > > > please flame. > > > > best regards, > > tomas bonnedahl > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
hello list subscribers, i may have been too cocky in my previous posts regarding this policy routing problem of mine. (my old posts in further down). the problem that i cannot reach any defined network from the router still exists. i though that would be solved when adding "from interface-address, use routing table ''all''". well, it didnt. what i can conclude, with some help from tcpdump, from this is that the router can see the routing table when trying to reach a defined network. the routing table looks pretty much like this: "network a could be reached via router x". my router does send away a arp request to router x in order to send the packet through it, and router x does indeed reply, so everything tcpdump shows is these two packets, nothing more. ''ping a'' on the router returns: root@ibus-router:~# ping 172.16.1.2 PING 172.16.1.2 (172.16.1.2): 56 octets data sendto: Network is unreachable ping: sent 64 octets to 172.16.1.2, ret=-1 i have googled on this but without any meaningful results. i was also concerned with the fact that only adding the interface address in the rules would be a problem, and it is. the arp reply from router x will be routed according to table ''main'' and thus not reach the origin address. so i simpy added router x''s address to the rules and told it to use table ''all''. i still cannot reach network a from the router. the thing i seem to think is the most difficult to understand here is that route lookup is correct, otherwise the arp request wouldnt be sent, but the packet never leaves the router. this is how i see it: 1. router is requested by me to ping network a 2. router looks in the RPDB to see which routing table to use 3. RPDB says "use table ''all''" 4. router looks after a route to network a in routing table ''all'' 5. router finds a route to network a and understands that it has to send it via router x 6. router checks arp cache, doesnt see anything for router x 7. router sends out a arp request to router x 8. router x answers with a arp reply (this is where nothing happends) 9. router _should_ compose a packet and send it to router x ip route flush cache is not a problem. any insight on this would be helpful. thank you for your time and for reading this far. best regards, tomas bonnedahl On Tue, Mar 11, 2003 at 06:07:03PM +0100, Tomas Bonnedahl wrote:> hello again list. i have another solution to this that has some > advantages over my last post. > > when dealing with packets and their ''coming-back'' i choosed to add routes > to these networks in table ''main'', instead i can create two more rules (a > total of four rules altogether) that looks like the first two but uses > the to parameter unstead of the from. (they''ll just say "packets that is going > to x, use table ''all''"). > > > -tomas bonnedahl > > On Tue, Mar 11, 2003 at 05:32:51PM +0100, Tomas Bonnedahl wrote: > > i have some additional information regarding this issue with policy routing. > > > > on the router that has policy routing implemented, read further down for > > more information on my gols, three ethernet interfaces exists. > > > > since the routing table ''main'' just consists of a route to 192.168.1/24 > > with a prohihbit 0/0, you cannot from the router reach a network > > that is located on some of the other interfaces than 192.168.1/24 exists > > on. this is because the src address in the packet will be the address of > > that interface which the packet will exit. according to the rules that exists > > in the RPDB, that address will use the routing table ''main'' which, in turn, > > does not have a route to that network. > > > > the solution to this would be to: > > 1. make (two) rules which says "if the src address of a packet is the adress > > of an interface, use table ''all''". (also note that im using the /32 address) > > 2. add, in routing table ''main'', routes to these /32 addresses. > > > > the first part here is used so that a packet could be _sent_ away correct, the > > second part is used so that a packets can come _back_ correct. > > > > im sure martin have some insight in this, perhaps a simpler solution? > > > > indeed, i did not think of this when implementing policy routing since i was > > only concerned with networks and not the router itself. > > > > i hope this will help someone struggeling with policy routing. > > > > > > best regards, > > tomas bonnedahl > > > > On Thu, Mar 06, 2003 at 04:31:42PM +0100, Tomas Bonnedahl wrote: > > > hello list (and martin) ;x > > > > > > i have now composed my final(?) policy routing design. > > > > > > the goals i had when beginning with this, for you that have not follow > > > mine and martins thread, was to 1) only let 192.168.1/24 to see all routes, > > > 2) not route between defined networks, except to and from 192.168.1/24 and 3) not > > > defined networks should only be able to reach 192.168.1/24. > > > > > > this might sound simple. it wasnt for me. > > > > > > the solution i came up with, after days and days of thinking (and patience) was > > > this: > > > > > > two routing tables, one called "ALL" that, suprisingly, held routes to all networks defined > > > and a default route to internet. the other called "main", just for ease, that held one route to > > > 192.168.1/24 and had a default prohibit. > > > > > > the one rule that exists just says "if src == 192.168.1/24 use table ALL". of course there is > > > an additional rule, the standard one that says "from all lookup main" with a number of 32766. > > > > > > so, for you that doesnt understand my poor english, literally every network that passes, except > > > from 192.168.1/24, will use the main table that just holds the route to 192.168.1/24 and the > > > prohibit one. > > > > > > > > > this so simple, something just has to be wrong. feel free to englighten me. > > > > > > > > > please flame. > > > > > > best regards, > > > tomas bonnedahl > > > _______________________________________________ > > > LARTC mailing list / LARTC@mailman.ds9a.nl > > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
i think i may know what the problem can be here. the order of what happends here is crucial, if the router wants to know what interface the packet is supposed to exit on and hence use that address as source, it needs to do a lookup in the routing table. while this is processing, the router cannot contribute a src address to the RPDB, thus the rule "from router, lookup ''main''" will not match. what will match is the rule "from all use ''main''". but ''main'' doesnt hold this route. though this does not explain the arp packets being sent between the router and router x. argh, can someone please explain this to me? regards, tomas bonnedahl On Wed, Mar 12, 2003 at 05:55:27PM +0100, Tomas Bonnedahl wrote:> hello list subscribers, i may have been too cocky in my previous posts regarding this > policy routing problem of mine. (my old posts in further down). > > the problem that i cannot reach any defined network from the router still exists. > i though that would be solved when adding "from interface-address, use routing table > ''all''". well, it didnt. > > what i can conclude, with some help from tcpdump, from this is that the router can > see the routing table when trying to reach a defined network. > > the routing table looks pretty much like this: "network a could be reached via router x". > my router does send away a arp request to router x in order to send the packet through it, and > router x does indeed reply, so everything tcpdump shows is these two packets, nothing more. > > ''ping a'' on the router returns: > > root@ibus-router:~# ping 172.16.1.2 > PING 172.16.1.2 (172.16.1.2): 56 octets data > sendto: Network is unreachable > ping: sent 64 octets to 172.16.1.2, ret=-1 > > i have googled on this but without any meaningful results. > > i was also concerned with the fact that only adding the interface address in the rules > would be a problem, and it is. the arp reply from router x will be routed according to table > ''main'' and thus not reach the origin address. so i simpy added router x''s address to the rules and > told it to use table ''all''. i still cannot reach network a from the router. > > the thing i seem to think is the most difficult to understand here is that route lookup is > correct, otherwise the arp request wouldnt be sent, but the packet never leaves the router. > > this is how i see it: > 1. router is requested by me to ping network a > 2. router looks in the RPDB to see which routing table to use > 3. RPDB says "use table ''all''" > 4. router looks after a route to network a in routing table ''all'' > 5. router finds a route to network a and understands that it has to send it via router x > 6. router checks arp cache, doesnt see anything for router x > 7. router sends out a arp request to router x > 8. router x answers with a arp reply > (this is where nothing happends) > 9. router _should_ compose a packet and send it to router x > > ip route flush cache is not a problem. > > any insight on this would be helpful. thank you for your time and for reading this far. > > > best regards, > tomas bonnedahl > > > On Tue, Mar 11, 2003 at 06:07:03PM +0100, Tomas Bonnedahl wrote: > > hello again list. i have another solution to this that has some > > advantages over my last post. > > > > when dealing with packets and their ''coming-back'' i choosed to add routes > > to these networks in table ''main'', instead i can create two more rules (a > > total of four rules altogether) that looks like the first two but uses > > the to parameter unstead of the from. (they''ll just say "packets that is going > > to x, use table ''all''"). > > > > > > -tomas bonnedahl > > > > On Tue, Mar 11, 2003 at 05:32:51PM +0100, Tomas Bonnedahl wrote: > > > i have some additional information regarding this issue with policy routing. > > > > > > on the router that has policy routing implemented, read further down for > > > more information on my gols, three ethernet interfaces exists. > > > > > > since the routing table ''main'' just consists of a route to 192.168.1/24 > > > with a prohihbit 0/0, you cannot from the router reach a network > > > that is located on some of the other interfaces than 192.168.1/24 exists > > > on. this is because the src address in the packet will be the address of > > > that interface which the packet will exit. according to the rules that exists > > > in the RPDB, that address will use the routing table ''main'' which, in turn, > > > does not have a route to that network. > > > > > > the solution to this would be to: > > > 1. make (two) rules which says "if the src address of a packet is the adress > > > of an interface, use table ''all''". (also note that im using the /32 address) > > > 2. add, in routing table ''main'', routes to these /32 addresses. > > > > > > the first part here is used so that a packet could be _sent_ away correct, the > > > second part is used so that a packets can come _back_ correct. > > > > > > im sure martin have some insight in this, perhaps a simpler solution? > > > > > > indeed, i did not think of this when implementing policy routing since i was > > > only concerned with networks and not the router itself. > > > > > > i hope this will help someone struggeling with policy routing. > > > > > > > > > best regards, > > > tomas bonnedahl > > > > > > On Thu, Mar 06, 2003 at 04:31:42PM +0100, Tomas Bonnedahl wrote: > > > > hello list (and martin) ;x > > > > > > > > i have now composed my final(?) policy routing design. > > > > > > > > the goals i had when beginning with this, for you that have not follow > > > > mine and martins thread, was to 1) only let 192.168.1/24 to see all routes, > > > > 2) not route between defined networks, except to and from 192.168.1/24 and 3) not > > > > defined networks should only be able to reach 192.168.1/24. > > > > > > > > this might sound simple. it wasnt for me. > > > > > > > > the solution i came up with, after days and days of thinking (and patience) was > > > > this: > > > > > > > > two routing tables, one called "ALL" that, suprisingly, held routes to all networks defined > > > > and a default route to internet. the other called "main", just for ease, that held one route to > > > > 192.168.1/24 and had a default prohibit. > > > > > > > > the one rule that exists just says "if src == 192.168.1/24 use table ALL". of course there is > > > > an additional rule, the standard one that says "from all lookup main" with a number of 32766. > > > > > > > > so, for you that doesnt understand my poor english, literally every network that passes, except > > > > from 192.168.1/24, will use the main table that just holds the route to 192.168.1/24 and the > > > > prohibit one. > > > > > > > > > > > > this so simple, something just has to be wrong. feel free to englighten me. > > > > > > > > > > > > please flame. > > > > > > > > best regards, > > > > tomas bonnedahl > > > > _______________________________________________ > > > > LARTC mailing list / LARTC@mailman.ds9a.nl > > > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > > > > > _______________________________________________ > > > LARTC mailing list / LARTC@mailman.ds9a.nl > > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
hello martin, i was sitting here and waiting for your answer, thank you ;x
(for ease in the migration i use table ''main'' with all routes
and table ''test''
with only routes to 192.168.1/24 and prohibit 0/0.)
root@ibus-router:~# ip rule show
0: from all lookup local
31000: from 172.16.1.2 to 195.43.36.55 lookup main
31100: from 195.43.36.55 to 172.16.1.2 lookup main
32000: from 192.168.1.0/24 lookup main
32100: from 192.168.4.0/24 lookup main
32200: from 192.168.2.0/24 lookup main
32300: from all to 192.168.4.1 lookup main
32400: from all to 192.168.2.2 lookup main
32500: from all lookup test
32766: from all lookup main
32767: from all lookup default
root@ibus-router:~# ip route show table main
192.168.4.0/24 dev eth2 scope link
192.168.2.0/24 dev eth0 scope link
192.168.1.0/24 dev eth1 scope link
10.47.17.0/24 via 192.168.2.1 dev eth0
172.16.1.0/24 via 192.168.4.2 dev eth2
10.46.23.0/24 via 192.168.2.1 dev eth0
192.168.75.0/24 via 192.168.2.1 dev eth0
10.100.0.0/16 via 192.168.2.1 dev eth0
127.0.0.0/8 dev lo scope link
default via 192.168.2.1 dev eth0
root@ibus-router:~# ip route show table test
192.168.1.0/24 dev eth1 scope link
127.0.0.0/8 dev lo scope link
prohibit default
things i like to clarify:
1. rules 31000 and 31100 is just so that one address on a defined network can
reach an
address on the internet, and that works perfect.
2. rules 32100-32400 is supposed to be so that the router can reach defined
networks, this
does not work.
3. the reason of having so many routes in table main is just plain stupid when
the default
is the same as there "via..". i will change this in a near future but
i added the networks
so that it would be more clear what i was doing.
some ascii art over the network:
internet --------------------------| fw | -- some defined
networks over ipsec
192.168.2.1/24
|
|
192.168.2.2/24
voip 192.168.4.2/24 ------ 192.168.4.1/24| router |192.168.1.1 --
LAN (192.168.1/24)
i hope you understand, please mail back if there is some more information you
would like.
thanks,
tomas
On Wed, Mar 12, 2003 at 11:54:48AM -0600, Martin A. Brown
wrote:> Tomas,
>
> I''d like to look at your problem, but need a few more details.
>
> Would you post the output of "ip rule show" and "ip route
show" "ip route
> show table all" (and any other tables.
>
> I like your sequence of 8 events....that help me understand your
> problem....
>
> Thank you,
>
> -Martin
>
> : i think i may know what the problem can be here.
> :
> : the order of what happends here is crucial, if the router wants to know
> : what interface the packet is supposed to exit on and hence use that
> : address as source, it needs to do a lookup in the routing table. while
> : this is processing, the router cannot contribute a src address to the
> : RPDB, thus the rule "from router, lookup
''main''" will not match.
> :
> : what will match is the rule "from all use
''main''". but ''main'' doesnt
> : hold this route.
> :
> : though this does not explain the arp packets being sent between the
router and router x.
> :
> :
> : argh, can someone please explain this to me?
> :
> : regards,
> : tomas bonnedahl
> :
> : On Wed, Mar 12, 2003 at 05:55:27PM +0100, Tomas Bonnedahl wrote:
> : > hello list subscribers, i may have been too cocky in my previous
posts regarding this
> : > policy routing problem of mine. (my old posts in further down).
> : >
> : > the problem that i cannot reach any defined network from the router
still exists.
> : > i though that would be solved when adding "from
interface-address, use routing table
> : > ''all''". well, it didnt.
> : >
> : > what i can conclude, with some help from tcpdump, from this is that
the router can
> : > see the routing table when trying to reach a defined network.
> : >
> : > the routing table looks pretty much like this: "network a
could be reached via router x".
> : > my router does send away a arp request to router x in order to send
the packet through it, and
> : > router x does indeed reply, so everything tcpdump shows is these
two packets, nothing more.
> : >
> : > ''ping a'' on the router returns:
> : >
> : > root@ibus-router:~# ping 172.16.1.2
> : > PING 172.16.1.2 (172.16.1.2): 56 octets data
> : > sendto: Network is unreachable
> : > ping: sent 64 octets to 172.16.1.2, ret=-1
> : >
> : > i have googled on this but without any meaningful results.
> : >
> : > i was also concerned with the fact that only adding the interface
address in the rules
> : > would be a problem, and it is. the arp reply from router x will be
routed according to table
> : > ''main'' and thus not reach the origin address. so
i simpy added router x''s address to the rules and
> : > told it to use table ''all''. i still cannot reach
network a from the router.
> : >
> : > the thing i seem to think is the most difficult to understand here
is that route lookup is
> : > correct, otherwise the arp request wouldnt be sent, but the packet
never leaves the router.
> : >
> : > this is how i see it:
> : > 1. router is requested by me to ping network a
> : > 2. router looks in the RPDB to see which routing table to use
> : > 3. RPDB says "use table ''all''"
> : > 4. router looks after a route to network a in routing table
''all''
> : > 5. router finds a route to network a and understands that it has to
send it via router x
> : > 6. router checks arp cache, doesnt see anything for router x
> : > 7. router sends out a arp request to router x
> : > 8. router x answers with a arp reply
> : > (this is where nothing happends)
> : > 9. router _should_ compose a packet and send it to router x
> : >
> : > ip route flush cache is not a problem.
> : >
> : > any insight on this would be helpful. thank you for your time and
for reading this far.
> : >
> : >
> : > best regards,
> : > tomas bonnedahl
> : >
> : >
> : > On Tue, Mar 11, 2003 at 06:07:03PM +0100, Tomas Bonnedahl wrote:
> : > > hello again list. i have another solution to this that has
some
> : > > advantages over my last post.
> : > >
> : > > when dealing with packets and their
''coming-back'' i choosed to add routes
> : > > to these networks in table ''main'', instead i
can create two more rules (a
> : > > total of four rules altogether) that looks like the first two
but uses
> : > > the to parameter unstead of the from. (they''ll just
say "packets that is going
> : > > to x, use table ''all''").
> : > >
> : > >
> : > > -tomas bonnedahl
> : > >
> : > > On Tue, Mar 11, 2003 at 05:32:51PM +0100, Tomas Bonnedahl
wrote:
> : > > > i have some additional information regarding this issue
with policy routing.
> : > > >
> : > > > on the router that has policy routing implemented, read
further down for
> : > > > more information on my gols, three ethernet interfaces
exists.
> : > > >
> : > > > since the routing table ''main'' just
consists of a route to 192.168.1/24
> : > > > with a prohihbit 0/0, you cannot from the router reach a
network
> : > > > that is located on some of the other interfaces than
192.168.1/24 exists
> : > > > on. this is because the src address in the packet will be
the address of
> : > > > that interface which the packet will exit. according to
the rules that exists
> : > > > in the RPDB, that address will use the routing table
''main'' which, in turn,
> : > > > does not have a route to that network.
> : > > >
> : > > > the solution to this would be to:
> : > > > 1. make (two) rules which says "if the src address
of a packet is the adress
> : > > > of an interface, use table ''all''".
(also note that im using the /32 address)
> : > > > 2. add, in routing table ''main'', routes
to these /32 addresses.
> : > > >
> : > > > the first part here is used so that a packet could be
_sent_ away correct, the
> : > > > second part is used so that a packets can come _back_
correct.
> : > > >
> : > > > im sure martin have some insight in this, perhaps a
simpler solution?
> : > > >
> : > > > indeed, i did not think of this when implementing policy
routing since i was
> : > > > only concerned with networks and not the router itself.
> : > > >
> : > > > i hope this will help someone struggeling with policy
routing.
> : > > >
> : > > >
> : > > > best regards,
> : > > > tomas bonnedahl
> : > > >
> : > > > On Thu, Mar 06, 2003 at 04:31:42PM +0100, Tomas Bonnedahl
wrote:
> : > > > > hello list (and martin) ;x
> : > > > >
> : > > > > i have now composed my final(?) policy routing
design.
> : > > > >
> : > > > > the goals i had when beginning with this, for you
that have not follow
> : > > > > mine and martins thread, was to 1) only let
192.168.1/24 to see all routes,
> : > > > > 2) not route between defined networks, except to and
from 192.168.1/24 and 3) not
> : > > > > defined networks should only be able to reach
192.168.1/24.
> : > > > >
> : > > > > this might sound simple. it wasnt for me.
> : > > > >
> : > > > > the solution i came up with, after days and days of
thinking (and patience) was
> : > > > > this:
> : > > > >
> : > > > > two routing tables, one called "ALL" that,
suprisingly, held routes to all networks defined
> : > > > > and a default route to internet. the other called
"main", just for ease, that held one route to
> : > > > > 192.168.1/24 and had a default prohibit.
> : > > > >
> : > > > > the one rule that exists just says "if src ==
192.168.1/24 use table ALL". of course there is
> : > > > > an additional rule, the standard one that says
"from all lookup main" with a number of 32766.
> : > > > >
> : > > > > so, for you that doesnt understand my poor english,
literally every network that passes, except
> : > > > > from 192.168.1/24, will use the main table that just
holds the route to 192.168.1/24 and the
> : > > > > prohibit one.
> : > > > >
> : > > > >
> : > > > > this so simple, something just has to be wrong. feel
free to englighten me.
> : > > > >
> : > > > >
> : > > > > please flame.
> : > > > >
> : > > > > best regards,
> : > > > > tomas bonnedahl
> : > > > > _______________________________________________
> : > > > > LARTC mailing list / LARTC@mailman.ds9a.nl
> : > > > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO:
http://lartc.org/
> : > > > >
> : > > > _______________________________________________
> : > > > LARTC mailing list / LARTC@mailman.ds9a.nl
> : > > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO:
http://lartc.org/
> : > > >
> : > > _______________________________________________
> : > > LARTC mailing list / LARTC@mailman.ds9a.nl
> : > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO:
http://lartc.org/
> : > >
> : > _______________________________________________
> : > LARTC mailing list / LARTC@mailman.ds9a.nl
> : > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO:
http://lartc.org/
> : >
> : _______________________________________________
> : LARTC mailing list / LARTC@mailman.ds9a.nl
> : http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> :
>
> --
> Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com
>
>
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hi Tomas,
: hello martin, i was sitting here and waiting for your answer, thank you
: ;x
I hope you didn''t sit there waiting for this answer!
: (for ease in the migration i use table ''main'' with all
routes and table
: ''test'' with only routes to 192.168.1/24 and prohibit 0/0.)
:
: root@ibus-router:~# ip rule show
: 0: from all lookup local
: 31000: from 172.16.1.2 to 195.43.36.55 lookup main
: 31100: from 195.43.36.55 to 172.16.1.2 lookup main
: 32000: from 192.168.1.0/24 lookup main
: 32100: from 192.168.4.0/24 lookup main
: 32200: from 192.168.2.0/24 lookup main
: 32300: from all to 192.168.4.1 lookup main
: 32400: from all to 192.168.2.2 lookup main
: 32500: from all lookup test
: 32766: from all lookup main
: 32767: from all lookup default
:
: root@ibus-router:~# ip route show table main
: 192.168.4.0/24 dev eth2 scope link
: 192.168.2.0/24 dev eth0 scope link
: 192.168.1.0/24 dev eth1 scope link
: 10.47.17.0/24 via 192.168.2.1 dev eth0
: 172.16.1.0/24 via 192.168.4.2 dev eth2
: 10.46.23.0/24 via 192.168.2.1 dev eth0
: 192.168.75.0/24 via 192.168.2.1 dev eth0
: 10.100.0.0/16 via 192.168.2.1 dev eth0
: 127.0.0.0/8 dev lo scope link
: default via 192.168.2.1 dev eth0
:
: root@ibus-router:~# ip route show table test
: 192.168.1.0/24 dev eth1 scope link
: 127.0.0.0/8 dev lo scope link
: prohibit default
:
: things i like to clarify:
: 1. rules 31000 and 31100 is just so that one address on a defined network can
reach an
: address on the internet, and that works perfect.
Looks perfect.
: 2. rules 32100-32400 is supposed to be so that the router can reach
: defined networks, this does not work.
This may be part of the "which comes first, the chicken or the egg"
scenario you alluded to in your previous mail. I''m still trying to
wrap
my mind around the intertwined relationship between source address
selection and route selection. I can''t answer your implied question
about
why this doesn''t work, nor can I answer your previous question about
the
ARP queries which never have a following ethernet frame with IP payload.
Maybe one of the people more familiar with the kernel source code can help
out here.
: 3. the reason of having so many routes in table main is just plain stupid
: when the default is the same as there "via..". i will change
this in
: a near future but i added the networks so that it would be more
: clear what i was doing.
Clarity appreciated.
: some ascii art over the network:
How about some modified ASCII art! Everybody loves ASCII....
0/0 internet -----+ +-------------+ +---- defined networks ipsec
\| fw |/ 10.47.17.0/24
+-------------+ 10.46.23.0/24
192.168.2.1/24 10.100.0.0/16
| 192.168.75.0/24
|
192.168.2.2/24
+-------------+
192.168.4.1/24 /| linux router|\ 192.168.1.1/24
/ +-------------+ +--- LAN
192.168.4.2/24 /
+------------+
| voip |
+------------+
|
+-- 172.16.1.0/24
This is what I''m able to gather from your routes and diagram, and you,
sir, have a garden of networks.
I think what you want to do on "linux router" is to try the following
(idiomatic) RPDB entry.
# ip rule add iif lo table all # -- or table main in above case
I know it seems a very simple answer, to a complex question, but I hope it
will work for you.
By the way, Tomas, did you know that you can have rule types in the RPDB,
e.g.,
# ip rule add blackhole from 192.168.4.2 to 10.0.0.0/8
# ip rule add prohibit from 10.47.17.0/24 to 172.16.1.0/24
# ip rule add unreachable from 192.168.75.0/24 to 192.168.4.0/24
OK, I know that tidbit doesn''t help you in your current troubles, but I
was hoping that the "iif lo" trick might help.
-Martin
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Wed, Mar 12, 2003 at 10:15:21PM -0600, Martin A. Brown wrote:> Hi Tomas,hello again.> I hope you didn''t sit there waiting for this answer!this time no. ;)> : things i like to clarify: > : 1. rules 31000 and 31100 is just so that one address on a defined network can reach an > : address on the internet, and that works perfect. > > Looks perfect. > > : 2. rules 32100-32400 is supposed to be so that the router can reach > : defined networks, this does not work. > > This may be part of the "which comes first, the chicken or the egg" > scenario you alluded to in your previous mail. I''m still trying to wrap > my mind around the intertwined relationship between source address > selection and route selection. I can''t answer your implied question about > why this doesn''t work, nor can I answer your previous question about the > ARP queries which never have a following ethernet frame with IP payload.exactly my thought too with the "chicken or egg". i have looked at the iproute2 src code and also the kernel route.c code but since im not that good of a programmer i couldnt make anything out of it. i may be stupid here, the arp quierys were sent when i was trying to ping the voIP network, but it _could_ have come from legatime traffic from the lan (the works) so the arp request didnt necessarily had to come in conjunction with my ping. im not sure but when we have now looked further into this, it seems possible that it was not from ping but from other traffic.> Maybe one of the people more familiar with the kernel source code can help > out here.yes. though im not sure anyone still reads this thread anymore, if anyone ever did. ;/> : some ascii art over the network: > > How about some modified ASCII art! Everybody loves ASCII.... > > 0/0 internet -----+ +-------------+ +---- defined networks ipsec > \| fw |/ 10.47.17.0/24 > +-------------+ 10.46.23.0/24 > 192.168.2.1/24 10.100.0.0/16 > | 192.168.75.0/24 > | > 192.168.2.2/24 > +-------------+ > 192.168.4.1/24 /| linux router|\ 192.168.1.1/24 > / +-------------+ +--- LAN > 192.168.4.2/24 / > +------------+ > | voip | > +------------+ > | > +-- 172.16.1.0/24 > > This is what I''m able to gather from your routes and diagram, and you, > sir, have a garden of networks.indeed true. you figured it out and made a much better outline than me.> I think what you want to do on "linux router" is to try the following > (idiomatic) RPDB entry. > > # ip rule add iif lo table all # -- or table main in above casehm. i do not have the possibility to check this right now, but i will do it as soon as possible. but i have to tell you, i really dont see what this "means" or will change. just that everything that exits (and enters?) on the loopback if will use table all?> I know it seems a very simple answer, to a complex question, but I hope it > will work for you.well, so do i ;)> By the way, Tomas, did you know that you can have rule types in the RPDB, > e.g., > > # ip rule add blackhole from 192.168.4.2 to 10.0.0.0/8 > # ip rule add prohibit from 10.47.17.0/24 to 172.16.1.0/24 > # ip rule add unreachable from 192.168.75.0/24 to 192.168.4.0/24yes, i knew that. i choosed prohibit since the blackhole just drops them on the floor and let the client time out.> OK, I know that tidbit doesn''t help you in your current troubles, but I > was hoping that the "iif lo" trick might help.ill check later today and ill mail back to you as soon as possible afterwards. thank you martin regards, tomas _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
martin, you are truly the greatest network hacker around. i works like a charm, i removed the two rules that said "from <if-address>, use table ''main''", and used the one you provided. thank you so much! best regards, tomas bonnedahl On Thu, Mar 13, 2003 at 11:27:37AM +0100, Tomas Bonnedahl wrote:> On Wed, Mar 12, 2003 at 10:15:21PM -0600, Martin A. Brown wrote: > > Hi Tomas, > > hello again. > > > I hope you didn''t sit there waiting for this answer! > > this time no. ;) > > > : things i like to clarify: > > : 1. rules 31000 and 31100 is just so that one address on a defined network can reach an > > : address on the internet, and that works perfect. > > > > Looks perfect. > > > > : 2. rules 32100-32400 is supposed to be so that the router can reach > > : defined networks, this does not work. > > > > This may be part of the "which comes first, the chicken or the egg" > > scenario you alluded to in your previous mail. I''m still trying to wrap > > my mind around the intertwined relationship between source address > > selection and route selection. I can''t answer your implied question about > > why this doesn''t work, nor can I answer your previous question about the > > ARP queries which never have a following ethernet frame with IP payload. > > exactly my thought too with the "chicken or egg". i have looked at the iproute2 > src code and also the kernel route.c code but since im not that good of a programmer > i couldnt make anything out of it. > > i may be stupid here, the arp quierys were sent when i was trying to ping the voIP > network, but it _could_ have come from legatime traffic from the lan (the works) so > the arp request didnt necessarily had to come in conjunction with my ping. im not sure > but when we have now looked further into this, it seems possible that it was not from > ping but from other traffic. > > > > Maybe one of the people more familiar with the kernel source code can help > > out here. > > yes. though im not sure anyone still reads this thread anymore, if anyone ever did. ;/ > > > > : some ascii art over the network: > > > > How about some modified ASCII art! Everybody loves ASCII.... > > > > 0/0 internet -----+ +-------------+ +---- defined networks ipsec > > \| fw |/ 10.47.17.0/24 > > +-------------+ 10.46.23.0/24 > > 192.168.2.1/24 10.100.0.0/16 > > | 192.168.75.0/24 > > | > > 192.168.2.2/24 > > +-------------+ > > 192.168.4.1/24 /| linux router|\ 192.168.1.1/24 > > / +-------------+ +--- LAN > > 192.168.4.2/24 / > > +------------+ > > | voip | > > +------------+ > > | > > +-- 172.16.1.0/24 > > > > This is what I''m able to gather from your routes and diagram, and you, > > sir, have a garden of networks. > > indeed true. you figured it out and made a much better outline than me. > > > I think what you want to do on "linux router" is to try the following > > (idiomatic) RPDB entry. > > > > # ip rule add iif lo table all # -- or table main in above case > > hm. i do not have the possibility to check this right now, but i will do it > as soon as possible. but i have to tell you, i really dont see what this "means" > or will change. just that everything that exits (and enters?) on the loopback if > will use table all? > > > I know it seems a very simple answer, to a complex question, but I hope it > > will work for you. > > well, so do i ;) > > > By the way, Tomas, did you know that you can have rule types in the RPDB, > > e.g., > > > > # ip rule add blackhole from 192.168.4.2 to 10.0.0.0/8 > > # ip rule add prohibit from 10.47.17.0/24 to 172.16.1.0/24 > > # ip rule add unreachable from 192.168.75.0/24 to 192.168.4.0/24 > > yes, i knew that. i choosed prohibit since the blackhole just drops them on the floor > and let the client time out. > > > OK, I know that tidbit doesn''t help you in your current troubles, but I > > was hoping that the "iif lo" trick might help. > > ill check later today and ill mail back to you as soon as possible afterwards. > > thank you martin > > regards, > tomas > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Excellent! : martin, you are truly the greatest network hacker around. <SMILE/> : i works like a charm, i removed the two rules that said "from : <if-address>, use table ''main''", and used the one you provided. I realized upon re-reading my post of last night, that I didn''t explain what "ip rule add iif lo" means. It is an idiom describing locally generated packets. I''m very happy that is working for you. -Martin -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/