Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 28 replies
  • Subscribers 2 subscribers
  • Views 19573 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.
  • 0
    Hi, yes it is a security problem.

    If you have a support contract, please raise the issue.

    Also see https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/t/41243

    Barry
  • 0
    Cool! 

    Barry, are those longer lines also ACKs?  What do you get with cc get packetfilter timeouts?

    If you have 30 for ip_conntrack_tcp_timeout_last_ack, what happens if you do the following?

    cc set packetfilter timeouts ip_conntrack_tcp_timeout_last_ack 45


    In fact, I'm just guessing that that might make a difference.

    Cheers - Bob
  • 0
    Hi Barry.
    Tried your command suggestion.
    Wow. It's not a leak - it's a flood!!!
    In about one minute, there was more than 200 lines, from about 20 different users.
  • 0
    Hi Bob,

    Not all of the lines are ACK's; sorry I didn't realize the formatting got messed up.

    Here's some more:

    15:11:16.016548 IP 192.168.212.115.64904 > 93.184.216.146.443: R 1460965381:1460965381(0) win 0
    15:11:16.017419 IP 192.168.212.115.64904 > 93.184.216.146.443: R 1460965381:1460965381(0) win 0
    15:11:16.018258 IP 192.168.212.115.64897 > 23.212.40.65.443: R 27686594:27686594(0) win 0
    15:11:16.018446 IP 192.168.212.115.64897 > 23.212.40.65.443: R 27686594:27686594(0) win 0
    15:11:16.038580 IP 192.168.212.115.64884 > 54.200.93.219.443: R 1628813938:1628813938(0) win 0
    15:11:16.039826 IP 192.168.212.115.64884 > 54.200.93.219.443: R 1628813938:1628813938(0) win 0
    15:11:16.046071 IP 192.168.212.115.64851 > 54.200.119.231.443: R 2070869391:2070869391(0) win 0
    15:11:16.046971 IP 192.168.212.115.64851 > 54.200.119.231.443: R 2070869391:2070869391(0) win 0
    15:11:16.064098 IP 192.168.212.115.64895 > 31.13.66.49.443: R 59528668:59528668(0) win 0
    15:11:16.064935 IP 192.168.212.115.64895 > 31.13.66.49.443: R 59528668:59528668(0) win 0
    15:13:57.303054 IP 192.168.212.116.33597 > 74.125.224.240.80: R 4029553140:4029553140(0) win 0
    15:13:57.303924 IP 192.168.212.116.33597 > 74.125.224.240.80: R 4029553140:4029553140(0) win 0
    15:13:57.304790 IP 192.168.212.116.33597 > 74.125.224.240.80: R 4029553140:4029553140(0) win 0
    15:13:57.305650 IP 192.168.212.116.33597 > 74.125.224.240.80: R 4029553140:4029553140(0) win 0
    15:13:57.306511 IP 192.168.212.116.33597 > 74.125.224.240.80: R 4029553140:4029553140(0) win 0
    15:13:57.307371 IP 192.168.212.116.33597 > 74.125.224.240.80: R 4029553140:4029553140(0) win 0
    15:14:15.747440 IP 192.168.212.115.64905 > 23.212.43.153.443: R 1800310213:1800310213(0) win 0
    15:14:15.748339 IP 192.168.212.115.64905 > 23.212.43.153.443: R 1800310213:1800310213(0) win 0


    .116 is my Android phone, and .115 is an IPTV device.

    I ran the 'cc' command (and verified in /proc that it worked), but I'm still seeing some leaked ACKs.
    I'll check again in few more minutes

    Barry
  • 0
    Still seeing leaking ACKs and Resets.

    Barry
  • 0
    I have asked my ISP to check it also in his side, just to make sure it's really going out.
    after about an hour:

    Extended IP access list LOG
        10 permit ip *.*.*.* (my internal IPs) 0.255.255.255 any log (5169 matches)
        20 permit ip any any (All the rest) (6944018 matches)
  • 0
    Hi.

    Firewall - advanced - "Use strict TCP session handling", seems to help.

    I Wonder if this could have negative influence on my firewall behavior?
  • 0
    Goldy, I've only noticed one problem with Strict TCP, but it was severe enough that it forced me to turn it off:
    https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/t/40764

    Barry
  • 0
    Hi Barry.
    Since it's been long time ago, could you please check if it still persist?
  • 0
    Hi, 
    I don't quite understand how the strict tcp session handling affects this problem?
    Could anyone explain it to me before I try to turn it on on my production UTM? :-)

    Thanks.