Project

General

Profile

Actions

Bug #11734

open

NAT rule overlap detection is inconsistent

Added by Marcos Mendoza 4 months ago. Updated 14 days ago.

Status:
Pull Request Review
Priority:
Normal
Category:
Rules / NAT
Target version:
Start date:
03/26/2021
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
21.09
Release Notes:
Default
Affected Version:
2.5.x
Affected Architecture:
All

Description

When saving an additional NAT port forward rule:

  1. The "protocol" field is effectively ignored in overlap checks
  2. The "source" field is not checked in overlap checks
  3. Rule is prevented from being saved when a destination mask is defined

Related issues

Has duplicate Bug #12132: Port Fowards Using CARP VIP Form Validation on Source BrokenDuplicate07/15/2021

Actions
Actions #2

Updated by Jim Pingle 4 months ago

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

Actions #3

Updated by Marcos Mendoza 4 months ago

I've added some further details on it. At the least, there is a typo that should be fixed.

Actions #4

Updated by Jim Pingle 4 months ago

  • Status changed from Rejected to Pull Request Review
  • Target version set to CE-Next
Actions #5

Updated by Marcos Mendoza 2 months ago

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.

Actions #6

Updated by Jim Pingle 2 months ago

  • Plus Target Version set to 21.09
Actions #7

Updated by Renato Botelho about 1 month ago

  • Status changed from Pull Request Review to Feedback

PR has been merged. Thanks!

Actions #8

Updated by Marcos Mendoza about 1 month ago

  • % Done changed from 0 to 100
Actions #9

Updated by Marcos Mendoza 16 days ago

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.

Actions #10

Updated by Kris Phillips 15 days ago

Potentially related issue with source traffic with video demonstrating the issue: https://redmine.pfsense.org/issues/12132

Actions #11

Updated by Kris Phillips 15 days ago

Tested the changeset and the issue for 12132 and this redmine appears to be resolved.

Actions #13

Updated by Jim Pingle 14 days ago

  • Status changed from Feedback to Pull Request Review
Actions #14

Updated by Jim Pingle 14 days ago

  • Has duplicate Bug #12132: Port Fowards Using CARP VIP Form Validation on Source Broken added
Actions

Also available in: Atom PDF