Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 62 replies
  • Subscribers 2 subscribers
  • Views 135498 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

Despite Masquerading Internal Addresses Appear On WAN-Interface

Xavier2
Hi,

my Astaro (9.106-17) is placed on it's WAN-Interface behind another router.
The Astaro is the only device behind the other router and there's just one link
between them.

On the Astaro for all internal networks masquerading is switch on by rules like
'Internal network XX' to WAN-Interface.

Everything worked unsuspicious and quite well until yesterday.

On the external router I switched on a feature called Backroute Verify on the interface to the Astaro.. This means that incoming data packets are only accepted over this interface if outgoing response packets are routed over the same interface.

The subnet between the external router and the Astaro is 10.15.95.0/24.
Astaro has 10.15.95.10. the other has 10.15.95.20
Therefore the external router drops all packets not coming from an address within that subnet. This should be no problem since masquerading is turned on.


The other router logs dropped packets. 
In the logs I can see a lot of of dropped packets from source addresses
behind the Astaro.

How can this happen with masquerading turned on?

It seems like the Astaro doesn' substitute the source address with it's own WAN address.

Surfing, Mailing everything seems to work from inside the Astaros's internal LANs.

But some TCP messages [RST or FIN,ACK odr RST,ACK] go trough. TCP Seq is always '1'.
Only these types of packets. No TCP payload packets and also no UDP.


I can see the with Wireshark too.

I've no clue.
What can I check?

Best regards
Xavier


-----------------------------

Sorry, by posting this messages there appear also some payload packets with internal addresses on the WAN Interface.


This thread was automatically locked due to age.
Parents
  • 0
    Hi,
    I got an answer from the sophos support. But it's not satisfying.

    Here in German:

    es sieht so aus das es sich bei den unmaskierte Paketen, die auf der ESX Firewall gedroppt werden, um FIN/ACK Pakete handelt, die der Client noch nach der Beendigung der Verbindung schickt.
    Da hier bereits die Verbindungen aus der Conntrack Table gelöscht sind, gehen die Pakete unmaskiert raus und kommen daher auch auf der ESX Firewall unmaskiert an.

    Somit scheint ein Paket nach der Beendigung der Session zu kommen, da müsste man schauen, durch welches Gerät im Netzwerk dies verursacht wird


    and in english:

    It looks like the unmasked packets that are dropped on the esx firewall are fin/ack packets which are sent by the client after the connection has allready been closed.
    At this point of time the connections are allready deleted from the contrack table and thus the packets are sent out and arrive unmasked.

    Therefore it seems there are packets send out after the session has allready been closed, you should look for the device on the network that is causing this.

    -------------------------------------------------------------------------------------

    I was able to reproduce this behaviour on different machines (Windows, Linux, virtualized and native). So I don't think this is the root of the problem.

    What I noticed is, that the problem only occurs on Interfaces that have a router in front of it that is holding the internet connection. I have one connection on this firewall that is directly connected to the internet and the problem does not arise here.

    I asked them to look further into this problem and also refered to this thread and told them that even Moderators from this forum were able to reproduce the problem.

    I will get back as soon as I get an answer.
Reply
  • 0
    Hi,
    I got an answer from the sophos support. But it's not satisfying.

    Here in German:

    es sieht so aus das es sich bei den unmaskierte Paketen, die auf der ESX Firewall gedroppt werden, um FIN/ACK Pakete handelt, die der Client noch nach der Beendigung der Verbindung schickt.
    Da hier bereits die Verbindungen aus der Conntrack Table gelöscht sind, gehen die Pakete unmaskiert raus und kommen daher auch auf der ESX Firewall unmaskiert an.

    Somit scheint ein Paket nach der Beendigung der Session zu kommen, da müsste man schauen, durch welches Gerät im Netzwerk dies verursacht wird


    and in english:

    It looks like the unmasked packets that are dropped on the esx firewall are fin/ack packets which are sent by the client after the connection has allready been closed.
    At this point of time the connections are allready deleted from the contrack table and thus the packets are sent out and arrive unmasked.

    Therefore it seems there are packets send out after the session has allready been closed, you should look for the device on the network that is causing this.

    -------------------------------------------------------------------------------------

    I was able to reproduce this behaviour on different machines (Windows, Linux, virtualized and native). So I don't think this is the root of the problem.

    What I noticed is, that the problem only occurs on Interfaces that have a router in front of it that is holding the internet connection. I have one connection on this firewall that is directly connected to the internet and the problem does not arise here.

    I asked them to look further into this problem and also refered to this thread and told them that even Moderators from this forum were able to reproduce the problem.

    I will get back as soon as I get an answer.
Children
  • 0 in reply to T-Roc_01
    Hi T-Roc,

    thank you for the information.


    Hi,
    It looks like the unmasked packets that are dropped on the esx firewall are fin/ack packets which are sent by the client after the connection has allready been closed.
    At this point of time the connections are allready deleted from the contrack table and thus the packets are sent out and arrive unmasked.

    Therefore it seems there are packets send out after the session has allready been closed, you should look for the device on the network that is causing this.


    Of course there are a lot of FIN/ACK as already mentioned.
    But there are also several TCP payload datagramms.

    In case of my UTM and my VoIP devices this is definitely not the whole story.
    I can see complete SIP UDP datagramms as you can in the attached trace. 
    (10.15.11.0/24 is a network behind the UTM.)

    Nevertheless Sophos's argumentation isn't satisfying. 
    I know no other firewall passing through such datagramms after a connection is closed.
    It reveals information on the network behind the firewall!
    This is a security issue.


    Best regards
    Xavier
Cookie Information Banner