Client machine is not using pfSense as its default gateway
-
I thought of an explanation of why ISA handles this differently. I believe Web server publishing rules in ISA don't actually do port forwarding, but rather bridge the request. pfSense does a standard port forward.
Is the "Client machine is not using pfSense as its default gateway" a limitation for any standard port forwarding, not just pfSense?
-
I'm not sure what you are asking. If outside host connects to pfense and pfsense forwards to an internal host, that host needs a default gateway (unless the source address is NAT'ed too, which can be undesirable). AFAIK, linux port forwarding works the same way.
-
I'm not sure what you are asking. If outside host connects to pfense and pfsense forwards to an internal host, that host needs a default gateway (unless the source address is NAT'ed too, which can be undesirable). AFAIK, linux port forwarding works the same way.
Sorry, I forgot to mention that the default gateway of the internal host is set to my ISA server, not the pfSense server. Here are some tests I ran that will hopefully clarify:
1. WAN -> pfSense -> web server (default gateway set to ISA): fail
2. WAN -> ISA -> web server (default gateway set to ISA): pass
3. WAN -> pfSense -> web server (default gateway set to pfSense): pass
4. WAN -> ISA -> web server (default gateway set to pfSense): passTests for pfSense port forwarding only work if the default gateway on the internal host is set to pfSense. If it's set to something else (e.g. ISA server), it fails. However, tests for ISA pass regardless of what the default gateway on the internal host is set to.
As I mentioned in my second post, I believe ISA is not doing port forwarding but rather bridging, so I think that's why web server publishing rules in ISA don't have the same limitation.
Is there anyway to workaround this limitation? This would be useful for testing prior to the transition from ISA to pfSense. It could also be useful if I'm testing a new firewall in the future (such as pfSense 2.0 on another machine).
-
I am not sure I understand the setup. The pfsense is not your gateway for the LAN? If not, how are the outside requests getting to it?
-
I apologize for not being clearer.
pfSense is currently not the default gateway for the LAN. The outside requests are getting to the internal hosts through a different firewall.
I'm currently using Microsoft ISA 2004 server for my firewall and gateway. Due to some limitations (mainly with QoS, SIP and hardware requirements), I have been looking into other alternatives. Many of the sipXecs mailing list users highly recommend pfSense, so here I am.
For testing purposes, it would have been convenient to be able to set up pfSense on the same LAN as ISA, set up some port forwarding and firewall rules to existing internal hosts that still have ISA as the default gateway and test. However, it appears that this is not possible, as port forwarding rules in pfSense require the default gateway of the internal hosts to be the pfSense machine.
For ISA server, this is not a requirement. A web server publishing rule in ISA does not require the internal host to have the ISA server as the gateway.
I'm just trying to figure out why this is a requirement in pfSense, and if there's anyway to have a different default gateway set for the internal host when port forwarding from pfSense.
-
Like I said, any unix-based port forwarding system I know of (including iptables in linux) is going to have the same issue. If this is just temporary, would it kill you to have the default gateway be pfsense? If so, you can probably set an inbound NAT entry so that the requests will look like they came from pfsense, in which case the replies will go back there (but having no idea where they really come from may or may not be okay with you.)
-
ISA 2004 web server publishing rules can make traffic to the webserver "appear to come from ISA" or "appear to come from the original client." I wonder if changing this setting in the rule would make it alternately behave like pfSense, and like you're seeing? It wouldn't solve the problem but it might narrow down the functionality. I have a site with an ISA 2004 box that I've managed for around 7 years; it's worked well, I've learned its ins and outs for sure, but I'm contemplating a switch to pfSense as well. However, it probably doesn't make sense to do that until 2.0 is released, at least in my case. Though I'm having some issues with ISA that are making me want to switch sooner now :-)
Some of the issue may also have to do with the statefulness of the firewalls. If pfSense is only seeing "half" of the conversation because ISA is getting the outbound half as the default gateway, and perhaps it's not liking that it doesn't "know" about the inbound half of the connection? This may go back to the idea of ISA doing bridging above…but it's too late (early?) for me to wrap my head around it entirely right now. The bridging thing sounds plausible to me though, but like I said, I think it's controllable in the ISA rule.
Also, look at pfSense's Package for "Proxy Server with mod_security." It's description says, in part, "In addition this package allows URL forwarding which can be convenient for hosting multiple websites behind pfSense using 1 IP address." which may or may not help you out, especially since ISA can do things like proxying websites with different hostnames and paths to different hostnames and paths internally and pfSense port forwarding (and simple port forwarding in general) cannot do this directly without a reverse proxy running. I haven't used that pfSense package myself enough to know if it will help in your situation, but I'd look at it. I need to investigate it more myself.
-
I think ISA acts as a Reverse-HTTP-Proxy Server in the context you have described. This is the M$ way of putting a reverse proxy server in a "DMZ" (i.e. built into the firewall). Not entirly sure if this is as secure as having a seperate reverse proxy server (e.g. Apache with mod_proxy) in a real DMZ, however that is another topic for another day :P
You need to change the default gateway of your web server to pfsense. That is just how port forwarding works ;)
-
If you don't mind losing the source address, you can use an outbound NAT rule on the interface that communicates with that server to have it do NAT when the destination is that server. This will make the server reply to that router that forwarded the connection to it, so the reply can go along the proper return path.
-
I am currently testing pfSense and ran into an issue with a simple http port forwarding rule. I followed the Port Forwarding Troubleshooting guide and found that the problem was related to common issue 3 - "Client machine is not using pfSense as its default gateway".
I was wondering if someone could explain this limitation. Also, is there a workaround?
It's basic networking - if the reply traffic isn't going to go back to the firewall, as it won't in such a scenario, it can't send it back to the Internet. ISA is a reverse proxy in that scenario, the traffic is sourced from ISA, not the remote public IP.
Efonne's work around would suffice but is ugly, better not to NAT like that where you can avoid it. A better deployment with ISA in most cases is to not use it as the default gateway but just as a proxy/reverse proxy.