Different behaviour on 2 interfaces (related to https on port 80 possibly)
Hi,
We have an M390 (12.11.2.B713726).
Our local LAN operates through Trusted2 interface.
We have a guest Wifi network operating on GuestWeb Interface.
One of our suppliers has a bunch of routers and we need to access their web portals.
These particular models appear to only listen for https on port 80 for some reason from what I can gather.
When I try to access one of these routers from Trusted2 LAN, it wont connect.
When I try to connect from the GuestWeb network then it will connect.
Trusted2 http proxy was using HTTP-Client.Standard.1
Guestweb proxy was using HTTP-Client.Standard.3
Comparing the 2 the only difference is that HTTP-Client.Standard.1 uses a Webblocker so I thought ok maybe the webblocker means it is inspecting the packets more and triggering the failure.
So I changed the config of the GuestWeb network http proxy to use the same HTTP-Client.Standard.1 as Trusted2 interface but it still works on the GuestWeb network.
On the Trusted2 network I then added a packet filter policy to blanket allow access from my PC to the remote IP address on port 80 and placed the policy above the default http-proxy policy and then the connection works for me.
This leads me to believe that it is the proxy that is causing the issue but it is confusing because the same policy causes no issues on the GuestWeb network.
I can see no other policies above the default http-proxy that should have an impact (there are less that a handful in total anyway)
Any suggestions appreciated...
Cheers,
~Shaun.
Comments
You are probably using and old HTTP-Proxy action that has many outdated configurations that aren’t really working anymore with modern websites.
Nowadays, many modern websites use custom HTTP “X-” headers and if these custom headers are stripped these websites aren’t working correct anymore.
I would also increase the “Set the maximum URL path length to” 16384 from the default 4096 value, both in HTTP Request and HTTP Response General Settings.
Security is achieved with the UTM security services, not by denying some HTTP headers.
The idea is more to use the Firebox devices UTM security services to protect your networks and users from attacks and harmful data.
Proxy actions are powerful tools and better suited to example control some web traffic by denying *.exe file downloads
or denying example on-line media content with denying HTTP headers, etc...
For normal daily web browsing, I would use the default “open” HTTP-Client.Standard action + UTM Security services!
Check following video where I show my new best practice HTTP Proxy action that is based on the WG Cloud Managed Firebox proxy action + couple setting
that I have enabled.
https://app.screencast.com/zooMlmsGhhJpS
Hi kimmo.pohjoisaho
Thanks for the answer and for taking the time to make the video.
The confusing point for me is that the Guestweb AND Trusted2 policies both use the same proxy action ( HTTP-Client.Standard.1) but it works for traffic sourced in GuestWeb and not Trusted2 so that would indicate that the proxy does work at least for one of them??
Just to make sure there wasn't something subtle that was different in the overall policy that was causing an issue, I temporarily added Trusted2 to the GuestWeb policy (which is above the Trusted2 one in the policy list) and I still can't access the router from my PC on trusted2 interface.
~S.
You can add a HTTP packet filter with To: set to your supplier's IP addr(s).
Make sure that this policy ends up above your current HTTP policies
Hi Bruce,
Yeah that would be fine if it was a small finite list but it's not.
There could be thousands of them and their IP addresses could/would change regularly as could the amount of them.
Just can't understand the different behaviour between the two interfaces... #pullingouthair
Cheers,
~Shaun.
Are you using different source (public) IP address for trusted2 and guestweb networks?
Check your d.nat config in network nat and the d.nat config in the policy advanced settings.
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/nat/nat_dynamic_use_c.html
How are you accessing the GuestWeb interface? Via wifi from your Trusted2 PC?
Since access from both interfaces use the same HTTP proxy, then look at whatever the differences are for those accesses as a possible cause.
Perhaps a MTU difference?
Thanks again for the replies guys.
@kimmo.pohjoisaho , both instances are NAT'd to the same IP
@Bruce_Briggs I have a laptop on my desk that is on the GuestWeb network and my PC which is on the Trusted2 interface.
Yeah I have been trying to compare everything between the policies and interfaces to see if there was anything different but no joy so far, same MTU.
Can you connect the laptop to Trusted2 for a test?