Specifying Source in NAT rule
-
I'm replacing an existing Watchguard Firebox (due to load balancing support), and am pretty happy with how my configuration of pfSense has gone up until now, but I'm stuck.
In the Watchguard, we had the option of selecting a Source IP / Port to limit the port forward rule to, and took advantage of it in the following way:
5 people needed to be able to use MS RD to get access to their workstations. So we found out their home IPs, and created 5 rules.
Rule 1 pointed RD connections from home IP 1 to workstation 1, rule 2 from IP 2 to ws 2, etc.
All of these rules used the same external IP and port.How do I replicate this setup in pfSense?
All I have found is an old discussion of how this should be added to pfSense 1.0:
http://www.mail-archive.com/support@pfsense.com/msg05904.html
-
When you add the port-forward rule, by default it automatically creates a corresponding firewall rule to allow that traffic through. You can modify that firewall rule that ends up under the outside interface to specify a source rather that allowing from everywhere. To prevent creating multiple firewall rules, you could create an alias that has those 5 allowed hosts and just allow the alias in the source field.
-
I don't think that accomplishes this goal.
If I create simple firewall rules, that just means that others can't access that port, I still need the ones with access to be redirected to the corresponding (different) internal IPs.
-
Sorry. You cannot do this in the GUI.
Not sure if you could do it through manually writing pfrules.You would have to start digging the pf man pages and see if it's possible.
-
And using 5 separate ports on WAN (like 20001 .. 20005) is not an option? NAT them to the respectice internal IPs then.
-
We would very much like to avoid the confusion using non-standard ports would cause the end-users.
I hesitate to manually alter any configurations using the command line out of fear that the next use of the GUI would overwrite them.
Unfortunately, I have no cash to contribute to this, otherwise I would offer a bounty. Given the description in thread I linked to, I had hoped this would either be done, or be easy to add to a future version (it seems like there's no new functionality, just a GUI change).
-
Don't know which confusion.
You can even e-Mail them a new Remote Desktop Connection setting as .RDP file. It contains domain AND port already, the user only has to enter logon credentials.
I really don't see your point here.…and with a non-standard port you even raise security since vulnerabilities in MS-RDP are not that easy publicly exploitable. Definitively a plus!
-
That would still be difficult and annoying to our end users, but it's really beside the point. Even if there were a good solution for this particular usage case, the issue still remains.
It sounds like specifying a source in NAT rules is currently impossible while retaining use of the GUI. My question at this point is whether that is something planned for a future release?
-
Sorry about my post guys, misunderstood the question.
-
I think one problem is that giving users more options gives them more opportunities to screw things up. I can see specifying the source for NAT being useful, but it would be a rarely-used option that only a handful of people would ever need. I would love to see an 'expert' box hidden under several warnings that would allow you to input raw syntax for a rule. It wouldn't have to attempt to display it, just add it to the ruleset. I have had couple of times when I wanted to do something unsupported by the GUI, like outbound NAT vs an address pool, pointing a fw rule to a custom table, etc.
