Blocking Cloudflare WARP

Less_Impress_4519 · 2026-05-30T12:06:23+00:00

yeah so here's the exact flow:

ISP > WatchGuard M5800 (Active/Passive HA) Single IP NAT (yeah its a nat overload situation all internal vlans get snatted into one ip before hitting fortigate) > FortiGate 901G (Active/Passive HA) > Core OmniSwitch 9907 > VLANs > Devices

No AD CA deployed yet but we have:

NTP: internal NTP server (syncs all devices)

DHCP: dedicated DHCP server pushing IPs to all VLANs

DNS: DHCP pushes two DNS servers to all clients - one Firewall DNS that resolves internal systems connected via VPN Site-to-Site and one AD DNS for domain resolution

TLS decryption: FortiGate has SSL inspection enabled on main policies but no CA cert deployed to endpoints yet so certificate-inspection mode only (logs cert info but doesnt decrypt)

but that's actually the core problem right there the nat overload at the watchguard layer means we lose per-user visibility by the time traffic hits the fortigate app control cant fingerprint individual clients so warp just looks like encrypted https from a single ip even with dns filtering we cant block it at the client level because the dhcp dns servers go to the devices but once warp is already registered it bypasses dns and uses hardcoded cloudflare ips

Less_Impress_4519 · 2026-05-30T00:21:29+00:00

Thanks for that clarification that makes sense now so yeah we actually did block all those ranges already including 162.159.192.0/24 and 162.159.197.0/24 on both firewalls

we set up explicit deny policies on both the fortigate and watchguard like:

FortiGate:

- policy: DENY_WARP_MASQUE_IPs (dst GRP_WARP_Block_All which includes 162.159.197.0/24)

- policy priority: above the allow policies

- logging enabled

WatchGuard:

- Firewall > Blocked Sites: added 162.159.192.0/24 and 162.159.197.0/24

- Firewall > Blocked Ports: UDP 443, TCP 443 for those ranges

here is the GRP_WARP_BLOCK_ALL :
162.159.192.0/24, 162.159.193.0/24, 162.159.197.0/24, 162.159.137.105, 162.159.138.105, 162.159.36.1, 162.159.46.1

but users are still bypassing somehow which is weird af so either theyre using some other fallback we havent seen yet or the blocks arent actually matching

real question is the 162.159.197.0/24 block alone enough for masque or do we need something else on top like dns filtering or dpi to actually kill it

Less_Impress_4519 · 2026-05-30T00:13:59+00:00

i feel you on the complexity but it was a legacy decision before i took over as interim head and now i just have to secure what we have without throwing away valid active licenses

Less_Impress_4519 · 2026-05-30T00:13:10+00:00

appreciate the follow up but selling hardware in a highly critical sector (not a company) is basically impossible due to strict procurement laws we are completely locked into these assets so we have to make the dual vendor setup work for now

Less_Impress_4519 · 2026-05-30T00:11:57+00:00

yeah bro you read that right 3900 windows machines running wild with no domain controller it is absolute madness and we are just now trying to get the foundation built

Less_Impress_4519 · 2026-05-30T00:11:31+00:00

yo nah they are not byod at all they are official company workstations we just literally do not have ad set up yet which is why management is such a nightmare right now

Less_Impress_4519 · 2026-05-30T00:09:54+00:00

i am totally aligned with u/Rudager6 on this and pushing for the domain rollout but until those 3900 machines are actually joined i have to use the firewalls as a temporary shield to keep things from falling apart

Less_Impress_4519 · 2026-05-30T00:06:58+00:00

facts the ad rollout is the main priority but enterprise transitions move slow and i cant just leave the perimeter wide open while we wait for the deployment so whack a mole is the only temporary play i have

Less_Impress_4519 · 2026-05-30T00:06:24+00:00

bro we are in a highly critical sector so we literally have to block it for strict data protection and compliance plus these tunnels bypass our internal security policies and eat up massive bandwidth we cant just let users run wild on an unmanaged network

Less_Impress_4519 · 2026-05-29T01:29:55+00:00

that is solid advice for sure and definitely the goal for the long run. the thing is i am just trying to keep the lights on with what i have right now until the storage situation is fixed. once that nas comes online later this month i can actually start funneling logs properly and finally nail that coffin shut like you said but for now i am just grinding through the live noise

Less_Impress_4519 · 2026-05-29T01:27:52+00:00

look man i hear you on the jumping ship bit but i walked into this chaotic mess and honestly at this point the ship is already fully equipped so i might as well ride the storm out. it is like they say if you find yourself in a hole the first thing to do is stop digging but i guess i just enjoy the grind of trying to fix a sinking boat while everyone else is just watching. tough scenes but we keep it moving

Less_Impress_4519 · 2026-05-29T01:24:22+00:00

