Project

General

Profile

Actions

Bug #6173

closed

/firewall_nat_edit.php: dsttype_selected wrong when edited w/VIPs defined

Added by Jean CHEF almost 8 years ago. Updated almost 8 years ago.

Status:
Resolved
Priority:
Normal
Category:
Web Interface
Target version:
Start date:
04/15/2016
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.3
Affected Architecture:

Description

When I edit a NAT rule, existing value for destination mask (alias IP for me) disappear and type is "any" even before I save "Single or alias".


Files

2_NAT-rules-edit.png (7.83 KB) 2_NAT-rules-edit.png Destination adress when I edit the rule Jean CHEF, 04/15/2016 10:39 AM
1_NAT-rules-list.png (28.1 KB) 1_NAT-rules-list.png Informations of my rule after save Jean CHEF, 04/15/2016 10:39 AM
portforward.png (48.2 KB) portforward.png First few rules in Port Forwarding Jacob Suter, 04/19/2016 09:10 PM
rule3.png (93.6 KB) rule3.png Rule #3 Jacob Suter, 04/19/2016 09:10 PM
Actions #1

Updated by Chris Buechler almost 8 years ago

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

Actions #2

Updated by Jean CHEF almost 8 years ago

I tried on 2 OS : LinuxMint and Ubuntu Mate, with 2 browers : Chrome and Firefox. I have same issue.

I joined 2 pictures for explain issue :
  1. At first, I maked a NAT rule, I saved it
  2. After, I want to edit it
Actions #3

Updated by Phillip Davis almost 8 years ago

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.

Actions #4

Updated by Jim Thompson almost 8 years ago

  • Assignee set to Chris Buechler
  • Affected Version set to 2.3
Actions #5

Updated by Jacob Suter almost 8 years ago

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.

Actions #6

Updated by Phillip Davis almost 8 years ago

@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.

Actions #7

Updated by Jacob Suter almost 8 years ago

Phillip Davis wrote:

@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.

No problem. I did have to white-out a lot of the data to be on the safe side.

The problem seems to exist on both rules written before and after the update. I've hit edit on all (40ish) forwards and all of them drop their destination info when edited. I've also cloned a couple rules today and they also did not copy over their destination info.

If you'd like to check on the box directly, I can get you access to it.

Actions #8

Updated by Anonymous almost 8 years ago

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

Actions #9

Updated by Phillip Davis almost 8 years ago

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!)

Actions #10

Updated by Jacob Suter almost 8 years ago

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.

Actions #11

Updated by Chris Buechler almost 8 years ago

  • Subject changed from /firewall_nat_edit.php : existing value for destination disappear when edit to /firewall_nat_edit.php: dsttype_selected wrong when edited w/VIPs defined
  • Status changed from New to Feedback
  • Target version set to 2.3.1

Finally found a way to replicate this. Fix pushed. Just because $config['virtualip']['vip'] is an array in your config doesn't mean 'dst' should be the selected option. I'm not sure what the intention was there.

This seems to work the same for all the combinations that worked before, and fixes systems with VIPs defined where this ended up as "any".

Phil: if you could sanity check me on that fix, I'd appreciate it.

Anyone seeing this issue, if you can apply this and test, please report back with results.
https://github.com/pfsense/pfsense/commit/70854dac17c0d0d42f4283d25156f1c03d337e8b
can use https://doc.pfsense.org/index.php/System_Patches if you're not familiar with patches.

Actions #12

Updated by Phillip Davis almost 8 years ago

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

Actions #13

Updated by Phillip Davis almost 8 years ago

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.

Actions #14

Updated by Chris Buechler almost 8 years ago

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.

Actions #15

Updated by Phillip Davis almost 8 years ago

  • % Done changed from 0 to 100
Actions #16

Updated by Phillip Davis almost 8 years ago

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.

Actions #17

Updated by Jacob Suter almost 8 years ago

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.

Actions #18

Updated by Chris Buechler almost 8 years ago

  • Status changed from Feedback to Resolved

all works now

Actions

Also available in: Atom PDF