Port forwarding for a single domain

Networking
1

apologies if this has been answered already and i can’t find it. i’ve done some searching and haven’t been able to locate any thing yet.

i have ipfire running successfully for several year now. i have a couple domains that point to my public ip from my isp, and use a port forwarding rule forward requests on various ports to a server hosting the services. currently, all the service for each domain are pointing to the same internal server, so this is a pretty simple setup. requests for domain1 port X forwards to server 1 port X, requests for domain2 port X also forwards to server 1. decisions on which page to server for a given domain are made by apache on server 1, for instance. the services on each domain use the same ports, i.e. domain1.com:80 and domain2.com:80, and cannot be changed to use different ports unfortunately.

i would like now isolate domain 1 services and domain 2 services to different servers (domain 1 requests to server 1, domain 2 requests to server 2). is ipfire capable of this? if so, how? all i have been able to find is examples of forwarding all requests, regardless of domain being addressed.

2

I never tried but I think the way to go is to install on IPFire a reverse proxy, which will take care of sending the traffic to the right machine based on the incoming domain. You can use HAProxy or nginx for this purpose. For nginx, it should be something like this:

server {       
     listen       80;
     server_name  domain1.com;

     location / {
          proxy_pass "http://server1:8080" ;
     }
}
server {       
     listen       81;
     server_name  domain2.com;

     location / {
          proxy_pass "http://server2:8081" ;
     }
}

As I said, never tried before, so this very likely will not work, but it should give you an idea (source: https://timothy-quinn.com/using-nginx-as-a-reverse-proxy-for-multiple-sites/). The virtual domains and the combined use of the proxy_pass directive should be at the core of what you want to accomplish. You can also serve to different servers based on the location directive, where you change server based on the directory part of the url, this is described in the wiki as well (link above).

I also think the DNAT based on port 80 should have as the destination the firewall itself, as HAProxy or Nginx will run on IPFire with this setup.

2 Likes
3

thanks for this. i have been looking into using apache proxypass and proxypassreverse to pass the requests from server1 to server2 in a lightweight manner. doing this directly with ipfire would be better if i can figure it out and get it working.

with apache on server1 now, one difference with the example you provided is that i have both domains listening on port 80, which is possible since it’s a single server hosting the pages and apache does the virtual hosting. need to read up on what you’ve shared, maybe the virtual host piece of this is available with nginx or haproxy as well.

4

Thanks and all the best with this project. May I ask to share with this audience the results of your work? Maybe it can be helpful to others as well.

1 Like
5

i have it working with apache reverseproxy on server 1 pointing to server 2. i decided i didn’t want to mess with the firewall as that would impact a lot of people (behind the firewall) if it went “wrong”.

one issue remains - i am able to reach server 2 via it’s domain name and ip address (this is what i want), however i am not able to authenticate into server 2 (login page loads, credentials are accepted, authentication fails though). next up is to figure out why i am not able to authenticate, which i’m pretty sure is an issue with the application on server 2 (using ip address to reach server 2 - auth works fine).

6

While apache or nginx are viable solutions I recommend caddy or traefik. The reason is that each one automatically handles https setup. They need ports 80 and 443 open for ACME and request certs from letsencrypt and/or zerossl on their own. They definitely are at least worth to check.

7

thanks, will look into both. even if i don’t ultimately use either, it’s always good to learn a bit more about different options and approaches.

https is a concern in this case, and while it’s working now it wasn’t the ideal setup i was looking for, so some room for improvement still. just need to evaluate if the effort is worth it to go through the setup process again.