Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    1:1 with VIP(PARP) & LDAP - BUG?

    Scheduled Pinned Locked Moved HA/CARP/VIPs
    14 Posts 4 Posters 4.9k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • P
      podilarius
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • J
        joshcch
        last edited by

        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.

        1 Reply Last reply Reply Quote 0
        • P
          podilarius
          last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • J
            joshcch
            last edited by

            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!

            1 Reply Last reply Reply Quote 0
            • C
              cmb
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • P
                podilarius
                last edited by

                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?

                1 Reply Last reply Reply Quote 0
                • J
                  joshcch
                  last edited by

                  @podilarius:

                  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?!

                  1 Reply Last reply Reply Quote 0
                  • P
                    podilarius
                    last edited by

                    what is in alias_a?

                    1 Reply Last reply Reply Quote 0
                    • J
                      joshcch
                      last edited by

                      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.

                      1 Reply Last reply Reply Quote 0
                      • S
                        Sn3ak
                        last edited by

                        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?

                        1 Reply Last reply Reply Quote 0
                        • P
                          podilarius
                          last edited by

                          In the 1:1 rule are you putting in a value for the Destination field?

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.