> 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/
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to