DNS Forwarding/Port Forwarding n00b question…
-
Hi gang,
I've managed to battle through every issue I've come across so far, and have found good success incorporating pfSense into my home project.
Running a groupware solution is a necessity for my home based business, not to mention all the features that I WANT to be able to add in order to satisfy my geekness, and so my DSL connection with 8 IP addresses which I used to run a WLAN, a LAN and a Server subnet (specifically a box running Win2k3Server and Kerio Mail/BPFTP/Apache) has been replaced with a faster, cheaper, better DSL connection with a single IP address thanks to pfSense. I built a box up from a P4 base with a 10Gb HD and installed two additional NIC's, in order to have a WAN port, a ServerLAN subnet and a GeneralLAN subnet.
That's the background.
I have two domains for essentially the same business, and I have the mail.mydomain.com and mail.mydomain2.com pointed to the IP address of the WAN, along with www., webmail., and the 'usual' hosts. With my current setup, traffic goes exactly where I want it to go, most specifically to the server on the the ServerSubnet.
This is where I want to complicate things.
My basic structure on the network is as follows: pfsense box obviously has a WAN address, and then its internal LAN subnet is the 192.168.3.0 subnet and its internal WAN subnet is the 192.168.2.0 subnet. The server box takes an address directly on the WAN subnet, while the LAN subnet (192.168.3.0) feeds a single device, a wireless router, which in turn establishes a subnet 192.168.1.0 on which all my domestic pooter boxes and trixbox server/IP phones reside happily.
I have a couple of boxes in my system, one is the pfSense box, and the other is a VOIP server on my LAN subnet, which I'd like to be able to 'web interface' with from the WAN.
The problem that I'm hitting is that traffic on port 80, and traffic on port 443 all get routed to the server box on the server subnet where Apache process them as requests for http/https on the principal domain as if they were 'www.mydomain.com' or 'www.mydomain2.com.'
I have DNS forwarding in pfSense set up to direct traffic for, say, firewall.mydomain.com to the network address of the pfSense box in its position 192.168.3.1 as the gateway of the LAN subnet which feeds a wireless router. In firewall NAT I have port 80 opened for destination to the server address, as well as port 443 so that the HTTP server can handle all traffic that its supposed to.
I've set pfSense to assign its web interface to port 10318 and this is where everything falls to bits.
I think it's an expectation over possibility issue, perhaps, and that I've simply got the concept wrong…
I had assumed that if I had the following set up, as an example, in DNS forwarding:
alias1.mydomain.com --> 192.168.2.10
alias2.mydomain.com --> 192.168.2.11
alias3.mydomain.com --> 192.168.2.12that traffic on port 80 or 443 would be directed to the appropriate box based on what the ALIAS determined, as if the ALIAS determines the destination.
In my clearly broken logic, then, I imagined that in NAT: Port Forward I would simply set up open port rules for all those servers for traffic on ports 80 and 443, that this would open the ports to all those machines and that the DNS forwarding would determine from the request for traffic on the WAN WHICH of the servers the traffic needed to pass to.
In this same logic, then, I assumed that if I had set firewall.mydomain.com to point to the LAN address of the pfsense box, and if I had set the pfsense box to receive HTTP traffic to port 10318, that having the NAT: Port Forward rule take port 80 traffic for the LAN address of the pfsense box and translate it to port 10318, it would do the trick.
I'm clearly missing a lot here, because all that the firewall.mydomain.com netmask gets me both from LAN and WAN is a 'test page' which is stored on the webserver and dished out by Apache, demonstrating that the traffic ISN'T being routed anywhere specific, but to a catch-all on the webserver.
Ideally I'd like a situation where:
www.mydomain.com 80/443 goes to the web server
firewall.mydomain.com 80/443 goes to the firewall web interface
trixbox.mydomain.com 80/443 goes to the trixbox server config pages
webmin.mydomain.com 80/443 goes to the trixbox server/webmin port 10000All without specifying port numbers in the URL in a web browser...
Now...
A friend advised me what I already knew, that Apache handles rewrites. He suggested that a NAT/firewall device couldn't handle routing the same type of traffic using the same ports to multiple servers within a network, that it was an 'either/or' and that the HTTP server (Apache) on the main server box was establshed via a NAT/Firewall Port Forwarding rule to accept all traffic on port 80/443 regardless of the requested domain, and that the only answer was to use Apache rewrites to then send the traffic where it should be going on the network.
I've already done this in a sense, by having webmail.mydomain.com point to this same combined Apache/Kerio/FTP server box and letting Apache perform a rewrite on webmail.mydomain.com by pointing it to port 10316 which Kerio is set up to receive webmail interface traffic on, so that the same box can run Apache (port 80) as well as the webmail feature of Kerio. If there were some way of abandoning this rewrite because I could have pfSense take all port 80 traffic for webmail.mydomain.com and separate it from port 80 traffic for www.mydomain.com and send it to port 10316 instead, that would be a winner, and no doubt a key stage in my understanding how all this can work. Yet my friend is insistant that Apache rewrites are the only way he can think of.
While I acknowledge that Apache can indeed do this, I'm still pretty convinced, probably wrongly so, that the purpose of a box like a pfSense box is to do just that without having to pass all the traffic to a webserver in order to have Apache do rewrites, not least because an efficient network with functionality accessible to the WAN would never depend on a single machine other than the firewall box which is designed to be ultra-reliable, to rewrite network addressing in order to route interface type traffic to the right boxes, just in case the web server in question fell over, while the firewall and the other boxes continued to run...
I'm convinced that there must be SOME way of doing it, but I'm so new to this that at the moment I think the only 'solid' idea that I have is that it MUST be possible, and the general theory of how it should work.
My admiration and appreciation to anyone who can decipher my ramblings and tackle what I'm sure is a really elementary subject for many, in order to walk me through the theory and the practice of what can be done in these instances...
Hopefully,
SampleX
-
A friend advised me what I already knew, that Apache handles rewrites. He suggested that a NAT/firewall device couldn't handle routing the same type of traffic using the same ports to multiple servers within a network, that it was an 'either/or' and that the HTTP server (Apache) on the main server box was establshed via a NAT/Firewall Port Forwarding rule to accept all traffic on port 80/443 regardless of the requested domain, and that the only answer was to use Apache rewrites to then send the traffic where it should be going on the network.
I've already done this in a sense, by having webmail.mydomain.com point to this same combined Apache/Kerio/FTP server box and letting Apache perform a rewrite on webmail.mydomain.com by pointing it to port 10316 which Kerio is set up to receive webmail interface traffic on, so that the same box can run Apache (port 80) as well as the webmail feature of Kerio. If there were some way of abandoning this rewrite because I could have pfSense take all port 80 traffic for webmail.mydomain.com and separate it from port 80 traffic for www.mydomain.com and send it to port 10316 instead, that would be a winner, and no doubt a key stage in my understanding how all this can work. Yet my friend is insistant that Apache rewrites are the only way he can think of.
Your friend is right.
pfSense is a NAT/router (and quite a lot more), but not a L7 filter.
To make a descision to which server a packet should be sent, the pfSense would have to analyze each connection on a much higher layer.
I think 2.0_alpha_alpha will have L7 filtering which "should" be able to do what you want, but 2.0 is still far away. -
OK. Thanks for that. I'll have to plumb the depths of his brain for how to do what I want to do…
There'll be no working with him now... Talk about gloating opportunity ;-)
