Tech Tips: SonicOSX Policies
shiprasahu93
Moderator
Hello All,
SonicOSX is the new SonicWall firewall platform that allows granular control and enforcement of dynamic Layer 7 applications. SonicOSX combines Layer 3 to Layer 7 rules into a single rule called Security Policy.
This new architecture contains various types of policies as below:
1) Security Policy:
Security Policy in SonicOSX merges all the separate components in SonicOS like access rules, app rules, cfs policy, app control, botnet filter, geo-ip filter, ips, gav, anti-spyware into a single rule. The set of these rules combined into one is termed as security policy of an organization.
2) NAT Policy:
This is similar to the NAT policy on SonicOS. It helps in performing NAT in inbound/outbound directions as necessary.
3) Route Policy:
This is similar to the Routing section on SonicOS. Policy Based Routing (PBR) allows you to create extended static routes to provide more flexible and granular traffic handling capabilities.
4) Decryption Policy:
Decryption policy in SonicOSX merges all the separate components in SonicOS like exclude/include objects, exclude include websites and exclude/include users in DPI-SSL and DPI-SSH into a single rule. It also enables user to take decision on what traffic needs to be decrypted and what needs to be bypassed.
5) DoS Policy:
DoS policy in SonicOSX merges all the separate components in SonicOS like DoS attacks, flood protection, DNS rebinding, connection limiting, SMURF, Land attacks etc into a single rule. It also enables user to take decision on what traffic needs to be protected and what needs to be bypassed.
6) End Point Policy:
This is similar to Guest Services on Endpoints on SonicOS.
I hope you all find this information useful.
Thanks!!
Shipra Sahu
Technical Support Advisor, Premier Services
Comments
Great
it would be great if the NAT & Routes were incorporated into the Security Policy
so you could route by User group or port forward using app objects not just the service,
so for example you could NAT using the App match object like HTTPS incoming to two or more internal servers based on a Match object like host header etc..... oviously this rule would need to be used in conjuction with the Server DPI-SSL
That's just one example but there would be other rules that would be able to take advantage of features like this.. opening up the possibilty to port forward the same TCP/UDP ports using one public IP to several internal destinations based on the application would be amazing cool feature I think,
one of the reasons I like Sonicwalls so much is because there are always several ways to acheive the same functions and make it easy to find a workaround.
This shouldn't be hard to implement as you can already NAT using FQDNs , and you can Route via FQDNs and App objects.
Just an Idea, maybe you could put it forwards as a RFE
Nice
good job
Thank you @Kiritharan. I am glad that these were helpful.
Shipra Sahu
Technical Support Advisor, Premier Services
Welcome @shiprasahu93