1:1 with VIP(PARP) & LDAP - BUG?
-
So I ran into an issue for the first time when attempting to setup outside authentication via LDAP when using a Proxy ARP VIP. The following was my intial setup
1:1 NAT using ProxyARP VIP
Firewall Rule - Pass Only being sourced from specific subnets.First test resulted in a connection timeout from my remote server, with the following packet capture.
1 0.000000 x x TCP 74 53025 > ldap [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=3340573784 TSecr=0 WS=128
2 2.999165 x x TCP 74 53025 > ldap [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=3340574534 TSecr=0 WS=128
3 8.998985 x x TCP 74 53025 > ldap [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=3340576034 TSecr=0 WS=128
4 33.464469 x x TCP 74 53062 > ldap [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=3340582149 TSecr=0 WS=128
5 36.461137 x x TCP 74 53062 > ldap [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=3340582899 TSecr=0 WS=128So the troubleshooting process began:
- Removed Source IP requirement from the Firewall ( Knew this was more than likely not the cause but I tried it anyway ) FAILED
- Setup Port Forward using the WAN interface IP. SUCCESS
1 0.000000 x x TCP 74 54238 > ldap [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=3340835760 TSecr=0 WS=128
2 0.000406 x x TCP 78 ldap > 54238 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1So for a minute I was a bit dumbfounded. Why were all of my other services using 1:1 ProxyARP + Firewall Rules working but not LDAP. So on a whim I changed the VIP type to CARP and retested. Sure enough this resolved the problem.
Now according to pFSense here are the conditions for each VIP type:
CARP
Can be used by the firewall itself to run services or be forwarded
Generates Layer2 traffic for the VIP
Can be used for clustering (master firewall and standby failover firewall)
The VIP has to be in the same subnet as the real interface's IP
Will respond to ICMP ping if allowed by firewall rules.Proxy ARP
Can not be used by the firewall itself but can be forwarded
Generates Layer2 traffic for the VIP
The VIP can be in a different subnet than the real interface's IP
Will not respond to ICMP ping.The highlighted statements are the only possible differences that would apply to my situation. While I understand CARP has to be used for services like VPN etc, why would this have any affect on LDAP? Should I post this as a BUG or is this a case of ignorance?
Any feedback is appreciated!
-
Is the LDAP server running on the firewall itself?
-
No I'm simply using LDAP for authentication against AD which behind the firewall.
-
Still don't understand. Is the LDAP itself running on the pfSense server and that is passing it trough to the AD? It would seem to me that if your are not running the LDAP server on the FW itself that it should pass through LDAP traffic directly to the server. It is true that ProxyARP cannot be used for services on the FW.
I would check this article also.http://support.microsoft.com/kb/179442
If you don't like CARP, you can also use IP Alias.
-
Correct LDAP is not running on the FW. Also it appears no version of a VIP works by itself. In order for this to work I have to set up port forwarding using the WAN interface in conjunction with 1:1 NAT + VIP..
If I remove the single port forward all authentication attempts timeout, even though I'm not even using that IP to run LDAP authentication attempts against.
-
Are you creating the rules on the WAN when you setup 1:1? Cause port forward automatically creates the rule for you. This might be why its works when you have port forward enabled and not with 1:1. With 1:1 it is not enough to just create the VIP and the NAT, you have to have FW rules to allow the traffic. If you mimic the rules that are created with the port forward, you should be good.
-
I've gone over my config more times than I care to admit. Has to be bug, and I'll be leaving it here. I appreciate your input podilarius!
-
It's not a bug, what you're doing isn't uncommon, and there is no different treatment of 389 than any other port. What it is, hard to say from that description. My first guess is your firewall rule that's allowing traffic through the 1:1 is wrong, has to have the private IP as the destination.
-
joshcch, if you could screen shot the 1:1 rules and the WAN rules, perhaps we could help more. Do you have any custom LAN rules that might block?
-
Are you creating the rules on the WAN when you setup 1:1? Cause port forward automatically creates the rule for you. This might be why its works when you have port forward enabled and not with 1:1. With 1:1 it is not enough to just create the VIP and the NAT, you have to have FW rules to allow the traffic. If you mimic the rules that are created with the port forward, you should be good.
I actually create all my rules before setting up 1:1 to avoid this exact problem. I have a handful of other services using 1:1 and proper firewall rules with no problems except for LDAP.
WAN RULE EXAMPLE
Protocol: TCP Source:Alias_A Port:* Destination:Internal IP Destination Port:LDAP
All LAN rules are default. Again if it was a problem with the rule I'd notice it right away, because it's just a clone of my existing rules with the only change being the destination port.
::EDIT::
Setting up a new customer today and having the exact same problem except this time the work around isn't helping. Loading up Wireshark on the internal machine shows no packets matching LDAP. So it's clear NAT is working at all for this service. Any ideas?!
-
what is in alias_a?
-
Just a list of public networks in CIDR format that I want to allow LDAP user lookups from. And no removing the alias from the source IP in the firewall rule has no affect on the translation.
-
OP: Am I to understand you correctly that, you have some of these VIP-1:1 up and running correctly which were pre-existing, and your new one isn't working?
If so, which version/build of pfSense are you using? Were your previous ones setup on an earlier pfSense release?
-
In the 1:1 rule are you putting in a value for the Destination field?