1:1 NAT reflection
-
First hi to all.
Now, i've done some fairly advanced things with pfSense so i don't consider myself novice but this situation is driving me crazy.
A customer needed to replace a aging, and failing Checkpoint with something else and naturally with covid and work from home vpn licenses were a big issue so the path forward was pfSense. The setup is, well, both simple and complex, depending from where you're starting. To sum it all up, the migration was a sucess and all works as expected except for one tiny thing, public DNS servers in DMZ.
Here the topology:
The problem is as follows... and please bear with me, I know there's split DNS and i used it frequently but this is something i inherited so here I am.
Both DNS01 and 02 can't talk to each other over their public IPs until I enable NAT reflection on both 1:1 mappings and enable outgoing nat for reflection, and that's fine, I get that, so that's enabled and now they both respond, well kind of, to queries. The problem starts when dns02 (slave) want's to update it's records from dns01 (master), it's rejected - ok at least traffic flows.
Now it's rejected because the master 112.82.112.164 (10.5.0.11) allows zone transfers to happen only from a public IP of slave which is 112.82.112.165 (10.5.0.12) and the bind log on the master says it rejected a zone transfer request from 10.5.0.1 - naturally because the config says so.
So i see there's NATin happening, also the pfctl -sn shows additional lines when you enable reflection and outgoing nat for it but it's using a pfSense interface address for that particular VLAN, so VLAN50 on pfSense is 10.5.0.1.I can clearly edit the bind configuration to allow transfers from local IPs it's just that apparently checkpoint handled it obviously differently and NATed it to public address.
Finally is this the intended pfSense implementation, to nat to it's interface or am I missing some additional steps, like some more NATing of pfSense itself
p.s. I'm far from DNS security whiz so maybe somebody has an idea as to why are transfer limited to only public IP addresses?!
-
@hb_nmedia What is the OS/software of the DNS servers? Often the DNS software config would dictate the master/slave IPs used, and maybe the slave can be set to connect to 10.5.0.11 directly.
If the slave was trying to connect to 10.5.0.11 directly it would not connect through the router. However since the slave is connecting to the .164 public IP the request is coming inbound through the router.
Using 1:1 NAT it does show the LAN IP of the router as the source. One can set firewall rules on that network to control it, something like:
on that VLAN:
allow from 10.5.0.12 to 112.82.112.164:53
block from 10.5.0.x network to 112.82.112.164:53Edit: using This Firewall doesn't work for these rules.
-
@steveits said in 1:1 NAT reflection:
@hb_nmedia What is the OS/software of the DNS servers? Often the DNS software config would dictate the master/slave IPs used, and maybe the slave can be set to connect to 10.5.0.11 directly.
it's Centos and the usual DNS package, meaning BIND, so it's named.conf and the corresponding zone text files and sure I can direct both master and slave to do transfers via local/private IPs but i was following Netgate documentation for accessing public resources from local network and came up with NAT reflection
If the slave was trying to connect to 10.5.0.11 directly it would not connect through the router. However since the slave is connecting to the .164 public IP the request is coming inbound through the router.
exactly what i need dns02 going out then back in to dns01 but with translated public IP, meaning 10.5.0.12->112.82.112.165
Using 1:1 NAT it does show the LAN IP of the router as the source. One can set firewall rules on that network to control it, something like:
on that VLAN:
allow from 10.5.0.12 to 112.82.112.164:53
block from 10.5.0.x network to 112.82.112.164:53the rules are in place and dns02 (10.5.0.12/112.82.112.165) can and must talk to all via udp 53 and additionally to 112.82.112.164 via tcp/udp 53
Edit: using This Firewall doesn't work for these rules.
so what you're saying 1:1 NAT reflection in this particular case wont work the way I need, meaning 10.5.0.12 outbound NATed to 112.82.112.165 and back to 112.82.112.164 inbound NATed to 10.5.0.11?
-
@hb_nmedia In my testing the reflection uses the LAN (or in your case VLAN) IP of pfSense. However access can be controlled by firewall rules on that LAN interface, to the WAN IP.
-
@steveits thanks Steve but I was wrong, or more likely misread and understood Netgate's usecase for reflection, well all would work until there's some filtering going on the destination host, which is the case with my scenario
Anyhow the issue is resolved with the assistance of reddit
To sum it up if anybody else comes with similar scenario:
Old checkpoint fw is bound neither to interfaces or direction, only source and destination, for all the rules, firewall and nat, so just 1:1 NAT on checkpoint did everything regardless of interfaces.
When i fully realized that and tsg-tsg mentioning 1:1 i added 1:1 on the specified VLAN interface and that’s it, and no reflection after that since that would again NAT everything to pfSense VLAN interface IP and stopped at dns01 named.conf because of allowed transfer hosts
anyhow this is pfctl exact rules
binat on bce3.40 inet from 10.5.0.11 to 10.5.0.12 → 112.82.112.164
binat on bce3.40 inet from 10.5.0.12 to 10.5.0.11 → 112.82.112.165