1:1 with VIP(PARP) & LDAP - BUG?
-
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?