Sonicwall CFS HTTPS

I have a sonicwall NSA 2400 using application rules to perform content filtering.  We recently acitvated the HTTPS portion of the CFS.  Since then websites that are trusted are randomly working and the being blocked then a few hours later working again.  It seems like the HTTPS CFS controls on sonicwall just plain old dont work.  Has anyone had this same issue and what did you do to resolve?
jcola1939Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Blue Street TechLast KnightCommented:
Hi jcola1939,

HTTPS CFS filtering definitely works but I have seen this before in old units with outdated firmware versions.

Update your SonicOS firmware version to the latest release (which should be SonicOS 5.9.0.1.100o).

If it's up-to-date reboot your firewall.

Let me know how it goes!
0
jcola1939Author Commented:
I am currently on 5.8.1.5-46o  I will try the firmware update and let you know how I make out.
0
Blue Street TechLast KnightCommented:
Sounds good!

Here is a guide on how to properly upgrade your firmware: https://www.fuzeqna.com/sonicwallkb/ext/kbdetail.aspx?kbid=5640
0
The Ultimate Tool Kit for Technolgy Solution Provi

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more!

jcola1939Author Commented:
I loaded the newest firmare on two of my three Sonicwall's.  I have reports that some of the sites that have been having issues seem to be working steadily.  However it could be too early to tell since it tends to bounce up and down.

We are still having hit or miss issues with google.  Google redirects to https://www.google.com and still seems to be acting up at times.  If you run a packet trace you will see the connection initially allowed to google servers and then all of a sudden it will just start blocking the traffic.
0
jcola1939Author Commented:
Below is an example of a dropped packet to google.  I removed my IP address.

Packet Detail.......

Ethernet Header
 Ether Type: IP(0x800), Src=[c4:71:fe:76:d9:db], Dst=[00:17:c5:c0:79:71]
IP Packet Header
 IP Type: TCP(0x6), Src=[74.125.224.114], Dst=[xxx.xxx.xxx.xxx]
TCP Packet Header
 TCP Flags = [ACK,], Src=[443], Dst=[3436], Checksum=0xa55b
Application Header
 HTTPS
Value:[0]
DROPPED, Drop Code: 39(Enforced firewall rule), Module Id: 25(network), (Ref.Id: _5384_uyHtJcpfngKrRmv) 1:1)


