Firebox Policy Puzzler - Why Don't I have Access to the Web?

Andrew_1110Andrew_1110
in Firebox - Networking, Multi-Wan, VLAN, NAT, SD-WAN

Hello everyone,

I'm very puzzled. (New Firebox T85 user, Cloud managed, test environment, DNS handled on an internal server, TLS Decryption disabled.)

I don't have any web access when I have a single core policy standing between my Internal Client and the Internet, with "Web, FTP, All TCP and UDP, PING" Traffic Types allowed. The browser simply says, "ERR_CONNECTION_CLOSED". [Case A]

If I edit this policy, removing all the Traffic Types above, and adding back "All" Traffic Types - and no other changes, my browser kicks into life. [Case B]

I have captured packets on the Internet side of the Firebox, to see if I can determine what is being filtered out in [Case A] - but I'm no Wireshark expert. What I cannot see is any [SYN] packets being sent from the Firebox... Why would my simple vanilla web access policy allowing "Web, FTP, All TCP and UDP, PING" Traffic Types, filter them out?

Many thanks for your thoughts.

Andrew

Best Answer

  • Andrew_1110Andrew_1110
    Answer ✓

    [SOLUTION]

    I opened a support case and eventually got through to a support engineer who suggested rebooting the Firebox. Guess what - it worked!

    For some reason, the "Proxy Policy" that handled the "Web Traffic" type (beneath the hood, hidden from the Cloud interface) wasn't activated and rebooting made it active. He had to enable the local Fireware web UI on the Firebox to see this.

    Now, looking at the Traffic Monitor, we can see allowed packets with "ProxyAllow: HTTPS Request categories", which were not there before. (The TCP SYN check failures were a symptom of the problem, rather than the cause.)

    We're not sure how this hidden proxy policy was deactivated - or indeed if it was ever active at the point that the policy was created. It may be a bug that never reoccurs.

    Anyway, the old "turn it off and on again" solution strikes again - I can't believe that I didn't try it, and that the 10 WatchGuard support techs I dealt with never suggested it!!!

    :blush::wink:

Answers

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @Andrew_1110
    What does the traffic monitor say when those rules are in place and you're unable to get to the website. If we have any Deny lines, that may help determine what is stopping your traffic.

    Pick the one that matches how you manage your firewall -- the same logs are displayed in all 3 places.

    (Traffic Monitor - WatchGuard Cloud)
    https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/WG-Cloud/Devices/managed/monitor_traffic.html

    (Traffic Monitor - WatchGuard System Manager)
    https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/fsm/log_msgs_traffic_mon_wsm.html

    (Traffic Monitor - WebUI)
    https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/system_status/traffic_monitor_web.html

    -James Carson
    WatchGuard Customer Support

  • Andrew_1110Andrew_1110

    Many thanks for taking the time to get back to me James.

    I can see that there are deny lines, and you are right, I think it will help us to figure out what's going on. Here is an example:

    2024-06-17 09:29:47 Deny x.x.x.x 20.90.152.133 https/tcp 57641 443 VLAN-500 Firebox tcp syn checking failed (expecting SYN packet for new TCP connection, but received ACK, FIN, or RST instead). 224128 (Internal Policy) proc_id="firewall" rc="101" msg_id="3000-0148" tcp_info="offset 5 AF 621368558 win 5152"

    Troubleshooting KB Article ID :000019092 on TCP SYN checking points me towards a potential issue with asymmetrical routing - something that could (and shouldn't) be happening in my config and I will investigate it further.

    I'm still confused as to why in my testing in [Case B], we don't get denied "TCP SYN checking" packets. Does the "All" Traffic Types policy setting bypass this test?

    Thank you again,

    Andrew

  • Andrew_1110Andrew_1110

    Hi,

    Just following up with the results of my investigation into whether asymmetrical routing is in play here. In short, it isn't.

    What I did wonder is that in my test environment, I have my Firebox external interface connected to an ISP router which will be performing NAT. (I'm using this ISP router for a VoIP system, and it has plenty of capacity - but I cannot set it up in bridge mode.) In this situation I now have double-NAT, with both the Firebox and ISP router between my test client and the web.

    (FYI - my plan was to use this ISP router as a secondary - with a primary ISP router (bridged, so no NAT) dedicated to a public IP for mobile VPN and server access - and use Round-Robin load balancing for web traffic. The primary router is not yet in play as it is dedicated to my production environment.)

    I don't know whether this double-NAT is the cause of my TCP SYN checking problem as I keep going back to the puzzle in my original post - how the heck does the policy difference between cases [A] and [B] determine whether I have web access? If double-NAT was a show-stopping config blunder, then it wouldn't work in either case.

    Again, I'd be grateful for people's thoughts...

    Cheers,

    Andrew

  • Bruce_BriggsBruce_Briggs
    Any denies other than for SYN checking?
  • Andrew_1110Andrew_1110

    Hey Bruce - no, the only deny lines are for TCP SYN check failures...

  • Bruce_BriggsBruce_Briggs

    Time for a support case.
    You can open one by clicking on the Support Center box on the top right.

    When you find a resolution, please post it.

  • Bruce_BriggsBruce_Briggs

    If you have a TCP-UDP proxy policy in your config, then it can include looking at web traffic - via HTTP & HTTPS proxy actions specified in the policy.

Sign In to comment.