pfSense

don't think I'm seeing what you're referencing there. What OS and browser? Cleared your browser cache?

I can't replicate it either.
Can you show a screen shot of the whole rule?
Maybe there is some unusual setting in some other field that is interacting somehow. Seeing all settings might help reproduce it.

I am experiencing the same issue. My installation is an upgrade from 2.2-Release, installed from the ISO approximately 2/1/16.

When editing or cloning a NAT rule, the destination block always returns to "Any". I've verified this in Chrome 49.0.2623.112m and Firefox 45.0.2 under Windows 10 x64. Both browsers have had their full history/cache wiped with the same result.

My screen caps would look identical to the ones above, but I'm using IPs instead of object names.

@Jacob can you provide a screenshot of the whole NAT entry that has this problem.
I have tried various different NAT rule settings and can't make it happen.

I have tested with the same setting you have in you MS-RDP rule, but was not able to reproduce the issue either.

Unless Phil has a flash of inspiration, I would suggest that you try accessing the GUI from a different browser on a different work station (if you have not done that already.) Browser caches and plugins (particularly 1Password/Lastpass type plugins) can do very strange things to input elements.

Failing that I think one of us will need access to your firewall to diagnose it further. By all means email/PM Phil or me and we can set something up. I am UTC/GMT -4 hours time zone, Phil is in UTC/GMT +5:45

I still cannot reproduce it. I copied all the things in your screen shot (filling in valid IP addresses where you redacted bits in the middle) includijg the non-default NAT Reflection and Filter Rule Association that you are using. For "Destination" I selected "Single host or alias" and a random IP address 5.6.7.8
When I edit the port forward rule again, it shows the Destination data that I entered.

This sounds like a bit of JavaScript not setting the selection on startup. Did you force the browser to reload everything, including JS? For me, ctrl-F5 does the trick.

And for 2016 I am in Central Australia UTC+9:30 - but my laptop is still on Nepal time :) (and probably my forum settings... I did change my watch!)

Phillip Davis wrote:

I still cannot reproduce it. I copied all the things in your screen shot (filling in valid IP addresses where you redacted bits in the middle) includijg the non-default NAT Reflection and Filter Rule Association that you are using. For "Destination" I selected "Single host or alias" and a random IP address 5.6.7.8
When I edit the port forward rule again, it shows the Destination data that I entered.

This sounds like a bit of JavaScript not setting the selection on startup. Did you force the browser to reload everything, including JS? For me, ctrl-F5 does the trick.

And for 2016 I am in Central Australia UTC+9:30 - but my laptop is still on Nepal time :) (and probably my forum settings... I did change my watch!)

The good news is the problem can be worked around, I just have to be careful to re-input the destination.

I even broke out IE11, which I'd never used previously (except to download firefox) and it's exhibiting the same behavior. Tried crtl-f5 in Chrome and FF, same results.

I do run AdBlockPlus in Chrome and FF. IE11 should have nothing installed. I'll use my test laptop (Fedora 23 w/ firefox) in the morning (UTC-6 here) to see if there's a change.

If there's no change, I have another idea (kick WebUI into http mode, tcpdump the webserver output to see what's sent over - to see if its a browser/js/parsing/plugin/weird issue) to check.

That fixes the problem reported here. But now if you have selected a VIP from the dropdown of special destinations, then when you edit again it displays "Any" instead, forgetting the selection of the VIP.
The problem is in is_specialnet() which checks if the value is in an array $specialsrcdst which is built up the top of firewall_nat_edit. $specialsrcdst array has all the strings that are special sources (like any (self) pptp pppoe ltp WAN WANip ...). So it works for source selection. But the destination selection also has special entries for the VIPs. So those would need to be added to $specialsrcdst array for the dst case.
Actually the array/list of those special nets/things is built by build_dsttype_list() which is used for making the actual dropdown list. We just need to check if array_key_exists() in that array to determine if it is a special net.
See Pull Request https://github.com/pfsense/pfsense/pull/2893

Note: The code for the src fields that uses $specialsrcdst and is_specialnet() works OK. But build_srctype_list() builds a similar structure. One is used to build the dropdown list, the other is used to see if the existing data matches a selection. If the functional content of the 2 lists becomes different then there will be future problems in that area of code also.
Once we have confirmed that the code solution for the dst case is good, I am happy to refactor the src case to work the same way - removing the $specialsrcdst and is_specialnet() use.

Thanks Phil! I was expecting some kind of edge case from fixing that, and hadn't yet had a chance to review every possible use case.

merged to master and 2_3.

PR https://github.com/pfsense/pfsense/pull/2895
1) Delete some unused code
2) Make the src type matching work similar to the dst type
3) Make the dst type dropdown entries "WAN" "LAN"... actually say "WAN net", "LAN net"... like it is for src type.

The situation I'm working with is a bit strange:

I have a block of publicly routable IPs routed toward my pfSense's WAN port CARP IP

All PCs behind pfSense are on private IPs

I forward all outside access to the internal servers using destination NAT based on specific destination IPs, protocol, port, and occasionally limiting the NAT access to specific source IPs or networks.