Hex Dump -------
 0017c5c0 7971c471 fe76d9db 08004500 05bcd6b5 00003806 *....yq.q.v....E.......8.*
 08aa4a7d e072c0a8 746401bb 0d6c201b 1eb8a2fd d8ce5010 *..J}.r..td...l .......P.*
 a747a55b 00001603 01005102 00004d03 01524ecf 9f1aa02b *.G.[......Q...M..RN....+*
 81564d0c 53899729 8d748fd6 65492751 afa5df2b f2d3f6b8 *.VM.S..).t..eI'Q...+....*
 6920f08e 010d42f2 65a6767b d247081c 05889433 ce615a9c *i ....B.e.v{.G.....3.aZ.*
 1ac7914b 7d4340cb 9ff00005 000005ff 01000100 1603010c *...K}C@.................*
 130b000c 0f000c0c 00047a30 82047630 82035ea0 03020102 *..........z0..v0..^.....*
 020850c7 1e48bcc5 0676300d 06092a86 4886f70d 01010505 *..P..H...v0...*.H.......*
 00304931 0b300906 03550406 13025553 31133011 06035504 *.0I1.0...U....US1.0...U.*
 0a130a47 6f6f676c 6520496e 63312530 23060355 0403131c *...Google Inc1%0#..U....*
 476f6f67 6c652049 6e746572 6e657420 41757468 6f726974 *Google Internet Authorit*
 79204732 301e170d 31333039 31313131 30343338 5a170d31 *y G20...130911110438Z..1*
 34303931 31313130 3433385a 3068310b 30090603 55040613 *40911110438Z0h1.0...U...*
 02555331 13301106 03550408 0c0a4361 6c69666f 726e6961 *.US1.0...U....California*
 31163014 06035504 070c0d4d 6f756e74 61696e20 56696577 *1.0...U....Mountain View*
 31133011 06035504 0a0c0a47 6f6f676c 6520496e 63311730 *1.0...U....Google Inc1.0*
 15060355 04030c0e 7777772e 676f6f67 6c652e63 6f6d3082 *...U....www.google.com0.*
 0122300d 06092a86 4886f70d 01010105 00038201 0f003082 *."0...*.H.............0.*
 010a0282 010100ab 4daf9190 95111836 01d9ce13 dfcd2e20 *........M......6....... *
 8d27fd28 c5efbb3b b780bf73 9cdb14ca 09a4ff7d 7ac68cc9 *.'.(...;...s.......}z...*
 d83fe839 a68bcc8b 6a5e20f5 d87940a7 38d77728 68f57f84 *.?.9....j^ ..y@.8.w(h...*
 9a2cf233 a087c4af 0b1810ca b9181592 12a5d7bc f48a6eff *.,.3..................n.*
 cd214e8d 4ff14577 91af418d cf2ad078 f8308b5d 6ccb5011 *.!N.O.Ew..A..*.x.0.]l.P.*
 31a8661c c3e17b6d fbade65f d157fb85 6b38bc9e 544e8170 *1.f...{m..._.W..k8..TN.p*
 79f4b442 8dba3a7e 223bfa48 e1f8206d 7945c9b8 67748116 *y..B..:~";.H.. myE..gt..*
 26d3c295 9cb38cde a8b44738 d84ada8b c434c06c c8005561 *&.........G8.J...4.l..Ua*
 4de6129c 36dd11d2 160118c3 0ebf21c8 0d75c059 5960cca3 *M...6.........!..u.YY`..*
 07caba6f 8d2c1cb6 ce2730be b13bb6ca cca2d965 b7d0e474 *...o.,...'0..;.....e...t*
 519728fa 78623e68 da29365d 5b31bc37 42e97958 0e6ceb02 *Q.(.xb.h.)6][1.7B.yX.l..*
 03010001 a3820141 3082013d 301d0603 551d2504 16301406 *.......A0..=0...U.%..0..*
 082b0601 05050703 0106082b 06010505 07030230 19060355 *.+.........+.......0...U*
 1d110412 3010820e 7777772e 676f6f67 6c652e63 6f6d3068 *....0...www.google.com0h*
 06082b06 01050507 0101045c 305a302b 06082b06 01050507 *..+........\0Z0+..+.....*
 3002861f 68747470 3a2f2f70 6b692e67 6f6f676c 652e636f *0...http:..pki.google.co*
 6d2f4749 4147322e 63727430 2b06082b 06010505 07300186 *m.GIAG2.crt0+..+.....0..*
 1f687474 703a2f2f 636c6965 6e747331 2e676f6f 676c652e *.http:..clients1.google.*
 636f6d2f 6f637370 301d0603 551d0e04 16041459 dc97b34b *com.ocsp0...U......Y...K*
 11320a17 de4fdda7 354b95c3 03fa5f30 0c060355 1d130101 *.2...O..5K...._0...U....*
 ff040230 00301f06 03551d23 04183016 80144add 06161bbc *...0.0...U.#..0...J.....*
 f668b576 f581b6bb 621aba5a 812f3017 0603551d 20041030 *.h.v....b..Z..0...U. ..0*
 0e300c06 0a2b0601 0401d679 02050130 30060355 1d1f0429 *.0...+.....y...00..U...)*
 30273025 a023a021 861f6874 74703a2f 2f706b69 2e676f6f *0'0%.#.!..http:..pki.goo*
 676c652e 636f6d2f 47494147 322e6372 6c300d06 092a8648 *gle.com.GIAG2.crl0...*.H*
 86f70d01 01050500 03820101 00683adf 5745a10f 9d101ad1 *.............h:.WE......*
 89d54974 fc2b94cd e1a65f86 452d65db 5aefbf01 dd4d1dba *..It.+...._.E-_e.Z....M..*
 b5d0d8a9 f4872133 d0697bbe 566a844c f3639006 ec99151e *......!3.i{.Vj.L.c......*
 414181de 5f7dca52 d8800bdd 72fb7f5c 95df2358 e993fd38 *AA.._}.R....r..\..#X...8*
 1f974311 6ad6f686 f8dd1209 6203e597 1afdcf7d cc8fe9cf *..C.j.......b......}....*
 5fc9b6a7 ef4ef455 0bf8422e 56d8f205 60725099 eb1bf29c *_....N.U..B.V...`rP.....*
 afcccae3 06cfdd2c c5a7b578 94b7804a 44b273a6 cced0de7 *.......,...x...JD.s.....*
 d830feba 73b8d432 e6b638dd fd97af97 45e133a3 06ab438b *.0..s..2..8.....E.3...C.*
 2390bd74 dd30db84 375c36b5 c949f0ee 9c5e8cfa 6a3dd70f *#..t.0..7\6..I...^..j=..*
 5941fa24 5178c8b7 59f03cd4 0e81d9c9 78d459e7 3c73630a *YA.$Qx..Y.......x.Y..sc.*
 fed01781 2edc119f 8d6eb917 e73ba944 9c8b3ac4 b951e88d *.........n...;.D..:..Q..*
 4c0929b5 e2000408 30820404 308202ec a0030201 02020302 *L.).....0...0...........*
 3a69300d 06092a86 4886f70d 01010505 00304231 0b300906 *:i0...*.H........0B1.0..*
 03550406 13025553 31163014 06035504 0a130d47 656f5472 *.U....US1.0...U....GeoTr*
 75737420 496e632e 311b3019 06035504 03131247 656f5472 *ust Inc.1.0...U....GeoTr*
 75737420 476c6f62 616c2043 41301e17 0d313330 34303531 *ust Global CA0...1304051*
 35313535 355a170d 31353034 30343135 31353535 5a304931 *51555Z..150404151555Z0I1*
 0b300906 03550406 13025553 31133011 06035504 0a130a47 *.0...U....US1.0...U....G*
 6f6f676c 6520496e 63312530 23060355 0403              *oogle Inc1%0#..U..      *
