Created WAN NAT but still seeing Default deny rule IPv4 (1000000103)

midnightfm

I am trying to open up the pfSense to allow LDAP/S to populate a user directory in our spam-filter as part of the email journaling process. I've already created the LDAP service account and I've created the NAT/WAN Rules in pfSense.

NATs:
Type: Port Forward
Enabled: Yes
Interface: WAN
Protocol: TCP
Source Address: The public IPs and IP ranges specified by the spam-filter company (there are multiple NATs, one for each host or range)
Source Ports: *
Dest. Address: The private IP of the domain controller
Dest. Ports: 636
NAT IP: The private IP of the domain controller
NAT Ports: 636

Rules:
Type: WAN
Enabled: Yes
Protocol: IPv4 TCP
Source: The public IPs and IP ranges specified by the spam-filter company (there are multiple rules, one for each host or range)
Port: *
Destination: The private IP of the domain controller
Port: 636
Gateway: *
Queue: none

In the spam-filter I entered the public IP of the domain controller as the LDAP host and 636 as the port. The test fails to connect and I can see in the pfSense logs that the traffic is being blocked by the Default deny rule IPv4 (1000000103), which I understand applies at the bottom of the rule list. I made sure the NATs and WAN Rules are enabled and the changes have been Applied, so I'm not sure why traffic is seemingly not being picked up by my NATs and Rules, when I can clearly see the source IP in the logs matches the IP in NAT/Rule.

Any help is appreciated. Thanks.

Aaron

viragomann

@midnightfm said in Created WAN NAT but still seeing Default deny rule IPv4 (1000000103):

In the spam-filter I entered the public IP of the domain controller as the LDAP host and 636 as the port.

Dest. Address: The private IP of the domain controller
Dest. Ports: 636

So the destination in the NAT rule has to be the public IP, not private.
in the filter rule, the you have to state the private IP (behind NAT) if you configure it manually.

NickD 0

@midnightfm On your NAT rule change the Dest. Address to the public IP you have chosen for your DC. If that is your firewall WAN address then use that or the built-in "WAN Address" alias. The firewall processes NAT before firewall rules so the NAT rule needs the public IP of the DC. This doc will help:

https://docs.netgate.com/pfsense/en/latest/nat/process-order.html

Also, you can change the Source Address in the NAT rule to be * ANY since your firewall rule is already restricted to the spam-filter source addresses. That will simplify troubleshooting and eliminate any ambiguity. You note in the NAT source address there are multiple NATs one for each host or range, if you change the source address NAT to * ANY then you only need the single NAT rule. Then you simply rely on your firewall rules to handle the filtering.

midnightfm

@NickD-0 I really appreciate your response. The change of the dest. address from private to public/WAN address makes sense to me since the NAT points to the private IP as the redirect anyway. I've also consolidated the NAT rules into a single NAT using "Source: * ANY" and then made sure to disable the WAN Rule that was automatically created.

So now I have a single NAT Port Forward using Source: * ANY, Dest: DC public IP, and Redirect: DC private IP, and several WAN Rules that route the spam-filter hosts/ranges to "WAN address" on 636, and I made sure to apply the changes.

I wish I could say that fixed my issue, but I'm still seeing the Default Block Rule being applied in the System Logs. I went back in and tried changing "WAN address" to the DC public IP, but same results.

I also ran netstat -aon | find "636" on the DC and confirmed nothing is listening.

Aaron

NickD 0

@midnightfm said in Created WAN NAT but still seeing Default deny rule IPv4 (1000000103):

and several WAN Rules that route the spam-filter hosts/ranges to "WAN address" on 636

You need to use the DC's private IP address for the WAN filtering rule as the destination. Recall for inbound WAN traffic the rule order is NAT then filter, so your inbound WAN filtering rules see packets with the DC private IP as the NAT rules already translated the packets.

I'm not sure why your DC doesn't have 636 listening but that's going to be an issue once you get the firewall squared away.

midnightfm

@NickD-0 thanks, I see the Barracuda spam-filter traffic in the logs being passed now.

I realized my choice of words regarding netstat was confusing. It's listening on 636; I should have said I wasn't seeing the spam-filter traffic when I run that command. Actually I'm still not and I'm still getting a "can't contact LDAP server" error in Barracuda, but it sounds like it may no longer be a firewall issue, so I'll raise a ticket with Barracuda.

Appreciate all the help and patience.

Aaron

NickD 0

@midnightfm Good to hear the firewall side is resolved. Sounds like you'll need to dig into some Windows event logs to diagnose the barracuda LDAPS issue. I'd expect to at least see failed connection and/or authentication attempts on the DC in the event logs.