Mike Lander wrote:> I am building a shorewall box that the last post has the SSH error and > wanted > some feedback from the list if possible. At first I thought the two ISP''s > I > building this > for had two T-1''s with FQ ip''s as it. I have the box built for this ready > to > go. > Now I find out that one of the T-1''s is non-routed with 5 useable ips > /29--Good > the other T-1 is natted in using one of the local lan Ip''s. Both full > T-1''s-----Not so Good > The Idea is to load balance and route specific stuff like mail etc: > The second ISP will NOT give me a FQ ip. Shorewall fits the bill > perfect for this need. > Currently the network is using routeback and static routes > to route specific traffic to the natted ISP gateway. The only solution I > could > think of was, I asked the ISP if they could change the currently > natted gateway (lan ip on internal) to a different Class 3 IP such as > 10.15.75.1 > then I could configure my second ISP to the same network > 10.15.75.2 and track and balance the routes. > Now would there be a better way to do this and leave the > Natted ISP with the same IP as the lan (loc) if ??I''d really need to see the routing tables and route rules from a shorewall dump to have a better understanding of your layout. Having said that, when you use the providers file, there will be a host route to that isp''s gateway created in that isp''s routing table, which should override any network route using that address space. In short it should work without changing any addressing, I have that running now: Table LOC: 10.3.0.1 dev eth0 scope link src 10.3.0.75 <<==host route to gateway10.3.0.0/24 dev eth0 proto kernel scope link src 10.3.0.75 default via 10.3.0.1 dev eth0 Table SHAW: 24.78.192.1 dev eth1 scope link src 24.78.192.197 10.3.0.0/24 dev eth0 proto kernel scope link src 10.3.0.75 24.78.192.0/23 dev eth1 proto kernel scope link src 24.78.192.197 169.254.0.0/16 dev eth1 scope link default via 24.78.192.1 dev eth1 Table main: 10.3.0.0/24 dev eth0 proto kernel scope link src 10.3.0.75 24.78.192.0/23 dev eth1 proto kernel scope link src 24.78.192.197 169.254.0.0/16 dev eth1 scope link default nexthop via 24.78.192.1 dev eth1 weight 1 nexthop via 10.3.0.1 dev eth0 weight 1 So any thing that uses the "loc" addressing would hit this route rule: 20256: from 10.3.0.75 lookup LOC and then use the LOC routing table where there is the host route to the gateway. Having 1 (like me, I trust my loc zone) or 2 interfaces (much safer, I had that setup too, till the nic died, too lazy to change it.) for that address space should not matter, as long as that host route is present, the traffic *should* find the gateway. There might be other things that I had to do to pull this off, but I just can''t recall what, if any, at the moment. < Just saw Tom''s post, I don''t type or copy&paste that fast...> Just because I have this working doesn''t diminish Tom''s warning about routing/ARP hell, (Think my fire is out now, it been a couple of years ;) ) you have been warned... Think I had to use a /32 mask on the nic that was connected to the gateway in the 2 interface setup, so there would be no network route present for it, just the above host route to the gateway. Hope it helps, Jerry I Have this setup as Jerry suggested above and I am not sure How to masqerade the loc isp. Also it is not clear to me which interface (nic) Jerry is reffering to apply a /32 mask on. also posted routing below Here is the config I have now? /etc/shorewall providers loc 1 256 main eth1 10.194.79.254 track,balance eth1 atg 2 512 main eth0 66.224.62.97 track,balance eth1 /etc/shorewall/masq eth0 10.194.79.181 66.224.62.120 eth1 66.224.62.120 10.194.79.181 eth0 eth1 66.224.62.120 eth1 eth1 10.194.79.181 ns5:~ # shorewall show routing Can''t determine the IP address of eth2 Shorewall 4.0.2 Routing at ns5 - Fri Aug 31 12:32:42 PDT 2007 Routing Rules 0: from all lookup local 10256: from all fwmark 0x100 lookup loc 10512: from all fwmark 0x200 lookup atg 32766: from all lookup main 32767: from all lookup default Table atg: 66.224.62.97 dev eth0 scope link src 66.224.62.120 10.194.79.0/24 dev eth1 proto kernel scope link src 10.194.79.181 default via 66.224.62.97 dev eth0 Table default: Table loc: 10.194.79.254 dev eth1 scope link src 10.194.79.181 10.194.79.0/24 dev eth1 proto kernel scope link src 10.194.79.181 default via 10.194.79.254 dev eth1 Table local: broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 broadcast 66.224.62.96 dev eth0 proto kernel scope link src 66.224.62.120 broadcast 10.194.79.0 dev eth1 proto kernel scope link src 10.194.79.181 local 10.194.79.181 dev eth1 proto kernel scope host src 10.194.79.181 local 66.224.62.120 dev eth0 proto kernel scope host src 66.224.62.120 broadcast 66.224.62.127 dev eth0 proto kernel scope link src 66.224.62.120 broadcast 10.194.79.255 dev eth1 proto kernel scope link src 10.194.79.181 broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 Table main: 66.224.62.96/27 dev eth0 proto kernel scope link src 66.224.62.120 10.194.79.0/24 dev eth1 proto kernel scope link src 10.194.79.181 169.254.0.0/16 dev eth0 scope link 127.0.0.0/8 dev lo scope link default nexthop via 10.194.79.254 dev eth1 weight 1 nexthop via 66.224.62.97 dev eth0 weight 1 ns5:~ # ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
----- Original Message ----- From: "Mike Lander" <landers@lanlinecomputers.com> To: "Shorewall" <shorewall-users@lists.sourceforge.net> Sent: Thursday, August 30, 2007 12:38 PM Subject: [Shorewall-users] Multi-Isp Masqerade ? : Mike Lander wrote: : > I am building a shorewall box that the last post has the SSH error and : > wanted : > some feedback from the list if possible. At first I thought the two ISP''s : > I : > building this : > for had two T-1''s with FQ ip''s as it. I have the box built for this ready : > to : > go. : > Now I find out that one of the T-1''s is non-routed with 5 useable ips : > /29--Good : > the other T-1 is natted in using one of the local lan Ip''s. Both full : > T-1''s-----Not so Good : > The Idea is to load balance and route specific stuff like mail etc: : > The second ISP will NOT give me a FQ ip. Shorewall fits the bill : > perfect for this need. : > Currently the network is using routeback and static routes : > to route specific traffic to the natted ISP gateway. The only solution I : > could : > think of was, I asked the ISP if they could change the currently : > natted gateway (lan ip on internal) to a different Class 3 IP such as : > 10.15.75.1 : > then I could configure my second ISP to the same network : > 10.15.75.2 and track and balance the routes. : > Now would there be a better way to do this and leave the : > Natted ISP with the same IP as the lan (loc) if ?? : : I''d really need to see the routing tables and route rules from a : shorewall dump to have a better understanding of your layout. Having : said that, when you use the providers file, there will be a host route : to that isp''s gateway created in that isp''s routing table, which should : override any network route using that address space. In short it should : work without changing any addressing, I have that running now: : : Table LOC: : : 10.3.0.1 dev eth0 scope link src 10.3.0.75 <<==host route to gateway: 10.3.0.0/24 dev eth0 proto kernel scope link src 10.3.0.75 : default via 10.3.0.1 dev eth0 : : : Table SHAW: : : 24.78.192.1 dev eth1 scope link src 24.78.192.197 : 10.3.0.0/24 dev eth0 proto kernel scope link src 10.3.0.75 : 24.78.192.0/23 dev eth1 proto kernel scope link src 24.78.192.197 : 169.254.0.0/16 dev eth1 scope link : default via 24.78.192.1 dev eth1 : : Table main: : : 10.3.0.0/24 dev eth0 proto kernel scope link src 10.3.0.75 : 24.78.192.0/23 dev eth1 proto kernel scope link src 24.78.192.197 : 169.254.0.0/16 dev eth1 scope link : default : nexthop via 24.78.192.1 dev eth1 weight 1 : nexthop via 10.3.0.1 dev eth0 weight 1 : : So any thing that uses the "loc" addressing would hit this route rule: : : 20256: from 10.3.0.75 lookup LOC : : and then use the LOC routing table where there is the host route to the : gateway. Having 1 (like me, I trust my loc zone) or 2 interfaces (much : safer, I had that setup too, till the nic died, too lazy to change it.) : for that address space should not matter, as long as that host route is : present, the traffic *should* find the gateway. There might be other : things that I had to do to pull this off, but I just can''t recall what, : if any, at the moment. : < Just saw Tom''s post, I don''t type or copy&paste that fast...> : : Just because I have this working doesn''t diminish Tom''s warning about : routing/ARP hell, (Think my fire is out now, it been a couple of years : ;) ) you have been warned... : : Think I had to use a /32 mask on the nic that was connected to the : gateway in the 2 interface setup, so there would be no network route : present for it, just the above host route to the gateway. : : : Hope it helps, : : Jerry : : : I Have this setup as Jerry suggested above : and I am not sure How to masqerade the : loc isp. Also it is not clear to : me which interface (nic) Jerry is : reffering to apply a /32 mask on. : also posted routing below : Here is the config I have now? : : : /etc/shorewall providers : loc 1 256 main eth1 10.194.79.254 track,balance eth1 : atg 2 512 main eth0 66.224.62.97 track,balance eth1 : : /etc/shorewall/masq : eth0 10.194.79.181 66.224.62.120 : eth1 66.224.62.120 10.194.79.181 : eth0 eth1 66.224.62.120 : eth1 eth1 10.194.79.181 : : : ns5:~ # shorewall show routing : Can''t determine the IP address of eth2 : Shorewall 4.0.2 Routing at ns5 - Fri Aug 31 12:32:42 PDT 2007 : : : Routing Rules : : 0: from all lookup local : 10256: from all fwmark 0x100 lookup loc : 10512: from all fwmark 0x200 lookup atg : 32766: from all lookup main : 32767: from all lookup default : : Table atg: : : 66.224.62.97 dev eth0 scope link src 66.224.62.120 : 10.194.79.0/24 dev eth1 proto kernel scope link src 10.194.79.181 : default via 66.224.62.97 dev eth0 : : Table default: : : : Table loc: : : 10.194.79.254 dev eth1 scope link src 10.194.79.181 : 10.194.79.0/24 dev eth1 proto kernel scope link src 10.194.79.181 : default via 10.194.79.254 dev eth1 : : Table local: : : broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 : broadcast 66.224.62.96 dev eth0 proto kernel scope link src 66.224.62.120 : broadcast 10.194.79.0 dev eth1 proto kernel scope link src 10.194.79.181 : local 10.194.79.181 dev eth1 proto kernel scope host src 10.194.79.181 : local 66.224.62.120 dev eth0 proto kernel scope host src 66.224.62.120 : broadcast 66.224.62.127 dev eth0 proto kernel scope link src : 66.224.62.120 : broadcast 10.194.79.255 dev eth1 proto kernel scope link src : 10.194.79.181 : broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 : local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 : local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 : : Table main: : : 66.224.62.96/27 dev eth0 proto kernel scope link src 66.224.62.120 : 10.194.79.0/24 dev eth1 proto kernel scope link src 10.194.79.181 : 169.254.0.0/16 dev eth0 scope link : 127.0.0.0/8 dev lo scope link : default : nexthop via 10.194.79.254 dev eth1 weight 1 : nexthop via 66.224.62.97 dev eth0 weight 1 : ns5:~ # : : Sorry noticed a typo in my masq I have : /etc/shorewall/masq : eth0 10.194.79.181 66.224.62.120 : eth1 66.224.62.120 10.194.79.181 : eth0 eth1 66.224.62.120 : eth1 eth0 10.194.79.181 Mike ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Mike Lander wrote:> > : /etc/shorewall/masq > : eth0 10.194.79.181 66.224.62.120 > : eth1 66.224.62.120 10.194.79.181 > : eth0 eth1 66.224.62.120 > : eth1 eth0 10.194.79.181The last two entries appear to me to be totally silly. Please stop and think a minute about what those entries are asking the firewall to do. The first one says that "any traffic from a host with a route out of eth1 that is being forwarded out of eth0 should have its source address rewritten to 66.224.62.120". Why would any traffic be taking that path at all? The second rule is similar... Am I missing something? -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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Mike Lander wrote:> > : /etc/shorewall/masq > : eth0 10.194.79.181 66.224.62.120 > : eth1 66.224.62.120 10.194.79.181 > : eth0 eth1 66.224.62.120 > : eth1 eth0 10.194.79.181The last two entries appear to me to be totally silly. Please stop and think a minute about what those entries are asking the firewall to do. The first one says that "any traffic from a host with a route out of eth1 that is being forwarded out of eth0 should have its source address rewritten to 66.224.62.120". Why would any traffic be taking that path at all? The second rule is similar... Am I missing something? -Tom Well in the mulit-Isp setup this is the convention to take with two isp two nics FQip That is why I am confused on how to masq from loc to the net with one nic FQip 66.224.62.120 and the other fowarding to the gw 10.194.79.254 on the internal lan. My thought about the lan is not to masq at all, any ideas? But you answer sure make me think about it more clear. Thanks Mike ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Mike Lander wrote:> Mike Lander wrote: > >> : /etc/shorewall/masq >> : eth0 10.194.79.181 66.224.62.120 >> : eth1 66.224.62.120 10.194.79.181 >> : eth0 eth1 66.224.62.120 >> : eth1 eth0 10.194.79.181 > > The last two entries appear to me to be totally silly. > > Please stop and think a minute about what those entries are asking the > firewall to do. The first one says that "any traffic from a host with a > route out of eth1 that is being forwarded out of eth0 should have its source > address rewritten to 66.224.62.120". Why would any traffic be taking that > path at all? The second rule is similar... > > Am I missing something? > > -Tom > > Well in the mulit-Isp setup this is the convention > to take with two isp two nics FQip > That is why I am confused on how to masq > from loc to the net with one nic FQip 66.224.62.120 > and the other fowarding to the gw 10.194.79.254 > on the internal lan. My thought about the lan > is not to masq at all, any ideas? > But you answer sure make me think about > it more clear.If there is a local LAN here, which interface is it connected to? All you have shown us is eth0 and eth1 which appear to go to the two providers. Please don''t tell me that ''the LAN'' is also accessed through one of those interfaces.... -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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
----- Original Message -----
From: "Mike Lander" <landers@lanlinecomputers.com>
To: "Shorewall Users" <shorewall-users@lists.sourceforge.net>
Sent: Thursday, August 30, 2007 1:09 PM
Subject: Re: [Shorewall-users] Multi-Isp Masqerade ?
: Mike Lander wrote:
:
: >
: > : /etc/shorewall/masq
: > : eth0 10.194.79.181 66.224.62.120
: > : eth1 66.224.62.120 10.194.79.181
: > : eth0 eth1 66.224.62.120
: > : eth1 eth0 10.194.79.181
:
: The last two entries appear to me to be totally silly.
:
: Please stop and think a minute about what those entries are asking the
: firewall to do. The first one says that "any traffic from a host with a
: route out of eth1 that is being forwarded out of eth0 should have its
source
: address rewritten to 66.224.62.120". Why would any traffic be taking that
: path at all? The second rule is similar...
:
: Am I missing something?
:
: -Tom
:
: Well in the mulit-Isp setup this is the convention
: to take with two isp two nics FQip
: That is why I am confused on how to masq
: from loc to the net with one nic FQip 66.224.62.120
: and the other fowarding to the gw 10.194.79.254
: on the internal lan. My thought about the lan
: is not to masq at all, any ideas?
: But you answer sure make me think about
: it more clear.
:
: Thanks
: Mike
:
:
Tom
This is what I think it should be
eth0 eth1 66.224.62.120
eth1 eth1 10.194.79.181
Mike
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Mike Lander wrote:> Mike Lander wrote: > >> : /etc/shorewall/masq >> : eth0 10.194.79.181 66.224.62.120 >> : eth1 66.224.62.120 10.194.79.181 >> : eth0 eth1 66.224.62.120 >> : eth1 eth0 10.194.79.181 > > The last two entries appear to me to be totally silly. > > Please stop and think a minute about what those entries are asking the > firewall to do. The first one says that "any traffic from a host with a > route out of eth1 that is being forwarded out of eth0 should have its > source > address rewritten to 66.224.62.120". Why would any traffic be taking that > path at all? The second rule is similar... > > Am I missing something? > > -Tom > > Well in the mulit-Isp setup this is the convention > to take with two isp two nics FQip > That is why I am confused on how to masq > from loc to the net with one nic FQip 66.224.62.120 > and the other fowarding to the gw 10.194.79.254 > on the internal lan. My thought about the lan > is not to masq at all, any ideas? > But you answer sure make me think about > it more clear.If there is a local LAN here, which interface is it connected to? All you have shown us is eth0 and eth1 which appear to go to the two providers. Please don''t tell me that ''the LAN'' is also accessed through one of those interfaces.... -Tom -- Well I thought I could access both T-1''s in this config in my previous post, the admin led me to believe. But as it turns out both these ISP''s (two full T-1''s are in seperate buildings) and connected by one run of Fiber. So Jerry seemed optimistic this config would work as his does. I have two nics in a test enviroment with the same setup at my place. eth0 66.224.62.120/27--gw 66.224.62.97 eth1 10.194.79.181- gw 10.194.79.254 I will send dump if you like. Mike ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
----- Original Message ----- From: "Mike Lander" <landers@lanlinecomputers.com> To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> Sent: Thursday, August 30, 2007 1:32 PM Subject: Re: [Shorewall-users] Multi-Isp Masqerade ? : Mike Lander wrote: : > Mike Lander wrote: : > : >> : /etc/shorewall/masq : >> : eth0 10.194.79.181 66.224.62.120 : >> : eth1 66.224.62.120 10.194.79.181 : >> : eth0 eth1 66.224.62.120 : >> : eth1 eth0 10.194.79.181 : > : > The last two entries appear to me to be totally silly. : > : > Please stop and think a minute about what those entries are asking the : > firewall to do. The first one says that "any traffic from a host with a : > route out of eth1 that is being forwarded out of eth0 should have its : > source : > address rewritten to 66.224.62.120". Why would any traffic be taking that : > path at all? The second rule is similar... : > : > Am I missing something? : > : > -Tom : > : > Well in the mulit-Isp setup this is the convention : > to take with two isp two nics FQip : > That is why I am confused on how to masq : > from loc to the net with one nic FQip 66.224.62.120 : > and the other fowarding to the gw 10.194.79.254 : > on the internal lan. My thought about the lan : > is not to masq at all, any ideas? : > But you answer sure make me think about : > it more clear. : : If there is a local LAN here, which interface is it connected to? All you : have shown us is eth0 and eth1 which appear to go to the two providers. : Please don''t tell me that ''the LAN'' is also accessed through one of those : interfaces.... : : -Tom : -- : Well I thought I could access both T-1''s in this config in my previous : post, the admin led me to believe. : But as it turns out both these ISP''s (two full T-1''s are in seperate : buildings) : and connected by one run of Fiber. So Jerry seemed optimistic this config : would work as his does. : I have two nics in a test enviroment with the same setup at my place. : : eth0 66.224.62.120/27--gw 66.224.62.97 : eth1 10.194.79.181- gw 10.194.79.254 : I will send dump if you like. : : Mike : : Here is the dump Thanks Mike : : : : ------------------------------------------------------------------------- : This SF.net email is sponsored by: Splunk Inc. : Still grepping through log files to find problems? Stop. : Now Search log events and configuration files using AJAX and a browser. : Download your FREE copy of Splunk now >> http://get.splunk.com/ : _______________________________________________ : Shorewall-users mailing list : Shorewall-users@lists.sourceforge.net : https://lists.sourceforge.net/lists/listinfo/shorewall-users : ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
----- Original Message ----- From: "Mike Lander" <landers@lanlinecomputers.com> To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> Sent: Thursday, August 30, 2007 1:39 PM Subject: Re: [Shorewall-users] Multi-Isp Masqerade ? : : ----- Original Message ----- : From: "Mike Lander" <landers@lanlinecomputers.com> : To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> : Sent: Thursday, August 30, 2007 1:32 PM : Subject: Re: [Shorewall-users] Multi-Isp Masqerade ? : : :: Mike Lander wrote: :: > Mike Lander wrote: :: > :: >> : /etc/shorewall/masq :: >> : eth0 10.194.79.181 66.224.62.120 :: >> : eth1 66.224.62.120 10.194.79.181 :: >> : eth0 eth1 66.224.62.120 :: >> : eth1 eth0 10.194.79.181 :: > :: > The last two entries appear to me to be totally silly. :: > :: > Please stop and think a minute about what those entries are asking the :: > firewall to do. The first one says that "any traffic from a host with a :: > route out of eth1 that is being forwarded out of eth0 should have its :: > source :: > address rewritten to 66.224.62.120". Why would any traffic be taking : that :: > path at all? The second rule is similar... :: > :: > Am I missing something? :: > :: > -Tom :: > :: > Well in the mulit-Isp setup this is the convention :: > to take with two isp two nics FQip :: > That is why I am confused on how to masq :: > from loc to the net with one nic FQip 66.224.62.120 :: > and the other fowarding to the gw 10.194.79.254 :: > on the internal lan. My thought about the lan :: > is not to masq at all, any ideas? :: > But you answer sure make me think about :: > it more clear. :: :: If there is a local LAN here, which interface is it connected to? All you :: have shown us is eth0 and eth1 which appear to go to the two providers. :: Please don''t tell me that ''the LAN'' is also accessed through one of those :: interfaces.... :: :: -Tom :: -- :: Well I thought I could access both T-1''s in this config in my previous :: post, the admin led me to believe. :: But as it turns out both these ISP''s (two full T-1''s are in seperate :: buildings) :: and connected by one run of Fiber. So Jerry seemed optimistic this config :: would work as his does. :: I have two nics in a test enviroment with the same setup at my place. :: :: eth0 66.224.62.120/27--gw 66.224.62.97 :: eth1 10.194.79.181- gw 10.194.79.254 :: I will send dump if you like. :: :: Mike :: :: Here is the dump : Thanks : Mike :: Now I am thinking that does not make sense at all my thought is the traffic coming from the natted gateway is already masqeraded/ just masqerade the eth1 to eth0 traffic so maybe its simple as below /etc/shorewall masqerade eth0 eth1 Does that make sense? Mike ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
----- Original Message -----
From: "Mike Lander" <landers@lanlinecomputers.com>
To: "Shorewall Users" <shorewall-users@lists.sourceforge.net>
Sent: Thursday, August 30, 2007 1:47 PM
Subject: Re: [Shorewall-users] Multi-Isp Masqerade ?
::: Mike Lander wrote:
::: > Mike Lander wrote:
::: >
::: >> : /etc/shorewall/masq
::: >> : eth0 10.194.79.181 66.224.62.120
::: >> : eth1 66.224.62.120 10.194.79.181
::: >> : eth0 eth1 66.224.62.120
::: >> : eth1 eth0 10.194.79.181
::: >
::: > The last two entries appear to me to be totally silly.
::: >
::: > Please stop and think a minute about what those entries are asking the
::: > firewall to do. The first one says that "any traffic from a host
with
a
::: > route out of eth1 that is being forwarded out of eth0 should have its
::: > source
::: > address rewritten to 66.224.62.120". Why would any traffic be
taking
:: that
::: > path at all? The second rule is similar...
::: >
::: > Am I missing something?
::: >
::: > -Tom
::: >
::: > Well in the mulit-Isp setup this is the convention
::: > to take with two isp two nics FQip
::: > That is why I am confused on how to masq
::: > from loc to the net with one nic FQip 66.224.62.120
::: > and the other fowarding to the gw 10.194.79.254
::: > on the internal lan. My thought about the lan
::: > is not to masq at all, any ideas?
::: > But you answer sure make me think about
::: > it more clear.
:::
::: If there is a local LAN here, which interface is it connected to? All
you
::: have shown us is eth0 and eth1 which appear to go to the two providers.
::: Please don''t tell me that ''the LAN'' is also
accessed through one of
those
::: interfaces....
:::
::: -Tom
::: --
::: Well I thought I could access both T-1''s in this config in my
previous
::: post, the admin led me to believe.
::: But as it turns out both these ISP''s (two full T-1''s are
in seperate
::: buildings)
::: and connected by one run of Fiber. So Jerry seemed optimistic this
config
::: would work as his does.
::: I have two nics in a test enviroment with the same setup at my place.
:::
::: eth0 66.224.62.120/27--gw 66.224.62.97
::: eth1 10.194.79.181- gw 10.194.79.254
::: I will send dump if you like.
:::
::: Mike
:::
::: Here is the dump
:: Thanks
:: Mike
:::
: Now I am thinking that does not make sense
: at all my thought is the traffic coming from
: the natted gateway is already masqeraded/
: just masqerade the eth1 to eth0 traffic
: so maybe its simple as below
: /etc/shorewall masqerade
: eth0 eth1
:
: Does that make sense?
: Mike
:
:
Tom,
I dont know if you recall but you helped me with the same
location years ago here is a post from the past between the lines
__________________________________________
On Sat, 15 Nov 2003, Mike Lander wrote:
> My mistake sorry, I got the networks wrong
> I need to add a static route for networks and hosts between
> 63.90.86.0~63.90.86.255 with gateway 10.5.198.238
> would this be correct?
> route add 63.90.86.0 255.0.0.0 gw 10.5.198.238
>
No; your netmask is incorrect -- check
http://www.shorewall.net/shorewall_setup_guide.htm#Addressing
(it would be good to bookmark that one for future reference).
--
Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://shorewall.net
Washington USA \ teastep@shorewall.net
___________________________________________
I am pulling that firewall and building that as well with Suse.
So I will have a shorewall box in both buildings, is there
a way that both shorewall boxes could loadbalance this?
With the two T-1''s in seperate buildings?
Mike
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Mike Lander wrote:> ----- Original Message ----- > From: "Mike Lander" <landers@lanlinecomputers.com> > To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> > Sent: Thursday, August 30, 2007 1:39 PM > Subject: Re: [Shorewall-users] Multi-Isp Masqerade ? > > > : > : ----- Original Message ----- > : From: "Mike Lander" <landers@lanlinecomputers.com> > : To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> > : Sent: Thursday, August 30, 2007 1:32 PM > : Subject: Re: [Shorewall-users] Multi-Isp Masqerade ? > : > : > :: Mike Lander wrote: > :: > Mike Lander wrote: > :: > > :: >> : /etc/shorewall/masq > :: >> : eth0 10.194.79.181 66.224.62.120 > :: >> : eth1 66.224.62.120 10.194.79.181 > :: >> : eth0 eth1 66.224.62.120 > :: >> : eth1 eth0 10.194.79.181 > :: > > :: > The last two entries appear to me to be totally silly. > :: > > :: > Please stop and think a minute about what those entries are asking the > :: > firewall to do. The first one says that "any traffic from a host with a > :: > route out of eth1 that is being forwarded out of eth0 should have its > :: > source > :: > address rewritten to 66.224.62.120". Why would any traffic be taking > : that > :: > path at all? The second rule is similar... > :: > > :: > Am I missing something? > :: > > :: > -Tom > :: > > :: > Well in the mulit-Isp setup this is the convention > :: > to take with two isp two nics FQip > :: > That is why I am confused on how to masq > :: > from loc to the net with one nic FQip 66.224.62.120 > :: > and the other fowarding to the gw 10.194.79.254 > :: > on the internal lan. My thought about the lan > :: > is not to masq at all, any ideas? > :: > But you answer sure make me think about > :: > it more clear. > :: > :: If there is a local LAN here, which interface is it connected to? All you > :: have shown us is eth0 and eth1 which appear to go to the two providers. > :: Please don''t tell me that ''the LAN'' is also accessed through one of those > :: interfaces.... > :: > :: -Tom > :: -- > :: Well I thought I could access both T-1''s in this config in my previous > :: post, the admin led me to believe. > :: But as it turns out both these ISP''s (two full T-1''s are in seperate > :: buildings) > :: and connected by one run of Fiber. So Jerry seemed optimistic this config > :: would work as his does. > :: I have two nics in a test enviroment with the same setup at my place. > :: > :: eth0 66.224.62.120/27--gw 66.224.62.97 > :: eth1 10.194.79.181- gw 10.194.79.254 > :: I will send dump if you like. > :: > :: Mike > :: > :: Here is the dump > : Thanks > : Mike > :: > Now I am thinking that does not make sense > at all my thought is the traffic coming from > the natted gateway is already masqeraded/ > just masqerade the eth1 to eth0 traffic > so maybe its simple as below > /etc/shorewall masqerade > eth0 eth1 > > Does that make sense?No. a) You have two interfaces on this firewall. b) You are using multi-ISP so I''m forced to believe that one NIC goes to one ISP and one NIC goes to the other. This seems to be supported by the routing configuration you posted. c) You say that there is a LAN somewhere that you want to masquerade but you seem to not want to tell me how it is reached. d) You keep showing us rules that masquerade traffic received from one ISP that is being sent via the other ISP. That makes no sense to me and Shorewall will complain loudly when processing the masq rules you have been posting. Mike, please explain in simple English what you are trying to accomplish. Until I understand that, I can''t comment intelligently on your config files, on a Shorewall dump, or on individual file entries. I''m sorry but I don''t have the time to go back through the long email trail between you and Jerry; I might be able to dig this information out myself if I did... -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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
> : ----- Original Message ----- > : From: "Mike Lander" <landers@lanlinecomputers.com> > : To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> > : Sent: Thursday, August 30, 2007 1:32 PM > : Subject: Re: [Shorewall-users] Multi-Isp Masqerade ? > : > : > :: Mike Lander wrote: > :: > Mike Lander wrote: > :: > > :: >> : /etc/shorewall/masq > :: >> : eth0 10.194.79.181 66.224.62.120 > :: >> : eth1 66.224.62.120 10.194.79.181 > :: >> : eth0 eth1 66.224.62.120 > :: >> : eth1 eth0 10.194.79.181 > :: > > :: > The last two entries appear to me to be totally silly. > :: > > :: > Please stop and think a minute about what those entries are asking > the > :: > firewall to do. The first one says that "any traffic from a host with > a > :: > route out of eth1 that is being forwarded out of eth0 should have its > :: > source > :: > address rewritten to 66.224.62.120". Why would any traffic be taking > : that > :: > path at all? The second rule is similar... > :: > > :: > Am I missing something? > :: > > :: > -Tom > :: > > :: > Well in the mulit-Isp setup this is the convention > :: > to take with two isp two nics FQip > :: > That is why I am confused on how to masq > :: > from loc to the net with one nic FQip 66.224.62.120 > :: > and the other fowarding to the gw 10.194.79.254 > :: > on the internal lan. My thought about the lan > :: > is not to masq at all, any ideas? > :: > But you answer sure make me think about > :: > it more clear. > :: > :: If there is a local LAN here, which interface is it connected to? All > you > :: have shown us is eth0 and eth1 which appear to go to the two providers. > :: Please don''t tell me that ''the LAN'' is also accessed through one of > those > :: interfaces.... > :: > :: -Tom > :: -- > :: Well I thought I could access both T-1''s in this config in my previous > :: post, the admin led me to believe. > :: But as it turns out both these ISP''s (two full T-1''s are in seperate > :: buildings) > :: and connected by one run of Fiber. So Jerry seemed optimistic this > config > :: would work as his does. > :: I have two nics in a test enviroment with the same setup at my place. > :: > :: eth0 66.224.62.120/27--gw 66.224.62.97 > :: eth1 10.194.79.181- gw 10.194.79.254 > :: I will send dump if you like. > :: > :: Mike > :: > :: Here is the dump > : Thanks > : Mike > :: > Now I am thinking that does not make sense > at all my thought is the traffic coming from > the natted gateway is already masqeraded/ > just masqerade the eth1 to eth0 traffic > so maybe its simple as below > /etc/shorewall masqerade > eth0 eth1 > > Does that make sense?No. a) You have two interfaces on this firewall. b) You are using multi-ISP so I''m forced to believe that one NIC goes to one ISP and one NIC goes to the other. This seems to be supported by the routing configuration you posted. c) You say that there is a LAN somewhere that you want to masquerade but you seem to not want to tell me how it is reached. d) You keep showing us rules that masquerade traffic received from one ISP that is being sent via the other ISP. That makes no sense to me and Shorewall will complain loudly when processing the masq rules you have been posting. Mike, please explain in simple English what you are trying to accomplish. Until I understand that, I can''t comment intelligently on your config files, on a Shorewall dump, or on individual file entries. I''m sorry but I don''t have the time to go back through the long email trail between you and Jerry; I might be able to dig this information out myself if I did... -Tom PS So you can follow building reference building 1 Full T-1 under my control with /29 non-routed building 2 Full T-1 under Toyota''s Control. natted with a cisco router with lan ip10.5.198.238 Note: In my test environment the practice ip 10.194.79.254 will emulate like 10.5.198.238 Tom, I was just eating lunch and thought I should explain this better instead of assuming you followed our post. I built these guys a shorewall box in 2003 as you have seen. It has redhat 8 and shorewall 3.0.2. and its been serving as a file server as well. When I checked this place the admin thought the T-1''s where in the same building as the old shorewall box is now. The old box is accessing the 10.5.198.238 gateway only for networks 63.90.860/24. PS old box is still at the location being used. Since the old shoreall box was built the natted gateway that is out of my control has beenupgraded to a Full T-1 in building 2 where currently there is no shorewall box. Just the Toyota Cisco. I was going to use three nic box with two nics for Ips''s But the two buildings are connected with fiber on the lan 10.5.198.0/24 So now a dual nic that Jerry has working sounded attractive. I will put the old shorewall box in building 2 (after rebuild)_ for a backup file server is what its primary purpose is. They have liked it so much, they want a bigger better box built for redirecting mydocments on their Xp boxes to a Samba share. So I built a Dell 2900 quad zeon 2gb ram to handle being a domain controller for their network to knock out the old shorewall box. The natted T-1 is hardly being used they wish to load balance to take advantage of the T-1''s and maybe down the road use as failover. I am not opposed to a better idea than the two nics if you have an idea. Because in a simular situation I asked you aways back I need customer wireless to a 2nd building slaved with fiber on a lan and you suggested to vpn to the wireless to seperateh the lan traffic from customer wireless router and that worked great. Getting lengthy so hope this helps. Thanks Tom Mike ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Mike Lander wrote:> > PS So you can follow building reference > building 1 Full T-1 under my control with /29 non-routed > building 2 Full T-1 under Toyota''s Control. natted with > a cisco router with lan ip10.5.198.238 > > Note: In my test environment the practice ip 10.194.79.254 > will emulate like 10.5.198.238 > > Tom, > I was just eating lunch and thought I should explain this better instead > of assuming you followed our post. I built these guys a shorewall box > in 2003 as you have seen. It has redhat 8 and shorewall 3.0.2. > and its been serving as a file server as well. When I checked this place > the admin thought the T-1''s where in the same building as the old > shorewall box is now. The old box is accessing the 10.5.198.238 > gateway only for networks 63.90.860/24. > > PS old box is still at the location being used. > > Since the old shoreall box was built the natted gateway that > is out of my control has beenupgraded to a Full T-1 in building 2 > where currently there is no shorewall box. Just the Toyota Cisco. > I was going to use three nic box with two nics for Ips''s > But the two buildings are connected with fiber on the > lan 10.5.198.0/24 So now a dual nic that Jerry has > working sounded attractive. > > I will put the old shorewall box in building 2 (after rebuild)_ > for a backup file server is what its primary purpose is. > > They have liked it so much, they want a bigger > better box built for redirecting mydocments on their Xp boxes to a > Samba share. So I built a Dell 2900 quad zeon 2gb ram to handle > being a domain controller for their network to knock out the > old shorewall box. > The natted T-1 is hardly being used they wish to load > balance to take advantage of the T-1''s and maybe down the > road use as failover. I am not opposed to a better idea than > the two nics if you have an idea. Because in a simular situation > I asked you aways back I need customer wireless to a 2nd building > slaved with fiber on a lan and you suggested to vpn to the wireless > to seperateh the lan traffic from customer wireless router > and that worked great. Getting lengthy so hope this helps. >Mike, Does http://www1.shorewall.net/images/Landers.png accurately reflect the network topology? If so, you want this masq entry; eth0 10.194.79.0/24 66.224.62.120 -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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Mike Lander wrote:> > PS So you can follow building reference > building 1 Full T-1 under my control with /29 non-routed > building 2 Full T-1 under Toyota''s Control. natted with > a cisco router with lan ip10.5.198.238 > > Note: In my test environment the practice ip 10.194.79.254 > will emulate like 10.5.198.238 > > Tom, > I was just eating lunch and thought I should explain this better > instead > of assuming you followed our post. I built these guys a shorewall box > in 2003 as you have seen. It has redhat 8 and shorewall 3.0.2. > and its been serving as a file server as well. When I checked this place > the admin thought the T-1''s where in the same building as the old > shorewall box is now. The old box is accessing the 10.5.198.238 > gateway only for networks 63.90.860/24. > > PS old box is still at the location being used. > > Since the old shoreall box was built the natted gateway that > is out of my control has beenupgraded to a Full T-1 in building 2 > where currently there is no shorewall box. Just the Toyota Cisco. > I was going to use three nic box with two nics for Ips''s > But the two buildings are connected with fiber on the > lan 10.5.198.0/24 So now a dual nic that Jerry has > working sounded attractive. > > I will put the old shorewall box in building 2 (after rebuild)_ > for a backup file server is what its primary purpose is. > > They have liked it so much, they want a bigger > better box built for redirecting mydocments on their Xp boxes to a > Samba share. So I built a Dell 2900 quad zeon 2gb ram to handle > being a domain controller for their network to knock out the > old shorewall box. > The natted T-1 is hardly being used they wish to load > balance to take advantage of the T-1''s and maybe down the > road use as failover. I am not opposed to a better idea than > the two nics if you have an idea. Because in a simular situation > I asked you aways back I need customer wireless to a 2nd building > slaved with fiber on a lan and you suggested to vpn to the wireless > to seperateh the lan traffic from customer wireless router > and that worked great. Getting lengthy so hope this helps. >Mike, Does http://www1.shorewall.net/images/Landers.png accurately reflect the network topology? If so, you want this masq entry; eth0 10.194.79.0/24 66.224.62.120 -Tom Yes this accurately reflects the network topology? However I been testing squid through this now and the brower pauses an balks at times. So I tried 10.194.79.181 in tcp outgoing in squid.conf and browsing was fine. When I changed tcp outgoing to 66.224.62.120, the trouble started again. You would of thought I would have been the lan gateway causing trouble. any ideas? PS back up a litte about masq. I am trying to understand the masq stuff for multi-isp In my main firewall my masq is as follows eth0 $ETH2_IP 66.224.62.118 eth2 66.224.62.118 $ETH2_IP eth0 eth1 66.224.62.118 eth2 eth1 $ETH2_IP When you said this looks "silly" why would we need in the first rule anything coming in on $eth2(comcast) going out eth0 (eshelon t-1) be rewritten as 66.244.62.118 when no traffic should not be going through in the first place with policy "net net drop" Thank You, Mike ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Mike Lander wrote:> Yes this accurately reflects the network topology? > However I been testing squid through this now and > the brower pauses an balks at times. So I tried > 10.194.79.181 in tcp outgoing in squid.conf > and browsing was fine. When I changed tcp > outgoing to 66.224.62.120, the trouble started > again. You would of thought I would have been > the lan gateway causing trouble. any ideas?Wireshark is your friend.> > PS back up a litte about masq. I am trying > to understand the masq stuff for multi-isp > In my main firewall my masq is as follows > eth0 $ETH2_IP 66.224.62.118 > eth2 66.224.62.118 $ETH2_IP > eth0 eth1 66.224.62.118 > eth2 eth1 $ETH2_IPThis is different from what you posted earlier. This is a sensible configuration that masquerades traffic from a local network (eth1) to either of two ISPs (eth0 and eth2). You posted this which I called ''silly'':> : eth0 10.194.79.181 66.224.62.120 > : eth1 66.224.62.120 10.194.79.181 > : eth0 eth1 66.224.62.120 > : eth1 eth0 10.194.79.181See the difference? -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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Mike Lander wrote:> Yes this accurately reflects the network topology? > However I been testing squid through this now and > the brower pauses an balks at times. So I tried > 10.194.79.181 in tcp outgoing in squid.conf > and browsing was fine. When I changed tcp > outgoing to 66.224.62.120, the trouble started > again. You would of thought I would have been > the lan gateway causing trouble. any ideas?Wireshark is your friend. Tom , Here is a tcpdump from eth1, I tryed one from eth0. Because I have tcpoutgoing in squid to 66.224.62.120. Squid should be trying to go out eth0. But I could see no evidence of traffice from 66.224.62.120 sniffing eth0. So this is a binary dump of eth1 lan with host 10.194.79.199 trying to browse web pages through squid. PS the dump is binary Mike ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Mike, Please fix your mail client so that it quotes properly. Regards, -Roberto On Thu, Aug 30, 2007 at 06:37:31PM -0700, Mike Lander wrote:> Mike Lander wrote: > > > Yes this accurately reflects the network topology? > > However I been testing squid through this now and > > the brower pauses an balks at times. So I tried > > 10.194.79.181 in tcp outgoing in squid.conf > > and browsing was fine. When I changed tcp > > outgoing to 66.224.62.120, the trouble started > > again. You would of thought I would have been > > the lan gateway causing trouble. any ideas? > > Wireshark is your friend. > > > Tom , > Here is a tcpdump from eth1, I tryed > one from eth0. Because I have tcpoutgoing > in squid to 66.224.62.120. Squid should be > trying to go out eth0. But I could see no > evidence of traffice from 66.224.62.120 > sniffing eth0. So this is a binary dump > of eth1 lan with host 10.194.79.199 > trying to browse web pages through > squid. > PS the dump is binary > Mike> ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users-- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Mike, Please fix your mail client so that it quotes properly. Regards, -Roberto On Thu, Aug 30, 2007 at 06:37:31PM -0700, Mike Lander wrote:> Mike Lander wrote: > > > Yes this accurately reflects the network topology? > > However I been testing squid through this now and > > the brower pauses an balks at times. So I tried > > 10.194.79.181 in tcp outgoing in squid.conf > > and browsing was fine. When I changed tcp > > outgoing to 66.224.62.120, the trouble started > > again. You would of thought I would have been > > the lan gateway causing trouble. any ideas? > > Wireshark is your friend. > > > Tom , > Here is a tcpdump from eth1, I tryed > one from eth0. Because I have tcpoutgoing > in squid to 66.224.62.120. Squid should be > trying to go out eth0. But I could see no > evidence of traffice from 66.224.62.120 > sniffing eth0. So this is a binary dump > of eth1 lan with host 10.194.79.199 > trying to browse web pages through > squid. > PS the dump is binary > MikeRoberto, I would be happy to accomdate. However "quotes properly" has no meaning to me. Do you mean lines before it wraps. Tom had me set that to 76 a long time ago.. Mike ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Thu, Aug 30, 2007 at 07:00:50PM -0700, Mike Lander wrote:> > Roberto, > I would be happy to accomdate. > However "quotes properly" has no > meaning to me. Do you mean lines > before it wraps. Tom had me set that > to 76 a long time ago.. >No. Wrapping is fine. The message to which I had replied had an attachment for the message to which you were replying, instead of being inline. Also, prefixing the each line of a reply with a standard character (like >) is a good idea. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
----- Original Message ----- From: "Roberto C. Sánchez" <roberto@connexer.com> To: <shorewall-users@lists.sourceforge.net> Sent: Thursday, August 30, 2007 7:22 PM Subject: Re: [Shorewall-users] Multi-Isp Masqerade ? On Thu, Aug 30, 2007 at 07:00:50PM -0700, Mike Lander wrote:> > Roberto, > I would be happy to accomdate. > However "quotes properly" has no > meaning to me. Do you mean lines > before it wraps. Tom had me set that > to 76 a long time ago.. >No. Wrapping is fine. The message to which I had replied had an attachment for the message to which you were replying, instead of being inline. Also, prefixing the each line of a reply with a standard character (like >) is a good idea. Regards, -Roberto -- Thanks for the tip, I figured out the > for reply. But a few years ago the list came up with the attachments like Tom''s for instance which I assume is some way to authenticate the person sending the mail is really him. But the whole thing is a nusiance to me, when you click reply nothing is there. so I copy and paste what I think is pertinate in the message. Maybe I have no linux etticate or something. But have been leary to ask what it is for. Thanks Mike ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Thu, Aug 30, 2007 at 08:07:39PM -0700, Mike Lander wrote:> Thanks for the tip, I figured out the > for reply. But a few years ago the > list came up with the attachments like Tom''s for instance which I assume > is some way to authenticate the person sending the mail is really him. > But the whole thing is a nusiance to me, when you click reply nothing > is there. so I copy and paste what I think is pertinate in the message. > Maybe I have no linux etticate or something. But have been leary > to ask what it is for. >OK. It is still not working. Unfurtonately, the SourceForge lists have this annoying habit of turning messages into multi-part messages even when they are not. Your best bet is to switch to a real mail client (like Thunderbird), which will handle many of these things for you automatically. Also, when you see the double-dash (--), that indicates the start of someone''s signature. You don''t want to reply below that since it will either show up as the person''s signature (your reply will) or it will not be displayed at all, as some people have viewing of signatures disabled. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Thu, Aug 30, 2007 at 08:07:39PM -0700, Mike Lander wrote:> Thanks for the tip, I figured out the > for reply. But a few years ago the > list came up with the attachments like Tom''s for instance which I assume > is some way to authenticate the person sending the mail is really him. > But the whole thing is a nusiance to me, when you click reply nothing > is there. so I copy and paste what I think is pertinate in the message. > Maybe I have no linux etticate or something. But have been leary > to ask what it is for. >OK. It is still not working. Unfurtonately, the SourceForge lists have this annoying habit of turning messages into multi-part messages even when they are not. Your best bet is to switch to a real mail client (like Thunderbird), which will handle many of these things for you automatically. Also, when you see the double-dash (--), that indicates the start of someone''s signature. You don''t want to reply below that since it will either show up as the person''s signature (your reply will) or it will not be displayed at all, as some people have viewing of signatures disabled. Regards, -Roberto -- Thanks again, I would not mind switching to a better client. This box, it is retired out in my shop and I Remote to it to design websites and get shorewall mail. Thats why I am not on the list as much as I used to be. I started with shorewall way back when it was seawall with Tom. I think in 99 or 2000. This client is full of mail with just Shorewall. It answers most of my questions by searching within this box. But lately it does not work well with the list. It runs OE) is dedicated to Shorewall list and has 15,301 messages in it. If Thunderbird would import them would be nice. I am really tired of building this server. I have been on it three weeks many hours to get Samba to work. I thought Shore Wall would be a breeze. But you can see this ones been tough. Which I could go on vacation like Tom. You GO Tom. Much deserved. I will try to get Thunderbird up when I have some more wind in my sails. I would love to get this project done though, having bad luck with help though. Thanks Roberto Mike ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
----- Original Message ----- From: "Mike Lander" <landers@lanlinecomputers.com> To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> Sent: Thursday, August 30, 2007 6:37 PM Subject: Re: [Shorewall-users] Multi-Isp Masqerade ?> Mike Lander wrote: > >> Yes this accurately reflects the network topology? >> However I been testing squid through this now and >> the brower pauses an balks at times. So I tried >> 10.194.79.181 in tcp outgoing in squid.conf >> and browsing was fine. When I changed tcp >> outgoing to 66.224.62.120, the trouble started >> again. You would of thought I would have been >> the lan gateway causing trouble. any ideas? > > Wireshark is your friend. > > > Tom , > Here is a tcpdump from eth1, I tryed > one from eth0. Because I have tcpoutgoing > in squid to 66.224.62.120. Squid should be > trying to go out eth0. But I could see no > evidence of traffice from 66.224.62.120 > sniffing eth0. So this is a binary dump > of eth1 lan with host 10.194.79.199 > trying to browse web pages through > squid. > PS the dump is binary > Mike-------------------------------------------------------------------------------- I think I have this firewall really close. I have one trouble cant seem to trace down. With the following routes (posted below) if I comment out like this in shorewall rules. #REDIRECT loc 3128 tcp www - !10.194.79.181 The local machines can browse through port 80 Things seem ok. But if I fire up squid (running on the firewall) by uncommenting the redirect The system returned: (113) no route to host At times squid may return a page. The trouble seems to be routing for local Any ideas on how I could diagose? Or does this routing look ok? Thanks Mike ns5:~ # shorewall show routing Can''t determine the IP address of eth2 Shorewall 4.0.2 Routing at ns5 - Sun Sep 2 04:43:52 PDT 2007 Routing Rules 0: from all lookup local 10256: from all fwmark 0x100 lookup atg 10512: from all fwmark 0x200 lookup loc 32766: from all lookup main 32767: from all lookup default Table atg: 66.224.62.97 dev eth0 scope link src 66.224.62.120 10.194.79.0/24 dev eth1 proto kernel scope link src 10.194.79.181 default via 66.224.62.97 dev eth0 Table default: Table loc: 10.194.79.254 dev eth1 scope link src 10.194.79.181 10.194.79.0/24 dev eth1 proto kernel scope link src 10.194.79.181 default via 10.194.79.254 dev eth1 Table local: broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 broadcast 66.224.62.96 dev eth0 proto kernel scope link src 66.224.62.120 broadcast 10.194.79.0 dev eth1 proto kernel scope link src 10.194.79.181 local 10.194.79.181 dev eth1 proto kernel scope host src 10.194.79.181 local 66.224.62.120 dev eth0 proto kernel scope host src 66.224.62.120 broadcast 66.224.62.127 dev eth0 proto kernel scope link src 66.224.62.120 broadcast 10.194.79.255 dev eth1 proto kernel scope link src 10.194.79.181 broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 Table main: 66.224.62.96/27 dev eth0 proto kernel scope link src 66.224.62.120 10.194.79.0/24 dev eth1 proto kernel scope link src 10.194.79.181 169.254.0.0/16 dev eth0 scope link 127.0.0.0/8 dev lo scope link default nexthop via 66.224.62.97 dev eth0 weight 1 nexthop via 10.194.79.254 dev eth1 weight 1 ns5:~ # ip rule ls 0: from all lookup local 10256: from all fwmark 0x100 lookup atg 10512: from all fwmark 0x200 lookup loc 32766: from all lookup main 32767: from all lookup default ns5:~ # shorewall show routing Can''t determine the IP address of eth2 Shorewall 4.0.2 Routing at ns5 - Tue Sep 4 12:39:49 PDT 2007 Routing Rules 0: from all lookup local 10256: from all fwmark 0x100 lookup atg 10512: from all fwmark 0x200 lookup loc 32766: from all lookup main 32767: from all lookup default Table atg: 66.224.62.97 dev eth0 scope link src 66.224.62.120 10.194.79.0/24 dev eth1 proto kernel scope link src 10.194.79.181 default via 66.224.62.97 dev eth0 Table default: Table loc: 10.194.79.254 dev eth1 scope link src 10.194.79.181 10.194.79.0/24 dev eth1 proto kernel scope link src 10.194.79.181 default via 10.194.79.254 dev eth1 Table local: broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 broadcast 66.224.62.96 dev eth0 proto kernel scope link src 66.224.62.120 broadcast 10.194.79.0 dev eth1 proto kernel scope link src 10.194.79.181 local 10.194.79.181 dev eth1 proto kernel scope host src 10.194.79.181 local 66.224.62.120 dev eth0 proto kernel scope host src 66.224.62.120 broadcast 66.224.62.127 dev eth0 proto kernel scope link src 66.224.62.120 broadcast 10.194.79.255 dev eth1 proto kernel scope link src 10.194.79.181 broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 Table main: 66.224.62.96/27 dev eth0 proto kernel scope link src 66.224.62.120 10.194.79.0/24 dev eth1 proto kernel scope link src 10.194.79.181 169.254.0.0/16 dev eth0 scope link 127.0.0.0/8 dev lo scope link default nexthop via 66.224.62.97 dev eth0 weight 1 nexthop via 10.194.79.254 dev eth1 weight 1 ns5:~ # ns5:~ # ip route ls 66.224.62.96/27 dev eth0 proto kernel scope link src 66.224.62.120 10.194.79.0/24 dev eth1 proto kernel scope link src 10.194.79.181 169.254.0.0/16 dev eth0 scope link 127.0.0.0/8 dev lo scope link default nexthop via 66.224.62.97 dev eth0 weight 1 nexthop via 10.194.79.254 dev eth1 weight 1 ns5:~ # ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Mike Lander wrote:> ----- Original Message ----- > From: "Mike Lander" <landers@lanlinecomputers.com> > To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> > Sent: Thursday, August 30, 2007 6:37 PM > Subject: Re: [Shorewall-users] Multi-Isp Masqerade ? > > >> Mike Lander wrote: >> >>> Yes this accurately reflects the network topology? >>> However I been testing squid through this now and >>> the brower pauses an balks at times. So I tried >>> 10.194.79.181 in tcp outgoing in squid.conf >>> and browsing was fine. When I changed tcp >>> outgoing to 66.224.62.120, the trouble started >>> again. You would of thought I would have been >>> the lan gateway causing trouble. any ideas? >> Wireshark is your friend. >> >> >> Tom , >> Here is a tcpdump from eth1, I tryed >> one from eth0. Because I have tcpoutgoing >> in squid to 66.224.62.120. Squid should be >> trying to go out eth0. But I could see no >> evidence of traffice from 66.224.62.120 >> sniffing eth0. So this is a binary dump >> of eth1 lan with host 10.194.79.199 >> trying to browse web pages through >> squid. >> PS the dump is binary >> Mike > > > -------------------------------------------------------------------------------- > > I think I have this firewall really close. I have > > one trouble cant seem to trace down. With the following routes > > (posted below) > > if I comment out like this in shorewall rules. > > #REDIRECT loc 3128 tcp www - !10.194.79.181 > > The local machines can browse through port 80 > > Things seem ok. > > But if I fire up squid (running on the firewall) > > by uncommenting the redirect > > The system returned: > > (113) no route to host > > At times squid may return a page. >I have my squid running a different box. You could (should?) configure squid to listen on only the internal interface, that should keep the routing straight. When things ping-pong between working and not working on connections involving the firewall itself, it is usually because the masq entries for the firewall are missing as shown in the multi-isp doc. In the masq file, you have: eth0 10.194.79.181 66.224.62.120 eth1 66.224.62.120 10.194.79.181 Right? (I can''t tell from here). more below..> The trouble seems to be routing for local > > Any ideas on how I could diagose? > > Or does this routing look ok? > > Thanks > > Mike >Looks like mine... ;-) <snip> If the masq file is fine, then I think you may need to use the tcrules file here. Something like might help: <loc_mark> $FW 10.194.79.0/24 tcp - 3128 replace the <loc_mark> with the mark your using on the local interface and don''t use :F or :P Jerry ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
----- Original Message ----- From: "Jerry Vonau" <jvonau@shaw.ca> To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> Sent: Tuesday, September 04, 2007 2:49 PM Subject: Re: [Shorewall-users] Multi-Isp Masqerade ?>>> Mike Lander wrote: >>> >>>> Yes this accurately reflects the network topology? >>>> However I been testing squid through this now and >>>> the brower pauses an balks at times. So I tried >>>> 10.194.79.181 in tcp outgoing in squid.conf >>>> and browsing was fine. When I changed tcp >>>> outgoing to 66.224.62.120, the trouble started >>>> again. You would of thought I would have been >>>> the lan gateway causing trouble. any ideas? >>> Wireshark is your friend. >>> >>> >>> Tom , >>> Here is a tcpdump from eth1, I tryed >>> one from eth0. Because I have tcpoutgoing >>> in squid to 66.224.62.120. Squid should be >>> trying to go out eth0. But I could see no >>> evidence of traffice from 66.224.62.120 >>> sniffing eth0. So this is a binary dump >>> of eth1 lan with host 10.194.79.199 >>> trying to browse web pages through >>> squid. >>> PS the dump is binary >>> Mike >> >> >> -------------------------------------------------------------------------------- >> >> I think I have this firewall really close. I have >> >> one trouble cant seem to trace down. With the following routes >> >> (posted below) >> >> if I comment out like this in shorewall rules. >> >> #REDIRECT loc 3128 tcp www - >> !10.194.79.181 >> >> The local machines can browse through port 80 >> >> Things seem ok. >> >> But if I fire up squid (running on the firewall) >> >> by uncommenting the redirect >> >> The system returned: >> >> (113) no route to host >> >> At times squid may return a page. >> > > I have my squid running a different box. You could (should?) configure > squid to listen on only the internal interface, that should keep the > routing straight. > > When things ping-pong between working and not working on connections > involving the firewall itself, it is usually because the masq entries > for the firewall are missing as shown in the multi-isp doc. > > In the masq file, you have: > > eth0 10.194.79.181 66.224.62.120 > eth1 66.224.62.120 10.194.79.181 > > Right? (I can''t tell from here). more below.. > >> The trouble seems to be routing for local >> >> Any ideas on how I could diagose? >> >> Or does this routing look ok? >> >> Thanks >> >> Mike >> > > Looks like mine... ;-) > > <snip> > If the masq file is fine, then I think you may need to use the tcrules > file here. Something like might help: > > <loc_mark> $FW 10.194.79.0/24 tcp - 3128 > > replace the <loc_mark> with the mark your using on the local interface > and don''t use :F or :P > > Jerry >Hi Jerry, I think my whole trouble was masq file the only entry I had was the first entry below which Tom helped me with that! I cannot seem to grasp the entries in the masq even though if I read an existing masq entry I can follow the meaning of it. The best way to describe this is, the firewall seemed to be gasping for a breath until I entered the eth1 rewrite. Not sure if its perfect time will tell but now browsing seemed to spring to life. I belive ack''s were coming back fand they where trying to goto local machines instead of answering squid syn''s. Thank you. Mike eth0 10.194.79.0/24 66.224.62.120 ----1st entry eth1 66.224.62.120 10.194.79.181 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Mike Lander wrote:> > Hi Jerry, > I think my whole trouble was masq file the only entry I had > was the first entry below which Tom helped me with that! > I cannot seem to grasp the entries in the masq even though if > I read an existing masq entry I can follow the meaning of it. > The best way to describe this is, the firewall seemed to > be gasping for a breath until I entered the eth1 rewrite.Yup, for whatever reason the networking stack picks a route to use before it picks the source ip. It may have the right route, on the right interface, but with the wrong source ip. That is why those masq entries for the firewall traffic are there, it is really just a workaround...> Not sure if its perfect time will tell but now browsing > seemed to spring to life.Glad you got it to work.> I belive ack''s were coming back > fand they where trying to goto local machines > instead of answering squid syn''s. > Thank you. > Mike > > eth0 10.194.79.0/24 66.224.62.120 ----1st entry > eth1 66.224.62.120 10.194.79.181That''s why there is that warning in the multi-isp doc, Tom and I spent a lot of time debugging this after the multi-isp support was added. You could do one of two things, bind the app to a single ip address or add those entries. Jerry ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
> Mike Lander wrote: >> >> Hi Jerry, >> I think my whole trouble was masq file the only entry I had >> was the first entry below which Tom helped me with that! >> I cannot seem to grasp the entries in the masq even though if >> I read an existing masq entry I can follow the meaning of it. >> The best way to describe this is, the firewall seemed to >> be gasping for a breath until I entered the eth1 rewrite. > > Yup, for whatever reason the networking stack picks a route to use > before it picks the source ip. It may have the right route, on the right > interface, but with the wrong source ip. That is why those masq entries > for the firewall traffic are there, it is really just a workaround... > >> Not sure if its perfect time will tell but now browsing >> seemed to spring to life. > > Glad you got it to work. > >> I belive ack''s were coming back >> fand they where trying to goto local machines >> instead of answering squid syn''s. >> Thank you. >> Mike >> >> eth0 10.194.79.0/24 66.224.62.120 ----1st entry >> eth1 66.224.62.120 10.194.79.181 > > That''s why there is that warning in the multi-isp doc, Tom and I spent a > lot of time debugging this after the multi-isp support was added. You > could do one of two things, bind the app to a single ip address or add > those entries. > > Jerry >Jerry, Ok I want to try to understand the second masq entry. Because the first entry is easier to follow. But analyzing the second entry. In the networks to snat we have 66.224.62.120. Outgoing or interface the packet is forwarded to is eth1 which eth1''s ip is 10.194.79.181. Then finally the source nat address that is to be rewritten is 66.224.62.120. What confused me here is how did a request get to 66.224.62.120. in the first place. When its marked for another isp (which is a natted gateway in this config)? And let me know if this is hard to explain because I have a new book for linux that may help me to understand this. Thanks, Mike ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
----- Original Message ----- From: "Mike Lander" <landers@lanlinecomputers.com> To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> Sent: Tuesday, September 04, 2007 6:30 PM Subject: Re: [Shorewall-users] Multi-Isp Masqerade ?> >> Mike Lander wrote: >>> >>> Hi Jerry, >>> I think my whole trouble was masq file the only entry I had >>> was the first entry below which Tom helped me with that! >>> I cannot seem to grasp the entries in the masq even though if >>> I read an existing masq entry I can follow the meaning of it. >>> The best way to describe this is, the firewall seemed to >>> be gasping for a breath until I entered the eth1 rewrite. >> >> Yup, for whatever reason the networking stack picks a route to use >> before it picks the source ip. It may have the right route, on the right >> interface, but with the wrong source ip. That is why those masq entries >> for the firewall traffic are there, it is really just a workaround... >> >>> Not sure if its perfect time will tell but now browsing >>> seemed to spring to life. >> >> Glad you got it to work. >> >>> I belive ack''s were coming back >>> fand they where trying to goto local machines >>> instead of answering squid syn''s. >>> Thank you. >>> Mike >>> >>> eth0 10.194.79.0/24 66.224.62.120 ----1st entry >>> eth1 66.224.62.120 10.194.79.181 >> >> That''s why there is that warning in the multi-isp doc, Tom and I spent a >> lot of time debugging this after the multi-isp support was added. You >> could do one of two things, bind the app to a single ip address or add >> those entries. >> >> Jerry >> > Jerry, > Ok I want to try to understand the second masq entry. > Because the first entry is easier to follow. > But analyzing the second entry. > In the networks to snat we have 66.224.62.120. > Outgoing or interface the packet is forwarded to is > eth1 which eth1''s ip is 10.194.79.181. > Then finally the source nat address that is to > be rewritten is 66.224.62.120. > What confused me here is how did a request get to > 66.224.62.120. in the first place. When its marked > for another isp (which is a natted gateway in this > config)? > And let me know if this is hard to explain because > I have a new book for linux that may help me > to understand this. > > Thanks, > MikeSorry correction above : Then finally the source nat address that is to> be rewritten is 66.224.62.120.should have been 10.194.79.181 <<<<<<<<<<< ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Mike Lander wrote:>> Mike Lander wrote: >>> Hi Jerry, >>> I think my whole trouble was masq file the only entry I had >>> was the first entry below which Tom helped me with that! >>> I cannot seem to grasp the entries in the masq even though if >>> I read an existing masq entry I can follow the meaning of it. >>> The best way to describe this is, the firewall seemed to >>> be gasping for a breath until I entered the eth1 rewrite. >> Yup, for whatever reason the networking stack picks a route to use >> before it picks the source ip. It may have the right route, on the right >> interface, but with the wrong source ip. That is why those masq entries >> for the firewall traffic are there, it is really just a workaround... >> >>> Not sure if its perfect time will tell but now browsing >>> seemed to spring to life. >> Glad you got it to work. >> >>> I belive ack''s were coming back >>> fand they where trying to goto local machines >>> instead of answering squid syn''s. >>> Thank you. >>> Mike >>> >>> eth0 10.194.79.0/24 66.224.62.120 ----1st entry >>> eth1 66.224.62.120 10.194.79.181 >> That''s why there is that warning in the multi-isp doc, Tom and I spent a >> lot of time debugging this after the multi-isp support was added. You >> could do one of two things, bind the app to a single ip address or add >> those entries. >> >> Jerry >> > Jerry, > Ok I want to try to understand the second masq entry. > Because the first entry is easier to follow. > But analyzing the second entry. > In the networks to snat we have 66.224.62.120. > Outgoing or interface the packet is forwarded to is > eth1 which eth1''s ip is 10.194.79.181. > Then finally the source nat address that is to > be rewritten is 66.224.62.120.The masq rule reads more like: if (when?) the packet is leaving on eth1, with a source address that is 66.224.62.120 (from eth2), "fix it" with the address 10.194.79.181 (from eth1).> What confused me here is how did a request get to > 66.224.62.120. in the first place. When its marked > for another isp (which is a natted gateway in this > config)? > And let me know if this is hard to explain because > I have a new book for linux that may help me > to understand this. > > Thanks, > Mike > >As above, it''s a problem deep in the ip stack when your using the advanced routing features with 2 gateway and an application is allowed to bind to all of the available ip addresses. Try to read all the source code, you''ll see what I mean by "whatever reason". ;-) Jerry> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/