Hello,

Question 1)

I want my Fritz!Box configuration page being accessible from internet through a subdomain. A configuration snippet like this one
[code]
server {
listen 80;
server_name fritz.example.org;
location / {
proxy_pass http://fritz.box;
proxy_redirect default;
}
}
[/code]
works for most of my (hardware) configuration webpages, but in case of the Fritz!Box the screen just shows plain white nothing. I noticed with "WebMin" that obviously webpages can still detect wheter they are being accessed through reverse proxy or not, so therefore I think this might be the case for Fritz!Box, too. Maybe for security reasons... So, is there a chance to hide the presence of the reverese proxy completely from the connected backends?


Question 2)

Wildcard domains - for free - are hard to find, so I would favourize a solution where the backends are being mapped through subdirectories in a form like this:
[code]
server {
listen 80;
server_name example.org;
location /fritzbox {
proxy_pass http://fritz.box;
proxy_redirect default;
}
}
[/code]
This configuration however does not work at all, not only with Fritz!Box but with almost every webserver! As can be read all over the internet this has to do with absolute and relative paths, and the only solution would be to realtime rewrite the transferred HTML-code that is passing the reverse proxy in both directions. I read that Apache has such feature, but Apache is kind of overkill for me (on my NAS). Does nginx have such feature, too?

best regards
ako673de

Hello out there!

Still my Fritz!Box is not accessible from outside. I tried many different reverse proxy solutions, like nginx, apache, Lighty, but all of them (or just my programming skills?) failed (especially) with Fritz!Box.

I know my problem is quite unique, because almost any other user simply sets a tick in the Fritz!Box menu to enable access from outside, but anyway, there must be a solution (for people having other content on their standard http and https ports while being limited to these two ports by their provider)!

Please, if anyone has such kind of setup working, tell me how you did it.

My (current) Fritz!Box is a 7360...

regards
ako673de



Edited 1 time(s). Last edit at 10/22/2013 09:27AM by ako673de.

Forget my earlier reply! Now it works with Fritz!Box!

What I did was simply to upgrade to the latest Firmware (my 7360 had a 2 year old version before), and maybe it was also helpful to enable the option "access Fritz!Box-services from outside" (even if I had to choose another port than 443 there). I don't know, but at least one of these measures helped.

So, on to the next "not reverse-proxyable" site, I thought. And (with just compiled nginx version 1.5.6) it now worked from the beginning with the "standard" configuration:

server {
listen 443;
server_name <dyndns-address>;
ssl on;
location / {
proxy_pass http://<local-address>;
proxy_redirect default;
}
}

But when I tried to access the same page from outside my local network the screen again was empty and again I was stuck.

Obviously some code of this webpage depends on the location of the webbrowser. So I tried google to find out which nginx command might be helpful, but honestly I didn't understand quite a bit. Unfortunately the nginx help pages weren't quite helpful, too:
- What exactly can "proxy_set_header" do for me in my case?
- What exactly can "rewrite" do for me in my case?
- What exactly can "sub_filter" do for me in my case?
- Are there other commands to solve the problem?
I'm lost here. I don't know what the webserver might need (it's the configuration page of my "yaVDR" media server) and I have no idea how to probably analyse the communication between nginx and the webserver to check the effects of the various nginx commands.

But for you that problem sounds easy to solve, doesn't it? Any suggestions are welcome...

ako673de

Take a look here (in German): http://www.forum-raspberrypi.de/Thread-fritzbox-fernzugang-und-nginx-web-server-%C3%BCber-gleiche-ip (I assume you're German-speaking, as you're using a Fritzbox).

Anyway, one (maybe _the_) esential issue in your configuration sample is that the argument of proxy_pass needs to be a numeric IP URL rather than a DNS URL (I don't know why).

Hope that helps,

Michael

SOLVED!

First one thing about your comment Michael. A numeric IP is necessary whenever you are using variables in the proxy path. This is because if the final string needs to be built during runtime nginx asks a resolver ro resolve the final address. And of course there is no resolver for localhost...

Anyway, the solution for MY problem took quite a while. In the end I was sitting and analyzing every bit of the http traffic between all the remote sites and the webserver. There was no difference at all. So what's going on here?

I cleared the cache and history of the malfunctioning (firefox) browser - with no luck. Restarted browsers - with no luck.

In the end I was sure that there is absolutely nothing different between the working and the not working browsers!

Well, except for one thing: One of the not working browser is behind a proxy.

So i tried another browser (IE), and e voila, worked.

And now guess what: From then on that browser that never worked before now works!

On another machine I made the evil browser work by installing "fiddler", a web traffic analyzer.

Can anybody tell me why these steps did help? Especially the proxy thingy. For that to make any difference the other browser must have had some communication with the proxy that caused the proxy to do something different from then on. Very obscure... Keep in mind that http traffic on both evil browsers was exactly the same before and after!

Don't know if someone will find this helpful, but never mind...
ako673de