Bug #12452
closedPort forward rules are not created for special networks (pppoe, openvpn)
100%
Description
https://forum.netgate.com/topic/167150/dns-redirect-on-pppoe-clients-failing:
"I have a pfSense server running sucessfully with approx 150 end user devices connecting via a dedicated interface on the pfSense configured for PPPoE. The PPPoE client IP address are issued to the end user devices from a radius server, all this which works fine and traffic is good. DNS servers are pushed to the end user devices via the radius server which again is all good.
However, I want to redirect all the PPPoE client DNS traffic to the pfSense server so that DNS requests are handled via the pfSense to help prevent end users circumventing our DNS servers.
I have followed the guide for this, setup DNS resolvers on the pfSense and applied this to the LAN interface (a seperate interface) and as expected this works a treat for the LAN users but I repeat this for the PPPoE interface and it doesn't seem to work for the PPPoE clients, it just ignores the NAT redirect rule and the traffic is sent to the DNS server that has been manually configured."
pfSense successfully creates redirect rules for interfaces, like:
# NAT Inbound Redirects rdr on vtnet0 inet proto { tcp udp } from any to !192.168.3.4 port 53 -> 192.168.3.4 # Reflection redirect rdr on { openvpn WireGuard } inet proto { tcp udp } from any to !192.168.3.4 port 53 -> 192.168.3.4 ... pass in quick on $LAN inet proto { tcp udp } from any to 192.168.3.4 port 53 tracker 1634138298 keep state label "USER_RULE: NAT "
but doesn't create rdr rules for PPPoE Server or OpenVPN groups:
pass in quick on $OpenVPN inet proto { tcp udp } from any to 192.168.3.4 port 53 tracker 1634138263 keep state label "USER_RULE: NAT " pass in quick on $pppoe inet proto { tcp udp } from any to 192.168.3.4 port 53 tracker 1634138088 keep state label "USER_RULE: NAT "
Updated by Marcos M about 3 years ago
This should be tested on 22.01 snapshots as something changed to fix the missing nat rules (see #11481) which may affect this scenario as well.
Updated by Viktor Gurov about 3 years ago
Updated by Viktor Gurov about 3 years ago
pfSense doesn't create rdr rules for special interfaces (openvpn, pppoe, ipsec) if destination = any
add extra checks and input validation:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/460
Updated by Jim Pingle about 3 years ago
- Status changed from New to Pull Request Review
- Assignee set to Viktor Gurov
- Target version set to 2.6.0
- Plus Target Version set to 22.01
Updated by Viktor Gurov about 3 years ago
- Status changed from Pull Request Review to Feedback
- % Done changed from 0 to 100
Applied in changeset 6a41d4769dfcdfebc2bf827f67b7ca52613d7223.
Updated by Max Leighton about 3 years ago
- Status changed from Feedback to Resolved
Tested in
2.6.0-DEVELOPMENT (amd64)
built on Sat Nov 20 06:21:37 UTC 2021
FreeBSD 12.3-PRERELEASE
Input validation now prevents me from creating a port forward with destination ANY on OpenVPN or PPPoE interfaces when Pure NAT (or NAT+proxy) is selected on the rule or set as the system default.
Saving the rule will result in the message:
"The following input errors were detected:
The submitted interface does not support the 'Any' destination type with enabled NAT reflection."
Marking the ticket resolved.
Updated by Jim Pingle almost 3 years ago
- Subject changed from Port Forward rules are not created for special nets (pppoe, openvpn) to Port forward rules are not created for special networks (pppoe, openvpn)
Updating subject for release notes.
Updated by Viktor Gurov almost 3 years ago
Updated by Jim Pingle almost 3 years ago
- Status changed from Resolved to Pull Request Review
Updated by Viktor Gurov almost 3 years ago
- Status changed from Pull Request Review to Feedback
Applied in changeset 7034ac0946c63f77708f28643f5efc8fb0fe96a1.
Updated by Alhusein Zawi almost 3 years ago
Input validation prevented me to create a port forward with destination ANY on all interfaces( WAN,LAN....) and all protocols(even ICMP) if I selected pure NAT or NAT+proxy
"The submitted interface does not support the 'Any' destination type with enabled NAT reflection"
2.6.0.b.20220107.0600
Updated by Viktor Gurov almost 3 years ago
- Status changed from Feedback to Resolved