0
Blue Street TechLast KnightCommented:
That drop code refers to a Firewall Access Rule not CFS policy. Are you filtering outbound?

Verify what rule forced it to drop. It sounds like authentication issue. Are you forcing users to authenticate or have you specified another user group other than All in the Access Rule halting this type of traffic?
0
Blue Street TechLast KnightCommented:
Any update on this?
0
jcola1939Author Commented:
The traffic is going out however when the drops begin in starts with a packet back from the site.  That packet is dropped.  The firewall should allow the two way communication however it is dropping it.  I of course have a rule dropping outbound traffic coming in.  

I have noticed that for users that begin to experience these issues it can be resolved by putting them into a CFS access group that has the ability to see non rated  websites.  That is of course not Ideal.  Especially when I have the sites that are acting up listed as trusted sites.
0
Blue Street TechLast KnightCommented:
How many CFS polices do you have?

How are you authenticating the users, e.g. (do they logon to the SonicWALL appliance in order to access the Internet, are you using SSO, or is there no authentication)?

If user authentication is being used, are you blocking HTTP/s access for unauthenticated users?

How are you applying the CFS policies, e.g. per IP Address Range, per user/group)?

You post of the packet capture indicates the block is due to a Access Rule. Can you screenshot your WAN>LAN and LAN>WAN Access Rules and post them?

In the CFS section how are you handling If Server is unavailable for (seconds)? What action & how many seconds?

Under each policy in the Settings tab > Custom List Settings section is Source of Allowed Domains: Global or is it None or Per Policy? Every option under Custom List Settings should be either Global or Per Policy.

If dynamic content is present in these sites you might have to View Source them and search for external domains that are injecting themselves into the site in order to provide content.

Thanks.
0
jcola1939Author Commented:
I have two CFS polices defined using app rules.  One is the default and the other is the same but allows access to non rated sites.  The rules are applied using app rules and are IP based.  Both policies share the same trusted and untrusted settings.  Could the packet capture reflect a firewall rule block because the CFS is applied by app rules?

The current CFS settings are set to enable CFS server failover and to block traffic after 5 seconds of being unavailable.
0
Blue Street TechLast KnightCommented:
Ah, I see...App Rules is how you are applying this. OK. I believe this is where the issue lies - specifically in how the rules were written and are being applied.