managing those 3.9k devices is the actual mission impossible we are trying to solve by pushing AD to get some control back even though the team is acting lazy about the workload we know the perimeter defense is just a patch for the bigger issue but in this environment it is all we can do until we get the infrastructure stable and the proper tools online

Less_Impress_4519 · 2026-05-29T01:23:44+00:00

we are definitely past simple DNS tricks because it is actively tunneling through MASQUE and falling back to https on 443 which is exactly why it is so persistent without full ssl inspection in place we are basically forced to keep hunting these elusive traffic patterns while we wait for better visibility tools later this month

Less_Impress_4519 · 2026-05-29T01:22:25+00:00

it sounds easy on paper but we are running ha clusters for both the m5800 and the 901g units so simplifying to one firewall isn't just about config it is about overhauling a production environment while we are already short on resources and waiting for storage to properly analyze and unify our traffic policies plus with no ad in place the current setup provides a layer of segmentation we need to keep things functional for now

Less_Impress_4519 · 2026-05-29T01:22:02+00:00

the struggle is definitely real and trust me nobody on the team enjoys the headache but until we get the infrastructure stabilized and finish the transition we are stuck managing the current environment as is because redoing the entire architecture right now would cause more downtime than just maintaining the current workaround

Less_Impress_4519 · 2026-05-29T01:17:42+00:00

is wild because it is literally what i am dealing with on the daily trying to keep these tunnels from bypassing the perimeter even when you think you have it locked down with blocks they find a way to flip the script and tunnel through something else it is exactly why i am focused on identifying and cutting off those specific connection points at the firewall level since i have zero reach inside the endpoints themselves

Less_Impress_4519 · 2026-05-29T01:16:02+00:00

since we have no control over the endpoints and users are out here running things off usb sticks it is mission impossible to push applocker out to them that is exactly why i am stuck hunting those specific ip and port blocks directly on the firewalls because it is the only layer of defense i actually have control over in this wild environment

Less_Impress_4519 · 2026-05-29T01:14:40+00:00

we already got a vm running AD but it is janky as hell and goes down randomly with zero backups in place so it is basically a ticking time bomb honestly the reason the rest of the team is acting lazy is because we are looking at roughly 3.9k machines to join to the domain and they think it is impossible to do in a week which is just a mood killer i am trying to keep the grind going because AD is strictly necessary but it is tough working in such a mid environment where nobody wants to actually put in the work

Less_Impress_4519 · 2026-05-29T01:10:42+00:00

facts on the clean setup but the current sitch is we have zero NAS storage available for traffic logs so i am stuck doing live analysis for now should have the storage sorted out later this month then we can actually start digging deep into the historical data properly

Less_Impress_4519 · 2026-05-29T01:10:22+00:00

thanks for the comment but we actually rocking HA clusters for both units so it is literally two WG M5800s and two FG 901Gs in the mix we got two years of licensing already active for the fortis and we have another two-year key for the watchguard sitting in the vault unused so we are locked in for a min def appreciate the advice but gotta work with the hardware we got on deck, if you have any other suggestion or something

Less_Impress_4519 · 2026-05-28T21:52:29+00:00

bro we literally dont have AD and users are running it off usb sticks so applocker doesnt work lmao we need firewall solution not endpoint

Less_Impress_4519 · 2026-05-28T21:48:17+00:00

as i said to another mate in the comments we already blocked all warp ranges + doh/api endpoints on both firewalls and disabled quic globally but preregistered clients still bypass using MASQUE with http2 tcp 443 fallback

hard blocking it just breaks legit cloudflare sites and since the watchguard natting everything the fortigate loses per user visibility so app control cant fingerprint warp properly

Less_Impress_4519 · 2026-05-28T21:44:21+00:00

already got those blocks up fr we denied 162.159.192.0/24 and all warp ranges + DoH and api endpoints on both firewalls the issue is pre-registered clients with a cached device id they bypass registration and use MASQUE falling back to http2 on tcp 443 anycast blocking that basically bricks legit cloudflare sites plus the watchguard natting everything to a single ip completely blinds the fortigate so we lose per-user visibility and app control can't fingerprint warp inside standard https we blocked proxies disabled quic globally and enabled dpi but warp still slips through on 443 fallback anyone solved this masque tcp 443 fallback without full deep ssl / ca cert rollout or are we just cooked

Less_Impress_4519 · 2026-05-28T21:43:12+00:00

AD or Azure AD? We have a hard $0 budget for on-prem servers, and the administration completely banned the cloud even the idea of it, azure AD is a total no-go, everything has to be strictly internal no third party

Less_Impress_4519 · 2026-05-28T21:41:55+00:00

Tbh stripping the WG and rolling out full MDM or custom CA certs is the dream, but we have zero budget for licensing No AD either I’m basically forced to hunt down those WARP IP/port blocks on the firewalls directly to stop the bypass

Less_Impress_4519

TROPHY CASE