Putting apache behind pfSense (NATing) on a machine with two different interface
-
Hi,
This might be impossible to do, or not. I'm hoping for the second. This is partly a linux question and a pfSense question. It is definitely a network question.
I have a proof of concept PC with 2 ethernet cards. I want one card to be publicly accessible to the Internet (it's got a WAN address). I use linux ip tables to lock this interface down to one specific service from one specific set of hosts, that needs to be publicly accessible and that I don't want protected behind a router (The service is too critical, I don't want it to go down when I reboot the router).
I have a second NIC, which is plugged in to a pfSense (2.2.6), on an internal (192.168.1.25) IP. This one I use it all other services that are available on the LAN.
To make things work, I had to put in a few ip route rules. Everything works fine at this point, and has been working fine for months.
Now, let's throw a wrench into this. I want one service (httpd) to be running on 192.168.1.25 (LAN interface), but accessible from the internet. I naturally turned to the NAT rules, putting in a rule for http redirection to 192.168.1.25.
It's not working, and after a few hours of scratching my head I finally found why. I can either choose the server's ip route rules for the server to go out on the LAN interface (via the router) for outgoing connections, OR using the WAN interface. I can't figure out of way to tell it to use the WAN interface when the connection came in through the WAN, and the LAN connection if it came in from the LAN.
The net effect is that when accessing the httpd service through the port forward, it doesn't work as it is. It does work if I change my server's ip route to go out via the router, but then that other critical/WAN accessible service stops working. It's one of the other, at this point.
I can't even begin to form a solution. Any hint, besides to stop using two NICs each with their specific routes?
-
You need policy based routes on your Linux server. Read here how to do: https://kindlund.wordpress.com/2007/11/19/configuring-multiple-default-routes-in-linux
If you don't care about the source addresses in the webservers log you can also resolve this by an outbound NAT rule on pfSense for the traffic to the webserver.
-
I'm looking forward to trying it, but it's very clear this is exactly what I was looking for.
Thank you!
-
"I don't want it to go down when I reboot the router)"
Seems like a odd reason to directly expose a server.. So you go about rebooting pfsense all willy nilly like? If you need services to be up while you reboot pfsense, wouldn't you want pfsense setup in a carp so one can do down and still be behind a firewall.
If your going to expose the box directly to the internet, why would you then expose a httpd through the nat? Again seems like a odd configuration.. But yes you would need to do policy routing on the actual linux server to fix this issue. Or nat the connection coming in from the internet through pfsense so it looks to be coming from the pfsense lan IP.
From a security standpoint you have a issue, if this webserver you directly exposed to the internet is compromised your local network is at risk.. Is the other interface that is connected to your local lan firewalled off from the rest of your network?
Normally this is why you put any boxes serving to the internet in their own segment (dmz or firewalled segment) from the rest of your network. That is kind of hard to do with a multihomed server that you directly connect to both the internet and your local network.
-
From a security standpoint you have a issue, if this webserver you directly exposed to the internet is compromised your local network is at risk.. Is the other interface that is connected to your local lan firewalled off from the rest of your network?
This really wasn't the question, but in principle a service exposed to the Internet (http is a typical example), through a NATing router, to the server's LAN interface - which is the more classic case - is also connecting the LAN to the WAN. Everything depends on firewall rules, whether in my multihomed scenario or a classic NATing router. You'd need to firewall off the LAN too in both cases.
In other words, the devil is in the detail, but a NATed server or a multi-NIC server both have the same risk if the LAN security is badly designed.
Seems like a odd reason to directly expose a server.. So you go about rebooting pfsense all willy nilly like?
No I don't, but it happens, and I did have some lock-ups of pfSense in the past (hardware related - my new hardware seems to be more reliable) but opening up port x to the WAN on a server and NATing port x to that same server through pfSense, ends up being the same thing, with one less point of failure. In the case of httpd, which I want NATed, different processes/packages on the pfSense can help with enhancing security. In the case of my other critical service, pfSense does nothing to help, the security needs to be server-side anyways.
I'm not disputing the usefulness of a router, it's just that for anything public a hole needs to be punched. I'm just punching it on that server.
-
I would personally rather have one security configuration in one place (like in pfSense) for all of my public servers than maintain a bunch of iptables on various hosts. If there is a security issue on one of your hosts, they are on your LAN. Same with pfSense, but it's only one device to patch.
CARP/HA solves your "reboot the router" downtime.
-
I wouldn't punch it on the server when you have a router/firewall that is designed to do that.. I would never forward to a server directly on normal lan where all your other boxes are, like I said I would put the server that is serving up stuff to the public in its own isolated segment from the rest of my network..
So even if its compromised it would only have access to your other stuff in this isolated segment.
"pfSense does nothing to help, the security needs to be server-side anyways"
How is that?? When you can use the firewall on pfsense to only punch the whole to this server on the actual service ports and don't have to worry about something else listening that you didn't firewall at the host firewall, like say samba, or ssh or whatever.. If say your serving up ntp, that is the only thing allowed from inet to this box. While it might also be running ssh or http, etc..