Bug #11734
closedNAT rule overlap detection is inconsistent
Added by Marcos M over 5 years ago. Updated almost 5 years ago.
100%
Description
When saving an additional NAT port forward rule:
- The "protocol" field is effectively ignored in overlap checks
- The "source" field is not checked in overlap checks
- Rule is prevented from being saved when a destination mask is defined
MM Updated by Marcos M over 5 years ago Actions #1
- Assignee set to Marcos M
JP Updated by Jim Pingle over 5 years ago Actions #2
- Status changed from New to Rejected
Protocol doesn't overlap. You can have separate port forward rules for TCP and for UDP on the same port ranges which do not conflict.
Plus, that overlap check isn't for looking at network addresses, it's only making sure that port ranges do not overlap.
MM Updated by Marcos M over 5 years ago Actions #3
I've added some further details on it. At the least, there is a typo that should be fixed.
JP Updated by Jim Pingle over 5 years ago Actions #4
- Status changed from Rejected to Pull Request Review
- Target version set to CE-Next
MM Updated by Marcos M over 5 years ago Actions #5
Adding more details here; currently:
It's possible for rules with overlapping ports to be saved when the destination type is set to network because $natent['destination']['address'] can have a value of 10.0.0.0/24 while post['dst'] has a value of 10.0.0.0 (the mask is on a separate variable post['dstmask']).
There is a typo $natent['proto'], which means the != operator checks will always return true because null will never equal a defined variable. Hence, unless the protocol is set to TCP/UDP, the overlap check below this statement will never run.
JP Updated by Jim Pingle over 5 years ago Actions #6
- Plus Target Version set to 21.09
RB Updated by Renato Botelho about 5 years ago Actions #7
- Status changed from Pull Request Review to Feedback
PR has been merged. Thanks!
MM Updated by Marcos M about 5 years ago Actions #8
- % Done changed from 0 to 100
Applied in changeset commit:3736da7f0ffd73c0cd25b7118b3c4be2e1f0eab9.
MM Updated by Marcos M about 5 years ago Actions #9
There's still an issue when the selected source or destination is a special network (e.g. L2TP Clients), as well as a missing / in the checks. I have a fix ready to submit.
KP Updated by Kris Phillips about 5 years ago Actions #10
Potentially related issue with source traffic with video demonstrating the issue: https://redmine.pfsense.org/issues/12132
KP Updated by Kris Phillips about 5 years ago Actions #11
Tested the changeset and the issue for 12132 and this redmine appears to be resolved.
MM Updated by Marcos M about 5 years ago Actions #12
JP Updated by Jim Pingle about 5 years ago Actions #13
- Status changed from Feedback to Pull Request Review
JP Updated by Jim Pingle about 5 years ago Actions #14
- Has duplicate Bug #12132: Port Fowards Using CARP VIP Form Validation on Source Broken added
JP Updated by Jim Pingle about 5 years ago Actions #15
- Target version changed from CE-Next to 2.6.0
JP Updated by Jim Pingle about 5 years ago Actions #16
- Related to Bug #12361: NAT rule overlap detection does not check special networks added
JP Updated by Jim Pingle about 5 years ago Actions #17
- Status changed from Pull Request Review to Resolved
Marking resolved since the original part was already tested. I moved the special networks issue over to #12361 as it needs to wait until after 21.09.
JP Updated by Jim Pingle almost 5 years ago Actions #18
- Plus Target Version changed from 21.09 to 22.01
Also available in: Atom