Sophos Firewall: v19.0 EAP2: Feedback and experiences

Hello

just want to provide feedback about the design of the product after many years of using most of firewalls vendors and what really i think big limitation of Sophos firewall which i met in my installations : 

- There is no virtual instance (almost vendors have this features)

- Link between wan zone and gateway which make limitation of routing

- VPN is linked to WAN zone which make big limitation for segmentation, exp for banking they have many WANs (MPLS, Internet, LL, etc ...) and these links should be separated and according to PCIDSS all trafic goes overs external link should be encrypted so in the actual design of Sophos all these links should be configured on the WAN zone which make lot of routing and segmentation problems.

-  Application filter not users aware link web filter (what's the logic behind this !) so we need to configure firewall policy for each users group if they have different application filter while with web filter we can use only one ! before it was configurable on the user group and make life easy now it's make life hard ;-)

thank you

Hi,

not sure what you mean by no virtual instance, there are files to create virtual machines? Virtual version s are not usually released during EAP, but at GA. 

Ian

Virtual Domains as a concept is on the roadmap but from my point of view, the use case of this feature is proportionally small for Sophos customers. Most customers are not ISPs or that kind of "MSP Partner firewalls" to have to separate multiple firewalls on one piece of hardware. 

To separate the data plane from the management plane is something different, which is more useful. 

And the other parts of this feedback is already on the roadmap for future implementation. 

Hi Toni

Yes agree with you about virtual domains that it's small demand but it's important for competing with others vendors.

From my side this points is the least important one but the others three points are very important and can make difference and problem  with customers installation.

Also i forget to mention concept issue with Sophos with SD-WAN and routing, from network point of view and with ALL vendors there is three routes types:

- Directly connected subnet : these routes are added automatically by the system with metric zero and can't be changed or deleted 

- Policy based route (which include SD-WAN and IPSec) with metric > zero

- Static/dynamic route : are manually/protocols added with metric > zero

The logical priority is of these routes is Directly connected then PBR then Static/dynamic but for Sophos there is confusion between directly connected and static which make a lot of problem when using SD-WAN and IPSec. i did some dig in the advanced shell and found that the firewall treat the directly connected and static as one category which i think it's not correct !

Directly connected subnet MUST NOT be managed/changed by users and MUST HAVE the first precedence for routing.

I did some test and showed the result and real demo to local Sophos presales team, in fact when i changed the routing precedence SD-WAN the static the firewall routes local subnet trafic based on the SD-WAN policy !!!

best regards     

If you do this (directly connected routes higher precedence than any other routes) you will later revoke the SD-WAN/Network Capabilities. 

In the end, the plan is to bring the packet to the other end, no matter what which route you take. By using SD-WAN/Network Routes, you can force a asymmetric routing, and basically you do not care, because the other appliance will assemble the packets once again and the connection is there. This is not possible, if you stick to the strict world. 

Some vendors resolve this by creating SD-WAN Interfaces (which is a link bonding) and simply send the packet to this interface. Other vendors could potentially do this by the implementation, SFOS is doing. It is about "Old world vs new world". 

You can potentially still use the old world and leave it. 

But there are certain cases (especially in the future of SD-Network) which does not want to follow this strict "Direct attached network". 

And your statements are correct, but that is not the goal. SD-WAN PBR are there to overwrite the old (lets call them Legacy RFC approaches) and do something completely different. Because you can do what ever you want with Sd-WAN. You want to route one packet (only the initial packet?) to another interface - Go ahead, do it. The appliance does not stop you. 

That is not a issue, it is a preparation for the future. See SD-Network in Public cloud implementation. Try to change a Default gateway of a EC2 instance in AWS. It will go offline. 

You can compare SD-WAN PBR vs static as "Wild West" vs "RFC World". I wrote something about this here: community.sophos.com/.../routing-in-xgv18-with-sd-wan-pbr

Hi

not agree with you, directly connected are system route (they are added and removed by system) and different from static and should not be included in SD-WAN routing.

As you said the matter is to bring the packet to other side where it should be but directly connected are locally and must be routed locally and the actual concept the local subnet are routed to remote site.

Finally the SD-WAN is PBR with more granularity, even with Sophos in old version (also with Cyberoam) it was called PBR then with the boom of SD-WAN you changed the name :-).

let me explain in more details the issue with the actual concept : 

let say i have XGS boxes with tow interfaces :

- Port 1 : 192.168.1.1/24

- Port 2 : 192.168.2.1/24

- Port 3 : 192.168.3.1/24

Then i configured SD-WAN to route internet trafic over gateway 192.168.3.2 on Port3

The i tried to ping from PC connected on Port1 (192.168.1.2) to PC connected to Port2 (192.168.2.2)  which didn't work, the trace showed that the ping was routed over Port3 according to the SD-WAN policy !

This is has nothing related with new routing / future routing.

best regards 

It will come together quite soon. Direct connected networks are not always locally. See SD-Network. I perfectly understand your point, but that is the design to go forward. And you can workaround this by simply not use "All" in SD-WAN. SD-WAN PBR will overwrite everything and it needs to do this for further deployments. Asymmetrical routing was the fear of administrators. Nowadays it is pretty standard to do this on a true SD-Network design.

If you do not want to interact with this, change the Routing precedence and you are fine. 

Or you could simply replace the Internet PBR by using the new Internetv4 Object, like mentioned in my link above. 

Direct connected networks are not always locally !!! how this ? even if the local network is extended over wan there is others protocols to deal with that exp vxlan and not with sd-wan.

i see as workaround to the issue Sophos changed the default route precedence Static route, SD-WAN route, VPN route which not the case with old version also not conform to your preview statement about sd-wan routing neither about PBR (sd-wan in fact is PBR) in general ! 

anyway it's your choice to do but from my point of view as network expert and system integrator isn't correct and added to my preview points in many cases Sophos not fulfill customers requirement and others venders are preferred.

good day 

I think brahim ayari1 is mistaken in terms of what SD-WAN should overwrite, but the issue does raise a potential addition to the XG: Right now you define an ordering of routing precedence which is Static, SD-WAN, VPN (and then a default). What if you created another category called "Local" which acts as Brahim suggests and routes traffic between local Ports? Make it explicit (though the routes in this category are dynamically added based on the IP addresses of the Ports, not statically specified by the Admin).

The default priority would then be: Static, Local, SD-WAN, VPN (and then default), and could be reordered. If someone wants SD-WAN to take precedence for cool potentials, they could put Local before or after VPN instead. Or perhaps have a checkbox in SD-WAN routes that says "Do not override local Port-Port routing" or something like that? This would be something like the current "Route only through specified gateways" checkbox.

It is actually not the correct approach, as Static explicitly use the old world. 

By breaking up the "Static" into the world: local, static, dynamic. You would stop working with the "metric" system build in RFCs. Direct connected routes are flagged by the linux system. 

The new world of SD-Network will introduce plenty of cases, which does not follow this principle. Check AWS / Azure implementation. And to give the administrator the option to build products in this, will be the next steps. 

I think it's no problem of breaking static route but not to include system routes (directly connected ) in static routes.

AWS / Azure use overly concept which uses others protocols to extend and routes trafic between sites.

To be clear SD-WAN isn't extra thing or reinventing the wheel it's just advanced PBR based on application, latency, etc ... but at the end it's PBR routing mechanism, 

I think it's no problem of breaking static route but not to include system routes (directly connected ) in static routes.

I think it's no problem of breaking static route but not to include system routes (directly connected ) in static routes.