However the wiki only sets up a single “forwarding” to an internal server with ssl/https, leaving IPfire the http part.
Moreover the wiki obviously shows only a part of the necessary lines in conf file, which means for a beginner it’s hard to follow and to decide which lines are needed and which must be replaced.
I’m trying to set up a reverse proxy for some subdomains and forwarding them to different servers in LAN with different end-ports.
E.g. One server can be reached with 192.168.6.96:5000 the other 192.168.6.97:80.
None of them is offering https support. SSL handling should be left to nginx.
This setup is advanced and should be introduced later. Don’t know if the wiki article is accurated for applying a Let’s Encrypt cert but time will show.
So, anyone running a similar setup and can provide an appropriate nginx.conf?
To recap: nginx should runs as a reverse proxy for http and https for subdomains and servers behind the firewall.
I know you prefer and recommend haproxy and dehydrated in various postings, however I found more examples for nginx and acme.sh script in contrast for your recommendations.
Dehydrated in wiki, for example, is just an excerpt of the commands help output instead of showing us some real live usage.
Ok, some rudiments are necessary and helpful. A webserver, load balancer, reverse proxy or failover setup is definitely NOT a “next>next>finish setup”. @hellfire you wrote that you want to use a reverse proxy.
Everyone who knows what it is should set it up mostly secure(I hope so).
I think my external link above is very useful and secure too(correct checkboxes are mandatory).
I did think about a haproxy setup because Michael prefer this. Maybe it is some easier as nginx but nginx will give me a lot of more features in future.
Unfortunately I’ve a not so common setup:IPfire runs behind a cable modem as exposed host, which means that the red address is a private one: 172.17.0.1, that’s the static IP address of the modem.
IPfire itself has 172.17.0.2, set up in the cable modem, a Fritzbox 6591, btw.
Nevertheless, I guess I then can use 172.17.0.1, right? IPFire does not know the external, public IP.
I use 3 different hostnames which will redirected to 3 different internal server.
F.e. mail.domain.tld -> 192.168.0.10, remoteapps.domain.tld -> 192.168.0.20:8080, monitoring.domain.tld -> 172.16.0.10
Incoming requests on :80 will be redirected into https and then forwarded to internal server :8080. I think SSL is state of the art today.
So your external IP from provider is e.g. 213.123.45.6 which traffic will hit your IPFire. I assume your are using nginx right now? Is there an option, too, to tell nginx which IP address to bind to or is this a generic setting in conf file like *:80?
What’s your current configuration? www (213.123.45.6) -> IPFire (IP?) -> green -> server (1-3)?
or
www (213.123.45.6) -> router (IP?) -> IPFire (IP?) -> green -> server (1-3)?
The setup above assume that I want to host multiple services myself. Home offices, small offices and so on.
No cloud hosting!
213.123.45.6 is the current IP which I get from my ISP. It could also be a static IP.
1st device is a router with DSL dial in(example T-Online) or in your case behind a cable modem with public IP, IPFIRE is a exposed host on it (192.168.2.254=red adapter on IPFIRE)
2nd device is the IPFIRE with nginx and all the configs you want on it (192.168.0.0/24=green adapter/subnet)
3rd rowServers are in green subnet. (192.168.0.10 and 192.168.0.20)
x.x.x.10 is the mailserver(Exchange)
x.x.x.20 is the remote desktop server(hosted some remote apps)
On both are running a webserver (IIS) on port 80 and 443. These servers are fully reachable from LAN(green subnet) and should reachable from WAN (the red side) only on port 443 via SSL/TLS by let’s encrypt.