Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 28 replies
  • Subscribers 2 subscribers
  • Views 19586 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Strange Masquerading Issue

Goldy_01
Hi.

Today I've got a call from a colleague.
From what he says - he can see in his firewall, the internal source address of some (not all) of the stations from my Lan network which connect to his servers.
Since my entire internal network doing Masquerading, I wonder how this could be.
As far as I know, only DNat transmit the source address.

Any Idea?
[:S]


This thread was automatically locked due to age.
Parents
  • 0
    Goldy,

    Can you check and see if the problem is similar to what is described here: Ubuntu Linux iptables firewall rules to prevent TCP package leakage. WWW.Smythies.com. What this guy describes is very similar to what BarryG & Xavier2 were noting in the other thread.

    Basically, Linux iptables recieves a TCP close sequence and kills the entry in the conntrack table approx 30sec later. After that window of time has passed, a packet is recieved related to that conntrack entry but the firewall is unsure what to do so fires it out un-NAT'd.

    There are two fixes noted there, either add a new iptables rule related to invalid packets, or to increase the conntrack timeout (which Bob suggested).

    I'm going to be checking our firewall at the office when I get in this morning and see what's happening on ours.
Reply
  • 0
    Goldy,

    Can you check and see if the problem is similar to what is described here: Ubuntu Linux iptables firewall rules to prevent TCP package leakage. WWW.Smythies.com. What this guy describes is very similar to what BarryG & Xavier2 were noting in the other thread.

    Basically, Linux iptables recieves a TCP close sequence and kills the entry in the conntrack table approx 30sec later. After that window of time has passed, a packet is recieved related to that conntrack entry but the firewall is unsure what to do so fires it out un-NAT'd.

    There are two fixes noted there, either add a new iptables rule related to invalid packets, or to increase the conntrack timeout (which Bob suggested).

    I'm going to be checking our firewall at the office when I get in this morning and see what's happening on ours.
Children
No Data