Evaluation Concerns! Forum members great, Sophos engineers... not so much.

It is possible that a DROP or REJECT rule at the end of the firewall rules might solve this, but I have not tried it.

A friend is upgrading to 9.2 this weekend; I will try to test next week.

Barry

BarryG,

Thanks for responding. No I haven't taken it up with reseller yet, being an eval unit I really didn't want to bother him with it before the sale. Part of my due diligence is pouring through these threads and seeing what kind of help users are getting from Sophos and it ain't good.

I know my post sounds harsh (especially for an icebreaker), but I do feel reading the responses that users are getting from support warrant my comment about "flippant and utterly incompetent", especially when you couple the responses with the timeline and the apparent lack of fix for something one could argue should be pretty high priority in a "security" appliance.

Sophos buying Astaro means they are supposed to "own" it. I don't see support doing that here. I read one poor guy's post about their response to Country Block Exceptions From not working being to "Just allow all country wide". "No ETA for fixing it!" That's NOT an answer! Fix it (or take the feature out). That's what I mean by not "owning" it.

Here's their responses to the leakage...

https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/p/41243/144438#144438

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.

Answers why it is potentially happening but does NOT solve the issue.

https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/p/41243/144444#144444

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.

Classic finger pointing elsewhere, good thing Sophos doesn't make the router he was using.

https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/p/41243/144451#144451

The technician analysed this togehter with an sophos escalation egnineer:
 Even in your latest dumps there are fin, acks and reset packets. These are definitely packets that arrive unmasked, because the connection tracking table in your firewall has been notified about the end of the communication and hence deleted the connection from the table.
 If another packet from this communication arrives, after the connection got deleted from the table, it will not be masked.
 This is a technical condition which also arise with different firewalls, background to this is an any allow rule in the firewall. Without this rule, excess packets would not be transmitted.

 You cannot avoid this with this active firewall-rule, it is not a mistake of the UTM and can therefore not be influenced. The technician will close the ticket. 

So everyone (mods included) has misconfigured their rules in a dangerous way and it is NOT a mistake of the UTM, yet as OP mentions Cisco, Juniper, etc... somehow magically "can be influenced" not to do this

https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/p/41413/145376#145376

"Its not actually a known issue, its been reported before, but the fault has always been with the network configuration when it has been further examined.
 I've checked your Utm and am confident that there are no settings on here that would route internal traffic directly through to your external WAN interface."

Translation: LA LA LA LA LA... I can't hear you.

https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/p/41413/145380#145380

"I would suspect you are seeing this due to a configuration error with respect to cabling or your switch configuration.
 Please can you ensure that your vlans are separated and that you are not using the UTM as a trunk interface?"

Okay I'm getting confused here, it's not really a problem, but you've misconfigured your rules which is a problem, and your physical cables to your nonexistent virtual lan are whacked.


I'm having a hard time talking myself into paying "Enterprise" support for these kinds of "support" responses. My current UTM was written by ONE guy and if I found a bug I called or emailed him and within literally 15 minutes he had fixed, recompiled, and emailed me new version. Also, support was free with the purchase of the software. Alas, after 10 faithful years of service, software is EOL.

BarryG,

Thanks for responding. No I haven't taken it up with reseller yet, being an eval unit I really didn't want to bother him with it before the sale. Part of my due diligence is pouring through these threads and seeing what kind of help users are getting from Sophos and it ain't good.

I know my post sounds harsh (especially for an icebreaker), but I do feel reading the responses that users are getting from support warrant my comment about "flippant and utterly incompetent", especially when you couple the responses with the timeline and the apparent lack of fix for something one could argue should be pretty high priority in a "security" appliance.

Sophos buying Astaro means they are supposed to "own" it. I don't see support doing that here. I read one poor guy's post about their response to Country Block Exceptions From not working being to "Just allow all country wide". "No ETA for fixing it!" That's NOT an answer! Fix it (or take the feature out). That's what I mean by not "owning" it.

Here's their responses to the leakage...

https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/p/41243/144438#144438

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.

Answers why it is potentially happening but does NOT solve the issue.

https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/p/41243/144444#144444

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.

Classic finger pointing elsewhere, good thing Sophos doesn't make the router he was using.

https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/p/41243/144451#144451

The technician analysed this togehter with an sophos escalation egnineer:
 Even in your latest dumps there are fin, acks and reset packets. These are definitely packets that arrive unmasked, because the connection tracking table in your firewall has been notified about the end of the communication and hence deleted the connection from the table.
 If another packet from this communication arrives, after the connection got deleted from the table, it will not be masked.
 This is a technical condition which also arise with different firewalls, background to this is an any allow rule in the firewall. Without this rule, excess packets would not be transmitted.

 You cannot avoid this with this active firewall-rule, it is not a mistake of the UTM and can therefore not be influenced. The technician will close the ticket. 

So everyone (mods included) has misconfigured their rules in a dangerous way and it is NOT a mistake of the UTM, yet as OP mentions Cisco, Juniper, etc... somehow magically "can be influenced" not to do this

https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/p/41413/145376#145376

"Its not actually a known issue, its been reported before, but the fault has always been with the network configuration when it has been further examined.
 I've checked your Utm and am confident that there are no settings on here that would route internal traffic directly through to your external WAN interface."

Translation: LA LA LA LA LA... I can't hear you.

https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/p/41413/145380#145380

"I would suspect you are seeing this due to a configuration error with respect to cabling or your switch configuration.
 Please can you ensure that your vlans are separated and that you are not using the UTM as a trunk interface?"

Okay I'm getting confused here, it's not really a problem, but you've misconfigured your rules which is a problem, and your physical cables to your nonexistent virtual lan are whacked.


I'm having a hard time talking myself into paying "Enterprise" support for these kinds of "support" responses. My current UTM was written by ONE guy and if I found a bug I called or emailed him and within literally 15 minutes he had fixed, recompiled, and emailed me new version. Also, support was free with the purchase of the software. Alas, after 10 faithful years of service, software is EOL.