[SOLVED] Re: Firewall>NAT>Port Forward issue with port > 32807 - Possible bug?

[psilospiral]

Greetings Forum:

I am running into an issue when trying to enter a Port Forward rule with a port number larger than 32807.  If I enter a port of 32808 or greater, OPNSense complains "The target port range must be an integer between 1 and 65535."  If I lower it back to 32807, the rule is accepted.  I must be missing something very obvious here... ??

[psilospiral]

Greetings again Forum:

I discovered the problem.  Attached is a slightly larger screen shot (opnsense-nat2.png) that provides the 'to:' port range under my 'Destination port range' configuration.  My 'from:' entry is 61713, but my 'to:' entry is HTTP.  This combination will throw the error "The target port range must be an integer between 1 and 65535" when in fact the target port range is indeed an integer between 1 and 65535.  This appears to be a bug.  Would somebody else please verify this behavior on their firewall?

Background:  I am coming from years of pfsense experience, where the web user interface has a slightly different approach with port forwarding.  In pfsense, the fields 'from:' and 'to:' default to 'other' with no numerical entry in a new NAT Port Forward entry.  (re: pfsense-nat-new.png)  Further, if no port range is required, the 'to:' entry can simply be left blank.  I have grown so accustom to creating port forwards with this workflow that the "must be an integer between 1 and 65535" error was throwing me off when the actual problem appears to be that the 'to:' and 'from:' port entries must match to forward a single port.  I played a guessing game with the port numbers to determine what integer it would finally accept, which provided no logical clue...

In OPNsense, the fields 'from:' and 'to:' default to 'HTTP' with no numerical entry in a new NAT Port Forward entry.  (re: opnsense-nat-new.png)  As a result, the HTTP must be changed to 'other' and then the port must be entered a second time into the 'to:' field.  If the 'to:' field is simply left at default, the user is incorrectly told that the port range is an incorrect integer from 1-65535, when in fact it likely is a valid port number.  The solution is to make the 'to;' field = the 'from:' field.