Despite Masquerading Internal Addresses Appear On WAN-Interface

This is kind of interessting. In my config there are also a couple of devices configured on the affected interface.
I'm doing my best to get some information but till now sophos seemed not very "interested" in the problem.

I hope I'll get some answers from the escalation team next week. I will try to get them have a look at this thread, too.

Best regards
T-Roc

Hi T-Roc,

don't get me wrong.
The problem persists concerning traffic from all interfaces to WAN, not just
on that one with the phones.

Best regards
Xavier

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.

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

Hi, I totally agree with you. This is a security issue in my opinion and that's what I wrote them. I expect a firewall to drop the packets or at least mask them in this Situation. Is there any Moderator that has connections to Sophos?

Hi,

I don't have 'connections', but I am probably one of the people they're referring to.

What I have talked about in the past, is that hosting web servers (http/https) behind the firewall tends to create a lot of noise in the logs from 'expired' tcp connections, where the client or server tries to close the connection after it's already expired from the firewall's connection tracker, and then the firewall drops and logs the FIN/ACK and/or RST packets..

Your problem may sound similar, but I don't think it's the same.

AFAIK, in the webserver scenario, the firewall does not send out any packets.

I'm confused though; SIP is UDP, so why are there FIN/ACKs at all?

Barry

Hi Barry,

the UTM leaks both.
TCP datagramms, mostly FIN/ACKs and complete UDP datagramms.
The first come from all kind of devices (Windows PCs, Linux servers, AppleTVs,...) the latter from the phones using UTM's VoIP gateway.

As I first discovered this I filtered always for TCP connections that's why I didn't see the SIP UDPs.

Xavier

Hi Barry, i'm a little confused. I thought you were able to reproduce the Problem? For the http/https connections could you explain why the firewall drops the connection whilst the Server seems to have not closed it yet and especially why these packets don't get masked then? is this a normal behaviour or  shouldn't these also be masked or at least dropped? Would you agree this is a security issue?

We have a couple proxy systems behind the firewall so there are http/https connections.

Hi,
I got an answer from the sophos support.

Here is the answer:

I looked at the dumps again and I can't see any umasked packets leaving the firewall.
As the customer allready mentioned the problem only exists with a router (avm fritzbox in my case) installed in front of the utm, so I guess it is not a mistake in the config nor in the utm.
the customer could for example install a different router and monitor the traffic.
the description from the customer indicates that the problem arises from the router.
-------------------------------------------------------------------------------------

Well, I never said that the problem arises from the router so I guess there won't be any more information or effort from sophos in this case. Nevertheless I wrote back that xavier2 ist using a cisco router and the technician from sophos contradicts itself. In the first answer he wrote that the packets are sent out unmasked and now there are no packets sent out at all.

Sorry, I tried.
I will of course tell you if there will be any more information from sophos.

I got another answer from sophos. They are still on this problem and are very eager to solve it. I will tell you if they find the problem.