WebGUI to different URI (including embedded links) for ease of reverse proxy
-
WebGUI serves from http(s)://address/ - which can be frustrating when trying to configure it to work with reverse proxy - any reverse proxy, not just those packaged with pfsense. It's not a pfsense webGUI thing, it's just a limitation of reverse proxies when dealing with sites that use / as a document root.
For example, if I have servers/sites at http://server1/app1 and http://server2/app2, they are a cinch to reverse proxy. The RP simply forwards any requests for /app1 to server1/app1, etc. Embedded links in the pages of server1/app1/ already reference a context path of /app1, so the internal links to the page, example server1/app1/menu1/menu.html get through the proxy just fine.
Sites that use a document root of the fully qualified domain name, like http://server1/index.php, are more of a pain.
I can set a reverse proxy rule such that a request for say, http://reverseproxysite/pfsense is forwarded to http://pfsenseIP/ - and I'll get the pfsense login box. But the page won't have graphics/themes, or let you actually log in, because those resources are at /themes /css, etc. I could add rules for those URI's to the reverse proxy as well, but that doesn't account for the links hardcoded into the pfsense webGUI. If I want to click the link for the interfaces page, it's going to generate a request for http://reverseproxysite/interfaces.php, which doesn't exist.
This is a long prelude to a simple question -
Can I change the function of webGUI so that the entire site is served from say, http://pfsenseIP/pfsense/, including the embedded page links in the individual .php pages?
-
I have the same issue, when trying to revproxy with apache's mod_proxy module. But I even don't get the login screen, since the browser is immediately redirected to https://pfsense.my.domain which is (of course) not accessile.
This is how my attempt currentliy looks like:
LoadModule deflate_module /usr/lib64/apache2/mod_deflate.so LoadModule headers_module /usr/lib64/apache2/mod_headers.so LoadModule proxy_module /usr/lib64/apache2/mod_proxy.so LoadModule proxy_http_module /usr/lib64/apache2/mod_proxy_http.so LoadModule proxy_ajp_module /usr/lib64/apache2/mod_proxy_ajp.so LoadFile /usr/lib64/libxml2.so LoadModule xml2enc_module /usr/lib64/apache2/mod_xml2enc.so LoadModule proxy_html_module /usr/lib64/apache2/mod_proxy_html.so ProxyRequests Off ProxyHTMLLinks a href ProxyHTMLLinks area href ProxyHTMLLinks link href ProxyHTMLLinks img src longdesc usemap ProxyHTMLLinks object classid codebase data usemap ProxyHTMLLinks q cite ProxyHTMLLinks blockquote cite ProxyHTMLLinks ins cite ProxyHTMLLinks del cite ProxyHTMLLinks form action ProxyHTMLLinks input src usemap ProxyHTMLLinks head profile ProxyHTMLLinks base href ProxyHTMLLinks script src for ProxyHTMLLinks frame src longdesc ProxyHTMLLinks iframe src longdesc ProxyHTMLLinks body background ProxyHTMLLinks applet codebase ProxyHTMLEvents onclick ondblclick onmousedown onmouseup onmouseover \ onmousemove onmouseout onkeypress onkeydown onkeyup \ onfocus onblur onload onunload onsubmit onreset onselect \ onchange ProxyPass /pfsense/ http://pfsense.my.domain/ ProxyPassReverse /pfsense/ http://pfsense.my.domain/ ProxyHTMLURLMap http://pfsense.my.domain /pfsense <location ="" pfsense="">ProxyHTMLEnable On ProxyHTMLExtended On LogLevel Debug ProxyHTMLURLMap / /pfsense/ RequestHeader unset Accept-Encoding AuthName "Application /pfsense" AuthType Basic AuthUserFile /m/b/httpd/passwd AuthGroupFile /m/b/httpd/group Require group pfsense SSLRequireSSL RequestHeader set X_FORWARDED_PROTO 'https'</location >How does your revproxy configuration look like?
-
I'm using squid3, not apache, so it wouldn't be relevant. I'm far more comfortable with apache reverse proxies, but had major issues when trying to get things working using the apache packages under pfsense, whereas squid, for the most part, works. I do sometimes have to kill the squid processes and restart them after making a change via the gui though.
Anyway, what I ended up doing to get what I wanted was to create rules based on the requested subdomain - so rather than requesting
https://mydomain.com/pfsense
I'm requesting
https://pfsense.mydomain.com/
And that works because everything is now off the root path - /images, /themes, etc. The only downside is that because I don't have a wildcard ssl cert for mydomain.com (you have to pay extra for those), I've got to click through cert mismatch warnings to get to my site. But that's tolerable - it's only me accessing the few sites I have that require use of subdomains to reverse proxy properly. Whomever provides your domain usually has free/unlimited subdomains you can add.
TL&DR;
Redirect based on the subdomain requested and it will work without hacking up anything in the webConfigurator/pfsense config. Much easier.
-
I'm using squid3, not apache, so it wouldn't be relevant. I'm far more comfortable with apache reverse proxies, but had major issues when trying to get things working using the apache packages under pfsense, whereas squid, for the most part, works.
I'm using apache, because it can do the SSL stuff and pure HTTP applications are protected when they are accessed from the outside.
I don't use apache on pfsense. It is a separate server.
Anyway, what I ended up doing to get what I wanted was to create rules based on the requested subdomain - so rather than requesting
https://mydomain.com/pfsense
I'm requesting
https://pfsense.mydomain.com/
And that works because everything is now off the root path - /images, /themes, etc.
Ah! That's a great idea! Will have to check that out! But it still won't help with applications which put the host name into URLs >:(
The only downside is that because I don't have a wildcard ssl cert for mydomain.com (you have to pay extra for those), I've got to click through cert mismatch warnings to get to my site. But that's tolerable - it's only me accessing the few sites I have that require use of subdomains to reverse proxy properly.
Why don't you create your own CA? You could have as many certs as you need of any type you need. As long as your domain don't need to be accessed by the public, that's perfectly fine.
-
It's true, if your app/site hard codes the hostname into internal URL's, that'll be a problem. There is a mod package for apache that tries to change those I think, but from what I hear it doesn't work all that well.
If I use my own CA (which I did in the past), then you end up clicking through cert warnings (due to untrusted rootCA) as you do with an un-aliased cert subdomain.
I could get around that by adding my self signed rootCA to the trusted certs of whatever browser/computer I'm working on - but where it gets annoying is android. To add a cert there, android makes you use a lockscreen on your device, and I don't wanna do that (equally annoying).
With my purchased certificate, most of my proxied sites (not using subdomains) are authenticated no matter what browser/device I'm using. Which is good, because the few URI's I share with friends and family don't use subdomains, so they don't have to click through cert warnings or make exceptions. So ultimately my compromise is to deal with cert warnings on my subdomain URI's, rather than pay a bunch more for a wildcard cert. The basic comodo cert I purchased is quite cheap at ~$7 or so a year.
-
Just checked it out: mod_proxy don't seem to have the ability to proxy by the host name, since the matches are done against local paths.
-
Here's how I'm doing it…
services->reverse proxy
general/web servers tab should be straightforward. Jump in at mappings tab - you can create a mapping group like this:
.sub1.domain.com.$
.sub2.domain.com.$
.sub3.domain.com.$
.domain.com/URI1.$
.domain.com/URI2.$
.domain.com/URI3.$
.domain.com.*$I've also had success playing with the Redirects tab rules, but that's been really unreliable. I'll change something completely unrelated and the rules on that tab break.
anyway once you're passed to the apache server on your internal network, you can do yet more with redirects and RewriteRules.