Comments
-
Sorry for the long delay. Other things have been keeping me busy. The HTTP service rule is working as intended. The problem is HTTPS is not catching anything. Below is the HTTPS rule which is not catching anything. The comparable HTTP rule is catching. So I tried changing to a custom rule and THAT is not working either.…
-
The Regex expression you listed is not usable, as it is extremely wide open, meaning it catches things such as http://www.google.com/mysearch/6225432.5245235234.5254325.54252.542522 The reason I had originally configured it with https? was to prevent the above. There is no such "HTTP Access" on a NSA2600 6.5.4.6-79n. Here…
-
I also find it funny that I am labeld as a NEWBIE. I have been working with Sonicwall firewalls since the days of SOHO2 SOHO3, TELE3 and PRO100. I was an active member of the original Sonicwall Forum as well as the third party Sonicwall forums. I as an active member when Sonicwall changed to a new forum software and had to…
-
Yes, that is what I am trying to do. So for example a user does a Google search for widgets, and on of the websites is actually http://10.10.10.10/default.htm I want to be able to block that.
-
No sorry that does not help. I know very well how to create address objects and so forth. That is a manual process to be added AFTER THE FACT. I need to be able to block users from accessing IP Based websites at the time of attempt, not later.
-
Unfortunatly there is an issue in 6.5.3.x that we were experiencing that required us to go to a newer version per Sonicwall support.
-
Thanks
-
I realize it "should not matter" but I am working on resolving constant events being logged in the Windows Server application log concern certificate mismatch. I wanted to make sure before investigating that problem that it was not somehow caused or tied to different cipher suites being used.
-
Wow thanks for finding that great discussion. So once again Microsoft thinks they are better than everyone else by including a bit of information neither required or desired in that field.
-
More information: I am trying to figure out what the difference is in implementation between these cipher suites: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521 The first one is an available cipher suite in a Sonicwall NSA 2600 with firmware…
-
Support case number 43429731
-
OK, now that opened up another problem avenue. I am already forcing SSL checks as if the Intermediate was needed it would be failing regardless of DPI-SSL (Firewall Settings, SSL Control) Checking what certificates I have on the firewall, I see I already have that intermediate installed. HOWEVER, the certificate path is…
-
https://ace.cbp.dhs.gov/
-
NOW, here is another interesting tidbit: In Client DPI-SSL, if I uncheck "Always authenticate server before applying exclusion policy" then that website works. Again, regardless of what exclsion/inclusion objects I have selected on the Objects tab.
-
OK, this is even wierdererer than that: If I disable SSL Client Inspection on the zone, that website works fine. However NO DPI-SSL Client settings are applied to anything in that zone. If I enable SSL Client Inspection on the zone, enable DPI-SSL Client, that website gets blocked for ALL no matter what exclusion/inclusion…