Morning, I''ve got a /29 coming in via my main provider and a normal broadband connection from another. Most of the IPs on the /29 are proxied to the internal network. This traffic doesn''t to be connection tracked so it gets routed back out the correct interface, how I can I fix that? I tried the following in tcrules: 1:CP 66.46.199.128/29 0.0.0.0/0 But that didn''t seem to help. (And I''m a little over my head.) Thanks, A. -- Adam Sherman Technologist ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
On 7/18/05, Adam Sherman <carbon60@gmail.com> wrote:> I''ve got a /29 coming in via my main provider and a normal broadband > connection from another. > > Most of the IPs on the /29 are proxied to the internal network. > > This traffic doesn''t seem to be connection tracked so it gets routed back > out the correct interface, how I can I fix that? > > I tried the following in tcrules: > > 1:CP 66.46.199.128/29 0.0.0.0/0I also tried 1:P... I notice the following note in the documentation: "If you specify track, then connections which have had at least one packet arrive on the interface listed in the INTERFACE column have their connection mark set to the value in the MARK column." So, I would assume that the same thing needs to be done for all proxied IPs as well? If yes, how? Thanks, A. -- Adam Sherman Technologist ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
On 7/18/05, Adam Sherman <carbon60@gmail.com> wrote:> I''ve got a /29 coming in via my main provider and a normal broadband > connection from another. > > Most of the IPs on the /29 are proxied to the internal network. > > This traffic doesn''t seem to be connection tracked so it gets routed back > out the correct interface, how I can I fix that? >Just so I have it clear in my head, in the end, what is your goal? Jerry ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
On 7/19/05, Jerry Vonau <jvonau@shaw.ca> wrote:> > I''ve got a /29 coming in via my main provider and a normal broadband > > connection from another. > > > > Most of the IPs on the /29 are proxied to the internal network. > > > > This traffic doesn''t seem to be connection tracked so it gets routed back > > out the correct interface, how I can I fix that? > > Just so I have it clear in my head, in the end, what is your goal?We picked up the broadband connection to reduce the load on our "real" link for outbound traffic. I have a bunch of services running on those proxy-arp''d IPs. I want those services to be accessible via the main link, while directing most outbound traffic via the cheap broadband connection. In case it matters, I''m also directing some outbound traffic via the main link, anything that is important. Thanks, A. -- Adam Sherman Technologist ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
> Just so I have it clear in my head, in the end, what is your goal?We picked up the broadband connection to reduce the load on our "real" link for outbound traffic. I have a bunch of services running on those proxy-arp''d IPs. I want those services to be accessible via the main link, while directing most outbound traffic via the cheap broadband connection. In case it matters, I''m also directing some outbound traffic via the main link, anything that is important. You want replies that come in, to return out the same way and some slect outbound connections, on the main provider, while diverting everything else out the broadband? How do you have everything setup now? What did you try doing to make this work? It seems to me that you''d have to masq the outbounds that are using the broadband. Jerry ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
On 7/19/05, Jerry Vonau <jvonau@shaw.ca> wrote:> You want replies that come in, to return out the same way and some > slect outbound connections, on the main provider, while diverting > everything else out the broadband? How do you have everything > setup now? What did you try doing to make this work? It seems > to me that you''d have to masq the outbounds that are using the > broadband.I have succesfully setup Shorewall, using the providers file, to have most traffic go out the broadband connection while forcing certain traffic to the main link. This works now. The issue is that *inbound* connections to the proxy-ARP''d IPs do not work. Connections to the main IP that the router is using do work. Of course I need replies to the requests coming to those proxy-ARP''d IPs to go back out the main link. (Which they really should, since those systems are actually using the IP of the upstream router as gateway, via proxy.) Thanks for your help, A. -- Adam Sherman Technologist ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
Adam Sherman wrote:> On 7/19/05, Jerry Vonau <jvonau@shaw.ca> wrote: >>You want replies that come in, to return out the same way and some >>slect outbound connections, on the main provider, while diverting >>everything else out the broadband? How do you have everything >>setup now? What did you try doing to make this work? It seems >>to me that you''d have to masq the outbounds that are using the >>broadband. > > I have succesfully setup Shorewall, using the providers file, to have > most traffic go out the broadband connection while forcing certain > traffic to the main link. This works now. The issue is that *inbound* > connections to the proxy-ARP''d IPs do not work. Connections to the > main IP that the router is using do work. > > Of course I need replies to the requests coming to those proxy-ARP''d > IPs to go back out the main link. (Which they really should, since > those systems are actually using the IP of the upstream router as > gateway, via proxy.)We''re going to have to see the details of your setup in order to advise you: output of "shorewall status" along with a copy of your providers file for starters. -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
>I have succesfully setup Shorewall, using the providers file, to have >most traffic go out the broadband connection while forcing certain >traffic to the main link. This works now. The issue is that *inbound* >connections to the proxy-ARP''d IPs do not work. Connections to the >main IP that the router is using do work.Could you post the output of ip route show table <isptablename> ip rule show <isptablename> = name from providers file. Jerry ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
On 7/19/05, Tom Eastep <teastep@shorewall.net> wrote:> > Of course I need replies to the requests coming to those proxy-ARP''d > > IPs to go back out the main link. (Which they really should, since > > those systems are actually using the IP of the upstream router as > > gateway, via proxy.) > > We''re going to have to see the details of your setup in order to advise you: > output of "shorewall status" along with a copy of your providers file for > starters.Hope the attached helps. This is from my production setup with the default route going through the main link, ALST. I toggle the "balance" option in the providers file from one to the other to test running most traffic over the broadband link, RGRS. When I move the "balance" option to the RGRS line, everything works: outbound traffic, inbound traffic to the main IP (66.46.199.130), IPsec tunnels, OpenVPN tunnels, etc. Just not inbound traffic to the proxied IPs, (66.199.46.131...). Thanks, A. -- Adam Sherman Technologist
Adam Sherman wrote:> > When I move the "balance" option to the RGRS line, everything works: > outbound traffic, inbound traffic to the main IP (66.46.199.130), > IPsec tunnels, OpenVPN tunnels, etc. Just not inbound traffic to the > proxied IPs, (66.199.46.131...).Why in $INFERNO are you masquerading all of your hosts that use proxy arp??????? -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
On 7/19/05, Tom Eastep <teastep@shorewall.net> wrote:> > When I move the "balance" option to the RGRS line, everything works: > > outbound traffic, inbound traffic to the main IP (66.46.199.130), > > IPsec tunnels, OpenVPN tunnels, etc. Just not inbound traffic to the > > proxied IPs, (66.199.46.131...). > > Why in $INFERNO are you masquerading all of your hosts that use proxy arp???????I didn''t realize that''s what I was doing. So, I should modify my masq file to have one of the following in the SUBNET column: br0:!66.46.199.128/29 br0:10.100.0.0/16 Is this correct? Thank you very much for your help, A. -- Adam Sherman Technologist ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
Adam Sherman wrote:> On 7/19/05, Tom Eastep <teastep@shorewall.net> wrote: >>>When I move the "balance" option to the RGRS line, everything works: >>>outbound traffic, inbound traffic to the main IP (66.46.199.130), >>>IPsec tunnels, OpenVPN tunnels, etc. Just not inbound traffic to the >>>proxied IPs, (66.199.46.131...). >>Why in $INFERNO are you masquerading all of your hosts that use proxy arp??????? > > I didn''t realize that''s what I was doing. So, I should modify my masq > file to have one of the following in the SUBNET column: > > br0:!66.46.199.128/29 > br0:10.100.0.0/16 > > Is this correct?Yes. See if that helps. If it doesn''t then I''d like to see another "shorewall status". Thanks, -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
On 7/19/05, Tom Eastep <teastep@shorewall.net> wrote:> > br0:!66.46.199.128/29 > > br0:10.100.0.0/16 > > Yes.Which one is correct? I''d prefer the first, as I would not have to worry about every internal subnet we have. Thanks, A. -- Adam Sherman Technologist ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
Adam Sherman wrote:> On 7/19/05, Tom Eastep <teastep@shorewall.net> wrote: >>>br0:!66.46.199.128/29 >>>br0:10.100.0.0/16 >>Yes. > > Which one is correct? I''d prefer the first, as I would not have to > worry about every internal subnet we have. >You can use the first. -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
On 7/19/05, Tom Eastep <teastep@shorewall.net> wrote:> > br0:!66.46.199.128/29 > > br0:10.100.0.0/16I tried this line: eth1 br0:!66.46.199.128/29 But that gives me an error: Error: Unable to determine the routes through interface "br0:" Thanks, A. -- Adam Sherman Technologist ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
Adam Sherman wrote:> On 7/19/05, Tom Eastep <teastep@shorewall.net> wrote: >>>br0:!66.46.199.128/29 >>>br0:10.100.0.0/16 > > I tried this line: > > eth1 br0:!66.46.199.128/29 > > But that gives me an error: > > Error: Unable to determine the routes through interface "br0:" >eth1 !66.46.199.128/29 -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
On 7/19/05, Tom Eastep <teastep@shorewall.net> wrote:> >>>br0:!66.46.199.128/29 > >>>br0:10.100.0.0/16 > > > > I tried this line: > > > > eth1 br0:!66.46.199.128/29 > > > > But that gives me an error: > > > > Error: Unable to determine the routes through interface "br0:" > > > > eth1 !66.46.199.128/29That gives me: Masqueraded Networks and Hosts: Error: Unable to determine the routes through interface "" Am I screwing something else up? If I have multiple interfaces, can I just say "masquerade everything that isn''t SUBNET when exiting INTERFACE"? Thanks, A. -- Adam Sherman Technologist ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
Adam Sherman wrote:> On 7/19/05, Tom Eastep <teastep@shorewall.net> wrote: >>>>>br0:!66.46.199.128/29 >>>>>br0:10.100.0.0/16 >>>I tried this line: >>> >>>eth1 br0:!66.46.199.128/29 >>> >>>But that gives me an error: >>> >>>Error: Unable to determine the routes through interface "br0:" >>> >>eth1 !66.46.199.128/29 > > That gives me: > > Masqueraded Networks and Hosts: > Error: Unable to determine the routes through interface "" > > Am I screwing something else up? > > If I have multiple interfaces, can I just say "masquerade everything > that isn''t SUBNET when exiting INTERFACE"?Sorry -- I''ll get it right sooner or later: eth1 0.0.0.0/0!66.46.199.128/29 -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
On 7/19/05, Tom Eastep <teastep@shorewall.net> wrote:> eth1 0.0.0.0/0!66.46.199.128/29That makes sense. I''ve changed my masq settings as suggested, moved the "balance" option to the secondary broadband connection an restarted Shorewall. Same symptoms as before, trying to reach a proxy-ARP''d IP doesn''t work. New status file attached. Thanks, A. -- Adam Sherman Technologist
Adam Sherman wrote:> On 7/19/05, Tom Eastep <teastep@shorewall.net> wrote: >>eth1 0.0.0.0/0!66.46.199.128/29 > > That makes sense. I''ve changed my masq settings as suggested, moved > the "balance" option to the secondary broadband connection an > restarted Shorewall. Same symptoms as before, trying to reach a > proxy-ARP''d IP doesn''t work. > > New status file attached. >Adam, you are still masquerading your proxy arp''d hosts to the internet (interface eth0.5). -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
Tom Eastep wrote:> Adam Sherman wrote: >>On 7/19/05, Tom Eastep <teastep@shorewall.net> wrote: >>>eth1 0.0.0.0/0!66.46.199.128/29 >>That makes sense. I''ve changed my masq settings as suggested, moved >>the "balance" option to the secondary broadband connection an >>restarted Shorewall. Same symptoms as before, trying to reach a >>proxy-ARP''d IP doesn''t work. >> >>New status file attached. >> > > Adam, you are still masquerading your proxy arp''d hosts to the internet > (interface eth0.5). >Now that I''ve had my coffee, I see that such masquerading is necessary. Please turn off rp_filter on all interfaces and see if that helps. -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
On 7/20/05, Tom Eastep <teastep@shorewall.net> wrote:> Please turn off rp_filter on all interfaces and see if that helps.I''ll need to wait until tonight to try that. In other news, with the changed masq entry, all traffic from the local zone to remote IPsec tunnels is getting through, which is weird. Traffic from the route to the remote zones works fine though. Reverting to the "eth1 br0" masq line fixes the problem. Huh? Thanks, A. -- Adam Sherman Technologist ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
Adam Sherman wrote:> On 7/20/05, Tom Eastep <teastep@shorewall.net> wrote: >>Please turn off rp_filter on all interfaces and see if that helps. > > I''ll need to wait until tonight to try that.I have now set up a test bed for multi-ISP support (although both interfaces go to the same ISP). I''m having no problems accessing my Proxy ARP host from the Internet. One thing that I am doing that is different from you. I am running the code from CVS which has a COPY column in the providers file. In that column, I''m excluding the interface to the other provider.> > In other news, with the changed masq entry, all traffic from the local > zone to remote IPsec tunnels is getting through, which is weird. > Traffic from the route to the remote zones works fine though. > Reverting to the "eth1 br0" masq line fixes the problem. Huh?I''m totally unable to parse/digest that paragraph. -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
On 7/20/05, Tom Eastep <teastep@shorewall.net> wrote:> > In other news, with the changed masq entry, all traffic from the local > > zone to remote IPsec tunnels is getting through, which is weird. > > Traffic from the route to the remote zones works fine though. > > Reverting to the "eth1 br0" masq line fixes the problem. Huh? > > I''m totally unable to parse/digest that paragraph.Sorry, that should read that traffic is not going through. A. -- Adam Sherman Technologist ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
Adam Sherman wrote:> On 7/20/05, Tom Eastep <teastep@shorewall.net> wrote: >>>In other news, with the changed masq entry, all traffic from the local >>>zone to remote IPsec tunnels is getting through, which is weird. >>>Traffic from the route to the remote zones works fine though. >>>Reverting to the "eth1 br0" masq line fixes the problem. Huh? >>I''m totally unable to parse/digest that paragraph. > > Sorry, that should read that traffic is not going through.Ok -- that looks like a bug that''s been there since 2.4.0. I have to be out of the office today but I''ll get you a fix asap. -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
On 7/20/05, Tom Eastep <teastep@shorewall.net> wrote:> >>>In other news, with the changed masq entry, all traffic from the local > >>>zone to remote IPsec tunnels is getting through, which is weird. > >>>Traffic from the route to the remote zones works fine though. > >>>Reverting to the "eth1 br0" masq line fixes the problem. Huh? > >>I''m totally unable to parse/digest that paragraph. > > > > Sorry, that should read that traffic is not going through. > > Ok -- that looks like a bug that''s been there since 2.4.0. I have to be out > of the office today but I''ll get you a fix asap.Wow, I''m amazed you can devine that from the small amount of info I provided! No rush on the fix though, this is only enabling us to use our bandwidth more effiently in the future. Thanks again, A. -- Adam Sherman Technologist ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
On 7/20/05, Tom Eastep <teastep@shorewall.net> wrote:> >>Please turn off rp_filter on all interfaces and see if that helps.> I have now set up a test bed for multi-ISP support (although both interfaces > go to the same ISP). I''m having no problems accessing my Proxy ARP host from > the Internet.This is with rp_filter on or off?> One thing that I am doing that is different from you. I am running the code > from CVS which has a COPY column in the providers file. In that column, I''m > excluding the interface to the other provider.What does that mean, exactly? Thanks, A. -- Adam Sherman Technologist ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
Adam Sherman wrote:>>>Sorry, that should read that traffic is not going through. >>Ok -- that looks like a bug that''s been there since 2.4.0. I have to be out >>of the office today but I''ll get you a fix asap. > > Wow, I''m amazed you can devine that from the small amount of info I > provided! No rush on the fix though, this is only enabling us to use > our bandwidth more effiently in the future. >Attached is a patch for /usr/share/shorewall/firewall -- should apply although there will probably be an offset. -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
On 7/20/05, Tom Eastep <teastep@shorewall.net> wrote:> Attached is a patch for /usr/share/shorewall/firewall -- should apply > although there will probably be an offset.I have no copy_and_edit_table function in my firewall. Guess I need a newer version than 2.4.0? The second hunk applies cleanly with an offset. Thanks, A. -- Adam Sherman Technologist ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
Adam Sherman wrote:> On 7/20/05, Tom Eastep <teastep@shorewall.net> wrote: >>Attached is a patch for /usr/share/shorewall/firewall -- should apply >>although there will probably be an offset. > > I have no copy_and_edit_table function in my firewall. Guess I need a > newer version than 2.4.0? The second hunk applies cleanly with an > offset. >Don''t worry about the first hunk then. -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
> >>Please turn off rp_filter on all interfaces and see if that helps.> I have now set up a test bed for multi-ISP support (although bothinterfaces> go to the same ISP). I''m having no problems accessing my Proxy ARP hostfrom> the Internet.This is with rp_filter on or off? I believe Tom meant off.> One thing that I am doing that is different from you. I am running thecode> from CVS which has a COPY column in the providers file. In that column,I''m> excluding the interface to the other provider.What does that mean, exactly? When shorewall creates the routing table for the provider, and you have "main" in the dupicate column, the main table is just copied over to both providers. When you have entries in the "copy" column just the provider''s route and the routes from the interfaces listed in "copy" are created. Jerry ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
On 7/20/05, Tom Eastep <teastep@shorewall.net> wrote:> >>Attached is a patch for /usr/share/shorewall/firewall -- should apply > >>although there will probably be an offset.Disabling rp_filter on all my interfaces (by removing the routefilter option), changing the masq file as you suggested and applying your patch seems to have made everything work as originaly desired! Thank you *very* much. This is great! A. P.S. The Shorewall documention makes no mention of "rp_filter" being what "routefilter" actually does, might be wise to mention that. -- Adam Sherman Technologist ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click