Feature #4259
closed
Port forward NAT rules with "any" protocol
Added by Anonymous about 9 years ago. Updated almost 2 years ago.
100%
Description
Hello,
i'm starting to use pfsense inside my company network but i see that pfsense is missing a NAT ability compared to other product used on our production environment.
It would be nice to be able to create NAT rules with "any" as ip protocol. I don't mean bi-nat rules but simple destination or source nat rules without specify the ip protocol to use.
For example we should need to create destination nat rules dst_IP -> dst_IP for all ip protocols.
I checked on pf manual and i see that the protocol is optional. Is it correct?
Thank you
Related issues
Updated by Chris Buechler about 9 years ago
- Subject changed from NAT rules without ip protocol to Port forward NAT rules with "any" protocol
Updated by Ermal Luçi about 9 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset 9bbc482102d7a0a562a4368e9034e499651ac2e6.
Updated by Ermal Luçi about 9 years ago
Applied in changeset ebb9469d4e7ccb1986a4c17f1cdb44caf6bb6ad8.
Updated by Phillip Davis about 9 years ago
The fix "Use proper variable to do calculations" is actually the fix for #4529 - bit confusing there with the numbers just switched around.
Updated by Chris Buechler about 9 years ago
- Status changed from Feedback to New
- % Done changed from 100 to 0
Updated by Giuanin Piemunteis over 7 years ago
Could be it implemented with the new 2.4 release ?
Updated by Viktor Gurov almost 2 years ago
- Assignee set to Viktor Gurov
- Target version changed from Future to 2.7.0
- Plus Target Version set to 22.05
Updated by Jim Pingle almost 2 years ago
- Status changed from New to Pull Request Review
Updated by Viktor Gurov almost 2 years ago
- Status changed from Pull Request Review to Feedback
- % Done changed from 0 to 100
Applied in changeset 413ccc9447d65fed717c4bea565fb00a59ab62a9.
Updated by Alhusein Zawi almost 2 years ago
- Status changed from Feedback to Resolved
added
rdr on em0 inet from any to 10.100.100.127 -> 10.10.10.30
2.7.0.a.20220422.0600
Updated by Jim Pingle almost 2 years ago
- Status changed from Resolved to New
This is causing a PHP error:
strstr() expects at least 2 parameters, 1 given in /usr/local/pfSense/include/www/firewall_nat.inc on line 520 strstr() expects at least 2 parameters, 1 given in /usr/local/pfSense/include/www/firewall_nat.inc on line 521
Updated by Viktor Gurov almost 2 years ago
Jim Pingle wrote in #note-11:
This is causing a PHP error:
[...]
fix:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/752
Updated by Jim Pingle almost 2 years ago
- Status changed from New to Pull Request Review
Updated by Viktor Gurov almost 2 years ago
- Status changed from Pull Request Review to Feedback
Updated by Alhusein Zawi almost 2 years ago
Error:
There were error(s) loading the rules: /tmp/rules.debug:166: syntax error - The line in question reads [166]: pass in quick on $WAN reply-to ( em0 10.100.100.1 ) inet proto any from any to 10.10.10.30 ridentifier 1651948803 keep state label "id:1651948803" label "USER_RULE: NAT test_any_rule"
2.7.0.a.20220426.0600
Updated by Viktor Gurov almost 2 years ago
Alhusein Zawi wrote in #note-15:
Error:
There were error(s) loading the rules: /tmp/rules.debug:166: syntax error - The line in question reads [166]: pass in quick on $WAN reply-to ( em0 10.100.100.1 ) inet proto any from any to 10.10.10.30 ridentifier 1651948803 keep state label "id:1651948803" label "USER_RULE: NAT test_any_rule"
2.7.0.a.20220426.0600
You should test it on the latest snapshot (>20220428).
Updated by Alhusein Zawi almost 2 years ago
I am still seeing the same error
2.7.0.a.20220513.0600
There were error(s) loading the rules: /tmp/rules.debug:167: syntax error - The line in question reads [167]: pass in quick on $WAN reply-to ( em0 10.100.100.1 ) inet proto any from any to 10.10.10.30 ridentifier 1652551188 keep state label "id:1652551188" label "USER_RULE: NAT "
@ 2022-05-14 11:00:15
Updated by Jim Pingle almost 2 years ago
- Status changed from New to In Progress
- Assignee changed from Viktor Gurov to Jim Pingle
I can replicate the error here as well. It's failing to load the firewall rule because it has "proto any" where it should be omitted in that case. I found the test where it's falling through to that.
Updated by Jim Pingle almost 2 years ago
- Status changed from In Progress to Feedback
Applied in changeset 0a008d142f32a667e93c5aeba97938f7b71eff5b.
Updated by Viktor Gurov almost 2 years ago
- Related to Regression #13203: Floating rules without an interface are not loaded added
Updated by Danilo Zrenjanin almost 2 years ago
Tested:
2.7.0-DEVELOPMENT (amd64) built on Fri May 27 06:19:08 UTC 2022 FreeBSD 12.3-STABLE
No errors and the rdr rule works as expected. I am marking this ticket as resolved.
Updated by Danilo Zrenjanin almost 2 years ago
- Status changed from Feedback to Resolved