Foundationally & typically, in order to achieve more of an binary approach block/allow you can simply setup App Control, CFS and apply both via User Group, IP Range, Zone, etc. You would simply enable App Rules without any actual rules defined.

If you have the need to go beyond a binary approach of block/allow say more granular whereby you want to block Facebook or allow different levels of Facebook access at different times of the day then you would use App Rules to provide that granularity. With App Rules you can use it to allow a variety of access types, including read-only, full read / write access and many other variations.

If this is not the goal to provide this type of granularity then I'd configure App Control as desired, CFS applied to IP Ranges or Zones and simply enable App Rules, and remove the rules.

If you must have this granularity then please post a screenshot of your App Rules.

Thanks!
0
jcola1939Author Commented:
0
jcola1939Author Commented:
We switched from the regular CFS to app rules some time back to take advantage of the performance increase.
0
Blue Street TechLast KnightCommented:
You have DPI-SSL capabilities on your SonicWALL!

Deep Packet Inspection of Secure Socket Layer (DPI-SSL) extends SonicWALL’s Deep Packet Inspection technology to allow for the inspection of encrypted HTTPS traffic and other SSL-based traffic. The SSL traffic is decrypted transparently, scanned for threats and then re-encrypted and sent along to its destination if no threats or vulnerabilities are found. DPI-SSL provides additional security, application control, and data leakage prevention for analyzing encrypted HTTPS and other SSL-based traffic.

The following security services and features are capable of utilizing DPI-SSL:
Gateway Anti-Virus
Gateway Anti-Spyware
Intrusion Prevention
Content Filtering
Application Firewall
Packet Capture
Packet Mirror

Normally, without DPI-SSL, HTTPS traffic cannot be blocked by SonicWALL Security Services. However, with SonicWALL DPI-SSL feature, the SSL traffic is decrypted by the SonicWALL for inspection, thus enabling SonicWALL to inspect traffic and enforce any Security Services prevention on it. This describes how to block https://www.google.com using SonicWALL Content Filtering when DPI-SSL is enabled.

Enabling DPI-SSL Client Inspection for Content Filter

In this section we will enable DPI-SSL Client Inspection. The Client DPI-SSL deployment scenario typically is used to inspect HTTPS traffic when clients on the LAN browse content located on the WAN.

In this example I'm using the Default SonicWALL DPI-SSL Certificate Authority (CA) Certificate as the re-signing authority. Your users should be instructed to add the certificate to their browser’s trusted list to avoid certificate trust errors.
1. Login to the SonicWALL Management GUI.
2. Navigate to DPI-SSL and click on Client SSL.
3.On the Client SSL page, check the box under Enable SSL Client Inspection.
4. Check the box under Content Filter.

Now that DPI-SSL Client Inspection is enabled, SonicWALL will be able to apply Content Filter policies on the clear-text portion of the SSL encrypted payload passing through it.

Adding Trust to the Browser

To avoid certificate trust errors and to enable the re-signing certificate authority to successfully re-sign certificates, browsers would have to trust this certificate authority. Such trust can be established by having re-signing certificate imported into the browser's trusted CA list.

In the DPI-SSL > Client SSL page, click on the (download) link to download the Default SonicWALL DPI-SSL Certificate Authority (CA) Certificate.

To import the certificate into a browser, do the following:
Internet Explorer:
1. Go to Tools > Internet Options, click the Content tab and click Certificates.
2. Click the Trusted Root Certification Authorities tab and click Import. The Certificate Import
3. Wizard will guide you through importing the certificate.
Firefox:
1. Go to Tools > Options, click the Advanced tab and then the Encryption tab. Click View
2. Certificates, select the Authorities tab, and click Import. Select the certificate file, make sure the
3. Trust this CA to identify websites check box is selected, and click OK.
Mac:
1. Double-click the certificate file, select Keychain menu, click X509 Anchors, and then click OK.
2. Enter the system username and password and click OK.

Let me know how it goes!
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Blue Street TechLast KnightCommented:
How did this turn out? Where do you stand now? Did you try my guide in comment http:#a39613713 ?
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Hardware Firewalls

From novice to tech pro — start learning today.