The destination port range overlaps with an existing entry - Older Ver Allowed
-
Hey all-
The newer versions of pfSense have led to some frustration for me and I'm hoping someone can help. When I first imported my config.xml, everything worked fine, but as I started trying to make changes, I kept running into roadblocks where pfSense was telling me that something I used to be able to do, was not allowed. This is another example of this situation. I feel like I shouldn't have to directly edit the config.xml in order to accomplish what I'm trying to get done.
Essentially, what is happening is that pfSense will not allow me to create multiple NATs for differing Source IPs, directed to the same Destination Port. I get the error that is listed in the Subject.
Following is a Real World Example.
I have a Software Provider that is going to be changing ISPs, and so, will have new Public IPs. I would like to create a new NAT Rule that will allow their new Public IP ( Source Address ) to access a resource as soon as it becomes available to them. I would not like, however, to sever their connection before the new connection is live. I'm getting an error because their is already NAT mapped for their old Source Address/Destination Address and Port, that "conflicts" with the new Source Address/Destination Address and Port.
It seems like this should not be the case. To me, please correct me if I'm wrong, I should be allowed to create as many different NAT Rules as I'd like, so long as pfSense can decipher the difference between them. In this specific scenario, pfSense would apply the Rule based on the Target first, and then the Source. If both are not a match, a cascade should occur to the next Rule. I'm failing to understand why I cannot create multiple NAT Rules bound for the same Destination IP and Port, but with differing Source Addresses/Ports.
Please Help!
–Thanks
Joe
-
An interesting problem to be sure.
I usually create NAT and FW rules separately, ie: don't associate it to any filter rule, this way you don't run into this type of problem.As an example, making a web server accessible to a couple of different outside clients via HTTPS.
NAT port forward: SRC Address=ANY SRC Port=ANY DST Address=WAN IP DST Port=443 NAT IP=Server-Internal-IP NAT Port=443 FW rule 1: Protocol=TCP SRC=Client-1 SRC Port=ANY DST Address=Server-Internal-IP DST Port=443 FW rule 2: Protocol=TCP SRC=Client-2 SRC Port=ANY DST Address=Server-Internal-IP DST Port=443
-
Since your really only sending to the same box and just want to allow different/multiple different source ranges/IPs - wouldn't you just an alias as the source in the nat, this way when you let it associate the firewall rule it uses the alias. You just put whatever you want to allow in the alias.
Or am I misunderstanding the problem?
awebsters solution works as well.
-
Thanks for the quick responses guys. Appreciate it. In any case, I am able to assign multiple host IPs to the Alias, but am unable to use multiple Aliases for the Source IP ( if the Destination Port is the same ). This will work in the case that all of the IPs are from the same company, but makes it convoluted if the Source IPs are from different companies. In that case, I would have to create an Alias called "HTTP_Allowed" or something similar, and then add all of the IPs to that Alias that I would like to allow through to the webserver ( using the previous example ). That seems to rob you of flexibility, especially in the case where you need to quickly disable an entity's access. You would then need to sift through a list of IPs in order to weed out the ones that you don't want. If instead, I could just disable the rule that allows CompanyABC to access the webserver, without affecting any of the other companies, then that would be ideal. It used to be so much easier, so I was hoping that there was some way around this. It seems like I'll be stuck manually editing the config.xml file in order to implement these types of changes. If I make manual additions and then reload the firewall, then everything works as it should. It's just the web interface that gets in the way in this case.
-
huh??
How would editing the xml file be easier then editing an alias?
Company B no longer needs access - its .2 seconds to delete their netblock from the alias.
-
That's easy enough if your alias only contains a few addresses, but if there are several addresses, sometimes for each company, added at different times, then it quickly becomes a headache. It's easier to just edit the config.xml because the web interface will still show the entries in the config.xml and allow you to enable/disable them, it just will not allow you to create new entries of that style, or save them if you tried to modify them. So for example, if I created several entries for different companies ( in config.xml ), they would all show in the web interface, and I would be able to disable a specific one if need be, I just would not be able to modify them using the web interface. I could, however, disable an entire company's access with a simple click. Rather than having to sift through a potentially long list of aliases to find them all ( and possibly even miss one ).
-
Do whatever makes you happy.. Even if you had 100 companies, I would think a simple list with the company names would be easier to click then editing a xml file. But whatever floats your boat..
Shit a 1000 companies even.. Why would you not do netblocks vs individual IPs, etc.
