NAT Port Forwarding DNS NTP - On Different VLANs and Subnets
-
Hello, can't seem to find a clear answer to these questions:
Context:
DNS:
a. Using DNS resolver in port forward mode via VPN gateways
b. Interfaces set for outgoing and listening
c. Have proper resolution and active interfaces are registering/hitting in firewall rules states/bytes. Though I do not know if all queries are going to pfSense first or straight out the gateway or a combination thereof, because of the config questions I'm not clear on)NTP:
a. NTP server enabled configured and syncing
Objective:
Trying to lockdown all VLANs to only use the pfSense DNS Resolver and NTP Servers. Ultimately will apply same configuration uniformly, to both NTP and DNS redirects and any other ports like them.
I understand how to do this if was only LAN interface, but confusion arises when wanting to do so for multiple VLANs on different subnets, that collectively use multiple VPN and WAN gateways.
Below are two variations of the firewall rule options for example/visualization:
Question 1: Source - Is it better/more functional/secure to have * (any) or the specific net e.g LAN net?
Question 2: Destination - 127.0.0.1 or LAN Address?
Question 3: For understanding - Is the "LAN address" the interface IP address and is that equal to or synonymous with 127.0.0.1 in pfSense?
Question 4: If using multiple VPN gateways with Multi-WAN, would a floating rule on the Gateway, apply to all interfaces and subnets that use that gateway?
(In effect, negating the need to apply the allow rules on individual interfaces)NAT:
Question 5: Does every VLAN interface with a NAT gateway, need to have the above two NAT Port Redirects individually per interface?
Question 6: Does the source * (any) inverted only apply to within the LAN subnet or does it somehow apply to VLANs on other subnets as well (even though they are supposed to be logically separated)?
Question 7: Overall, Is there a better way to accomplish the objective?
Really appreciate anyone who takes the time to answer and give expert advice with these questions, been trying to figure it out via researching for an excessive amount of time.
-
I did it this way: I created an interface group (Interfaces > Assignments > Interface groups) and added all internal interfaces to it.
Then I added a NAT port forwarding rule on this interface group for TCP/UDP, source any, destination IP any and port 53, redirect target localhost, port 53.
I did also the same for NTP.Additionally I blocked any access to port 853 (DoT) with a floating rule and DoH access is blocked by pfBlockerNG with proper lists.
Consider that the rules on an interface group is probed before ones on member interfaces and if one matches it is applied and other rule (on member interfaces) are ignored.
@rennit said in NAT Port Forwarding DNS NTP - On Different VLANs and Subnets:
Question 1: Source - Is it better/more functional/secure to have * (any) or the specific net e.g LAN net?
Any is commonly recommended to be used as source in block rules, while the respective subnet should be used in pass rules.
To obey this with an interface group rule you can create an networks alias and add all your local networks to it and state it as source.
But anyway, as long as you don't have an outbound NAT rule in place for other subnets, communication cannot happen.Question 2: Destination - 127.0.0.1 or LAN Address?
This is the localhost IP and the rule results from a NAT rule as mentioned above.
Question 3: For understanding - Is the "LAN address" the interface IP address and is that equal to or synonymous with 127.0.0.1 in pfSense?
No, but both are assigned to pfSense. If you forward traffic to the localhost the destination your need to state in the rule is 127.0.0.1. But usually you will pfSense let create the firewall rule itself by selecting "associated filter rule.
Question 4: If using multiple VPN gateways with Multi-WAN, would a floating rule on the Gateway, apply to all interfaces and subnets that use that gateway?
Yes, you can select multiple interface in a floating rule, so it is applied to all selected.
But you can achieve the same with an interface group rule.Question 5: Does every VLAN interface with a NAT gateway, need to have the above two NAT Port Redirects individually per interface?
Yes, or even do it with a floating or interface group rule.
Question 6: Does the source * (any) inverted only apply to within the LAN subnet or does it somehow apply to VLANs on other subnets as well (even though they are supposed to be logically separated)?
"any inverted"? That makes no sense at all.
But basically the the rules are only applied to the incoming interfaces they are added to, no matter which subnet.Question 7: Overall, Is there a better way to accomplish the objective?
I prefer what I described above.
-
@viragomann Awesome answer! I really appreciate you taking the time and attention to detail, to go through and answer each question. Very helpful!
Had thought of and actually made groups after posting, but the time limit for editing had run out when I tried to do so. Makes sense.
Q6: Apologize, I wasn't clear, I meant referencing the picture. Source any and inverted on LAN address. Should have specified.
Q2: What's been interesting in practice, is although all are on the same rule redirected to 127.0.0.1, some worked and redirected to 127.0.0.1 and others redirected to the static ip on the interface. Therefore those did not work with the firewall wall pass rule specifically for port 53 to 127.0.0.1. I.e. No DNS until 127.0.0.1 was changed to xyz interface address in the pass rule.
Prior to changing the pass rule, the interface static IP could be seen in the firewall logs as -p 53 blocked (from a lower separate block rule to 'this firewall') on many of the interfaces, so had to change the pass rule from single host/alias --> 127.0.0.1 to xyz 'address'. Then once change to just the xyz interface address, dns resumed and all worked again. No changes to the lower block rule.
Any ideas as to why the explicit redirect to 127.0.0.1 would lead to that result on some interfaces, but others redirected specifically to the static ip of the interface? Anything to do with resolver functionality?
edit: When I went back and didn't have it as an inverted rule, but rather * (any) for destination, it redirected to 127.0.0.1 as expected. I'll not delete and leave the above though, for anyone that might experience the same with the inverted rule.
Thank you again for your time and great detailed answer above!