HTTP(S) Content Action & Revese-Proxy : Questions
Hi,
I haven't worked in a long time on WatchGuard fws and i've got a few questions.
I need to do HTTP and HTTPS Revese-Proxy for a client (basically just rerouting trafic according to the URL) and I couldn't make it work.
Right now, I have a Action Content filter with the domains I need to reroute.
This filter is configured in a HTTP(S) Proxy Policy with the Firebox itself as the destination (External IP Address).
The rule is matched, but there isn't any matching on the URL and I always end up getting a Access Denied from the firewall.
I've got 3 main questions, for the rest I'll leave you make me any advice you might think that could help me :
Does the Destination field HAS TO be a SNAT address? I read that in some documentation, but i'am not sure.
Does the trafic HAS TO come from the External interface, or can I also do Revese-Proxy between 2 Internal Trusted interfaces?
Regarding HTTPS, can you confirm that the box is able to route the trafic based on the SNI? By asking that I mean rerouting HTTPS without doing any SSL Inspection
Any help would be appreciated.
Thank you guys! ;-)
Comments
Just to be clear - you are using the Access Portal, correct?
If so, the Access Portal is for remote (external) users
About the Access Portal
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/services/access portal/access_portal_about.html
Sir,
I'am not using the Access Portal (I do not have the subscription). I just need to redirect the trafic according to the URL.
Then that is not a reverse proxy.
From External - you need to use a SNAT or 1-to-1 NAT, assuming that your internal server has a private IP addr.
From internal, you need to do NAT loopback for this to work.
"To use an HTTP content action in an HTTPS proxy action, you must enable content inspection and configure a domain name rule with the Inspect action."
Use an HTTP Content Action in an HTTPS Proxy Policy
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/proxies/general/content_action_config_c.html
Well yeah it's more like classic Proxy, sorry.
Anyway, I did read this documentation but they say, here : "To use an HTTP content action in an HTTPS proxy action, you must enable content inspection and configure a domain name rule with the Inspect action."
However, in other papers, I read that Content Action on HTTPS has been supported on SNI (so WITHOUT inspection) since version 12, for example : https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/proxies/examples/routing_action_https_no-ci.html
or
http://customers.watchguard.com/articles/Article/SNI-support-HTTPS-Proxy-content-inspection
That's why I'am lost actually.
Any tought on this?
Anyway, I will try again with a NAT rule from the External interface to try to make it work.
Since the latest docs on Content Action say you need to do Inspect, then I believe that.
If SNI was an acceptable alternative, then I would expect it to be in the docs.
Than you for your reply!
I will try it and keep you updated. If it doesn't work, I will consider installating the servers certificate and Inspect the trafic.
I still have a few question.
Do I have to use HTTP(S) Proxy 'Server' or 'Client' in my case?
Also, correct me if i'am wrong, but for classic HTTP the routing decision based on URL has to be put in a Action Content, and Action Proxy can be linked to it. So in the policy, do I have to specify the Action Proxy or the Action Content?
For HTTPS, routing decision based on URL can either be put in Action Proxy or Action Content, what is the better solution in my case?
Sorry if I'am not clear, this is kind of a mess ;-)
If you are using the Web UI, IMHO setting up proxies are more difficult and less obvious than doing it in WSM Policy Manager.
You use a Client proxy action for policies which protect your clients which are going to a server.
You use a Server proxy action for policies which protect your server(s) which are being accessed.
For what you want to do, you do need to have a Content Action associated with a HTTP and/or HTTPS proxy policy.
Alright,
Thank you for your answer and for your time.
I will test that ASAP and keep you informed.
Did you make this working?
I'm trying to follow some of the same guides to set up SSL-offloading from external to NAT'ed webservers in a DMZ.
I don't see any traffic being matched to the content rules .domain.tld/
Please provide details of what you have done here to get help from us, or open a support incident to get help from a WG support rep to get this working.
I have a web-server. Lets say it's located at 1.2.3.4 on dmz zone 1.2.3.0
There are some site on it. fx. shop.domain.tld
I have mada HTTP Content Action
Pattern match shop.domain.tld/*
Proxy action: HTTP-Server.Standard
Routing: Policy Default
Ports:80/443
SSL Offload and Log on.
I then have a HTTPS-Proxy (TCP/443):
Any-External to SNAP ext-IL --> 1.2.3.4:80
Proxy Action:
Domain names:
ACtion: Inspect
PAttern: shop.domain.tld/
Proxy Action: Name of cointent rule above
Certificate: Default
I do get one line in the log :-)
https/tcp 1048 443 0-WAN 2-DMZ1 ProxyAllow: HTTPS domain name match (HTTPS-proxy.LiferayDMZ-00) proc_id="https-proxy" rc="590" msg_id="2CFF-0003" proxy_act="HTTPS-Server.RevProxy" geo_src="DNK" geo_dst="DNK" rule_name="Default" sni="shop.domain.tld" ipaddress="ext ip"
But the browser returns a ERR_SSL_PROTOCOL_ERROR
Are you doing Inspect on shop.domain.tld ?
If not I think that you need to, in order to process the HTTP proxy action, which will do the SSL offload.
Also, I'm not sure about your SNAT I would think that the dest port should not be specified.
Yes, I'm doing inspect in the Proxy Action.
I need it to forward to port 80 as the server does not do SSL.
If you are doing Inspect, then I would expect to see
ProxyInspect: HTTPS domain name match
not
ProxyAllow: HTTPS domain name match
Also, I would expect to see a log message for the SSL offload.
From the docs:
When you enable the TLS/SSL Offload option in a content rule:
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/proxies/general/content_actions_tls-ssl-offload.html?Highlight=SSL offload
Try changing the SNAT 1st.
Yes you are right!! Thanks. That got me a bit further.
When I change the default action on the policy to inspect it works, so it seems that my domain name rules does not work as I expect.
Maybe I should no use both Domain Names rules on the pllicy and Content Actions....
"Maybe I should no use both Domain Names rules on the pllicy and Content Actions...."
If you are using a domain name on the To: field of your incoming HTTPS proxy to using the public P addr of the web site instead.