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

Hi,

I have not heard of a fix for this.
I have not had a chance to re-test it on 9.2x yet.

My systems at work are not NAT'd so this wouldn't apply so I cannot open a support case.

Have you asked your reseller or Sophos support about it?

afaict, only one person mentioned opening a support case; the response they initially got was odd, but I don't know if the user followed up.

Barry

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.

Market silk purses and ship sow's ears?

Remember this is almost entirely a user-to-user bulletin with little to no official Sophos involvement.  It is not necessarily a complete view of the support and engineering situation.

Ölm post about Pre-Sales Support:  https://www.astaro.org/gateway-products/web-protection-web-filtering-application-visibility-control/51620-9-200-web-filtering-causing-slow-internet-browsing-9.html#post268924

Work with your partner on the possibilities of taking support on a few test drives to gauge the standard/premium processes and procedures.

Take full advantage any pre-purchase, or pre-large-purchase, support possibilities: 

• Document every glitch, miss-documentation and malfunction.
  
• Build out as big a test environment as you can and break the product, or prove it isn't broken, before you've bought it.
  
• Push everything you can through the pre-sales engineers, support, sales and partner(s).
  
• Published (and tested) public patches/updates should be preferable to promises and hotfixes. 
  

Make sure what you think you are buying and what they think they are selling are the same:

• Document your assumptions and expectations and get clear confirmation that you aren't buying misunderstandings.  (Performance, capabilities, functionality, compatibility.)
  
• Get, in writing, confirmation that your intended design and implementation is a supported and recommended configuration.  Just because it is documented doesn't mean it works well (or at all).
  

It has been more than a year since I've interacted with Sophos Support (add salt, as needed):

Previously (2013) I'd written

[URL="https://www.astaro.org/gateway-products/general-discussion/47442-support-feedback-please.html#post233566"]I think "Platinum" is very inexpensive for 24x7 access to support - but don't think that that will mean support is working on your problem 24x7.

I've spent days waiting to hear anything back after an escalation - calling daily sometimes for a status update which often was "it has been escalated" then spotty responses after work appeared to begin. (These woes relate to the webproxy.)

I won't pretend I'm the ideal customer or that support is ideal.[/URL]

And earlier this year I wrote: 

"Premium support is inexpensive, I feel, but if I were involved in another serious UTM deployment I'd certainly be looking for a partner to help fill in gaps (such as hold spares or provide a short term software license on demand in the event of a hardware appliance failure) and keep us and any problems on Sophos sales/support/engineering's radar."

Call it cynicism, or experience, I don't think of it as evaluating/buying "support", "solutions" or even "products" instead, hopefully, "semi-specific set(s) of problems" and "help sorting out the(ir) mess".

teched,

Thanks for the link, might as well make some noise before deciding if I want to keep this pandora's box. I've never understood why companies buy up cool stuff like this and then take a dump all over it. Just finding out now I'm one of the "lucky" 1% who got pushed 9.301-2 early and learning about neat features like corrupted RPM Database and whatnot.

I've already gone into this with an absolute requirement of having a pair, I'm just trying to figure out now if this will be a pair of Aces or deuces.

GetParanoid, I suggest you take up your concerns with your reseller, nothing I, or anyone else can say on this board would probably change your mind; As another poster said, realize this is a user-to-user board, and to get access to Sophos Support (since you are in an evaluation phase), I would contact your reseller.

Welcome to the forum.

...
First post 10/13/2013 Despite Masquerading Internal Addresses Appear On WAN-Interface Last post 05-21-2014

First post 10/14/2013 Internal IP in IP Packet from Internet???? Last post 10/14/2013

On 12/23/2013 TheDrew finds Workaround Rule

First post 2/23/2014 Strange Masquerading Issue Last post 3/21/2014

On 2/28/2014 Goldy finds another workaround of turning on Use strict TCP session handling. Unfortunately BarryG points out this breaks login to Network Solutions (which undoubtedly means there are other breaks as well).

Is this a problem in your environment? Not everybody was affected by this. I initially had the problem that was only caused by android phones and some iphones. Strict traffic handling fixed it mostly but not all the way. 
I did revisit all my rules and removed the rules that had allow ANY traffic from mobile devices to ANY with more controlled rules and have since updated my system multiple times.
As of now I don't have this problem. As others have pointed out, we have a nice little community here that helps each other on most issues but your concerns can only be alleviated by your reseller.

FWIW, I left my home firewall (version 9.113) running tcpdump for the last 20+ hours and there were no leaked packets.

I do have "Use strict TCP session handling" ON; it seems to no longer cause problems with Network Solutions.

Barry

Other than a few issues I'm happy with the UTM (SG330) coming from Juniper SRX it's much nicer.

For the functionality it provides its one of the least problematic UTMs.

Excellent comments everyone. Thanks for chiming in, it certainly is much appreciated and helpful with the decision making process.

Understood on the end user to end user advice, I know everyone in here is trying to be helpful and I'm not trying to take any of my concerns out on you fine people. There are resellers and some Sophos employees in here as well, have already spoken with a few of both in fact, and they have all been very helpful, so I do think these comments make it up the chain (and they should). Even if I decide to go another route at least hopefully some of my ranting may benefit some others by complaining publicly about what I see wrong. Constructive criticism with hopeful end results is the goal here.

BarryG / teched / BrucekConvergent, as mentioned earlier I haven't taken these things up with my reseller yet because he's technically not my reseller (I'm evaluating, unsold). He's been fantastic, spent an hour with me just on initial inquiry about the product, a couple of hours SUMming in for my list of requirements. Followed up with me already about my concerns and wants to have them all addressed for me.

Billybob / BarryG, this is good news I will investigate further. Although not thrilled about the end user having to write rules for something that competitors have baked in, or seeing "engineers" stating it's not doable. Obviously we all know that's false.

Ross86, these kind of real world comments are what I'm in here for in the first place. Thanks for the experience you're providing. It does help offset the support concerns.