Hi, My set up looks like so: LAN --> (192.168.100.1) Gateway1 (global IP1) --> ISP1 LAN --> (192.168.100.2) Gateway2 (global IP2) --> ISP2 Some of my users use Gateway1 and some use Gateway2. Gateway2 is running shorewall. I have a server located on the public side of my Gateway 1 (i.e. on a global IP on ISP1). With no static routing, users who are using gateway2 are forced to go out through ISP2, travel the public internet and come back trough ISP1 to reach the server. This is obviously a waste of time and bandwidth. I add a static route on gateway2 like so: /sbin/route add -host ip.addr.of.server gw 192.168.100.1 From gateway2 itself I am able to ping ip.addr.of.server. However, users behing Gateway2 are unable to ping or otherwise connect to ip.addr.of.server. Users behind Gateway1 have no problems. My policy is as follows: loc fw ACCEPT loc all REJECT net fw REJECT all all REJECT I suspect that I must not filter packets coming to gateway2 in any way. Any ideas? S. -- "This is everybody''s fault but mine!" -- Homer J. Simpson ------------------------------------------------------- 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
>My set up looks like so: > >LAN --> (192.168.100.1) Gateway1 (global IP1) --> ISP1 >LAN --> (192.168.100.2) Gateway2 (global IP2) --> ISP2 > >Some of my users use Gateway1 and some use Gateway2. Gateway2 is >running shorewall. I have a server located on the public side of my >Gateway 1 (i.e. on a global IP on ISP1). > >With no static routing, users who are using gateway2 are forced to go >out through ISP2, travel the public internet and come back trough ISP1 >to reach the server. This is obviously a waste of time and bandwidth. > >I add a static route on gateway2 like so: >/sbin/route add -host ip.addr.of.server gw 192.168.100.1This is sort of like http://www.shorewall.net/FAQ.htm#faq2 but with no dnat required, as this route is present. Ok, your sending the traffic back out the same interface, do you have "routeback" as an option for this nic in the interface file?>From gateway2 itself I am able to ping ip.addr.of.server. However, >users behing Gateway2 are unable to ping or otherwise connect to >ip.addr.of.server. Users behind Gateway1 have no problems.You''ll need to masq this traffic back out this interface using the masq file. example in the FAQ above>My policy is as follows: > >loc fw ACCEPT >loc all REJECT >net fw REJECT >all all REJECT > >I suspect that I must not filter packets coming to gateway2 in any >way. Any ideas?Have you seen the 2 isp support in shorewall? 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_idt77&alloc_id492&op=click
On 8/3/05, Jerry Vonau <jvonau@shaw.ca> wrote:> >My set up looks like so: > This is sort of like http://www.shorewall.net/FAQ.htm#faq2 > but with no dnat required, as this route is present. > Ok, your sending the traffic back out the same interface, do you have > "routeback" as an option for this nic in the interface file?Ah, ha! Thanks. That solved the problem.> Have you seen the 2 isp support in shorewall?No. Sounds interesting. I will check it out. S. -- "This is everybody''s fault but mine!" -- Homer J. Simpson ------------------------------------------------------- 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