SDWAN and Cloudflare/Microsoft security
Hi
I´m asking because of lack of knowledge. We are routing almost all http/https traffic from our remote sites through our central FireboxV using SDWAN in the http and https policies.
99,999% of the times it works, but a few times, we have some sites (often with our big suppliers like Livis, HugoBoss, AutoDesk) where sites do not work correctly or we get a access denied to certain part of their websites. Common for those sites are enterprise security products in front of their systems like Cloud Flare WAF, Azure load balancer integrated with security and so on.
Today i had Autodesk licensing not working from our clients and going to manage.autodesk.com just show a nearly empty page. I had created a http/https non-proxy policies allowed traffic to Autodesk provided list of domain names which did not support tls inspection on out central FireboxV. Everything looked good from Fireware.
Using Fiddler i could se at some point, i got a reponse saying WAF: Access denied which most likely are the root cause when the traffic are routed using SDWAN.
The second i created a http/https policy on the local remote firewall containing the same non-proxy settings/rules routing traffic out from the remote office to the WAN instead of using SDWAN, it all starts working.
Common of each case are when i use SDWAN routing, the remote website denieds some of the traffic. Using Reddit without a logged in Reddit account sees the traffic a vpn traffic when using SDWAN.
I suspect some traffic do get routing out from the remote firewall WAN interface directly (as we have local policies routing MS365/Azure and other traffic not needing security inspection and faster routing) and the rest goes through the sdwan policy.
Could it be the website sees the traffic originating from different public ip adresses comming from the same user and denieds the traffic?
Other ideas?
Regards
Robert
Comments
More often than not when the clients and users I deal with have website issues like this, first thing I check (after the logs in case of things like WebBlocker) is whether a "proxy bypass" policy as you've done works.
It's not the SDWAN bit I suspect (though depending on your setup wouldn't rule it out), but I find more often it's the HTTP/HTTPS 'transparent' proxy rule/s that break things (I don't even use HTTPS content inspection).
So in my case the approved exceptions get a regular HTTP/HTTPS packet filter [non-proxied] policy, and the rest of the traffic gets funnelled through the regular proxy policies.
Hi @Robert_Vilhelmsen
Your description sounds accurate -- the site is likely denying access to other parts unless you have an active connection open to that site
If the website is denying access via the IP you're coming across with via SD-WAN, I'd suggest making a policy for that traffic that only goes out via one IP for those sites. SD-WAN and the poxies can't do anything about a website that is actively denying it access.
-James Carson
WatchGuard Customer Support
My though is, it´s caused by asymmetric routing from my side to the end destination. I will do some tests where i route all traffic through the sd-wan.
Some traffic must go through my WG proxies in the case with Autodesk as CF denieds some data send to the destination. It have tried using other public ip nat base and using only pakket filters to all autodisk domains except some Google domains.
Hitting the url going through my WG fireboxV throws:
https://api.account-platform.autodesk.com/gatekeeper/v1/initialize HTTP/2
"detail": "Forbidden",
"title": "WAF_FILTERED"
Using the same url with a mobile 5G connection throws:
"detail": "Missing Authentication Token",
"title": "MISSING_AUTHENTICATION_TOKEN"
Hi @Robert_Vilhelmsen
They're likely binding your authentication to a specific IP. Moving to just one IP accessing that site would likely help.
-James Carson
WatchGuard Customer Support
After some more debugging i think it comes down to different NAT base ip address the client present itself with as we have quite a few different policies weither the traffic are from a certain remote location, and if it´s a proxy or filter policy.
I identified some filter policies which could lead to a client being identified with different public ip address vs. what the proxy policies for the same client would NAT with as outgoing traffic depending on the destination which could be both a ip or a fqdn.
This would make sense as a WAF security product would see traffic originating from more than 1 ip address within the same session.
I also suspect Autodesk CloudFlare WAF has blocked some of the ip addresses, we have assigned our FireboxV duo to the above issue.
Hi all
The issues was related to different traffic was routed out with different public ip addresses.