Navigation

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

    CARP/HA Source IP for Authentication is interface IP instead of CARP IP.

    HA/CARP/VIPs
    3
    6
    570
    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.
    • S
      sthames42 last edited by

      On my LAN side:

      Primary  = .63.98
      Backup    = .63.126
      CARP VIP = .63.1

      I have a Radius server at .63.230. I can't set the interface to use for calls to the Authentication server so when the authentication request goes out to my radius server, the source IP is the device IP (.98 or .126) instead of the VIP .63.1. I solve this problem by adding an outbound NAT rule on the LAN interface to map the device IP to the VIP without port translation (static port).

      Is there a more appropriate way to do this? Are there any problems it might create?

      1 Reply Last reply Reply Quote 0
      • dotdash
        dotdash last edited by

        I usually just authorize the interface addresses for each firewall on the radius side. This means you can't sync the auth server from the primary to the backup, as the keys will be different.

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

          Thanks for responding.

          That's a solution, sure. And the sync isn't a problem since the server authenticates the client by Shared Secret. The ideal solution is to be able to set the interface to use but that isn't an option.

          My question is if anyone can think of any problems my solution will cause given all requests to the LAN from the routers will have the source IP of the CARP VIP.

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

            Ok, here I go answering my own question.  Bad idea!

            Using the outbound NAT for anything from the router broke dhcpd failover. The lease sync failed because the requests were blocked at the firewall by the default deny rule.

            So I guess I'll have to go with setting up two interfaces on the radius server.
            One more thing to have to remember.

            1 Reply Last reply Reply Quote 0
            • Derelict
              Derelict LAYER 8 Netgate last edited by

              If you properly limit the scope of the outbound NAT to just RADIUS ports, it shouldn't touch DHCP. Limit the Destination to .63.230 ports udp/1812-1813 for instance.

              But I would tend to be in the "add the LAN interfaces for both nodes as RADIUS clients on the server" camp.

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

                I agree, Derelict. I tend to be in that camp also.

                What I like about the NAT solution is it allows me to interchange a single router with an HA cluster without making changes to the rest of my network.

                Thank you for the answer on NAT.

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post

                Products

                • Platform Overview
                • TNSR
                • pfSense Plus
                • Appliances

                Services

                • Training
                • Professional Services

                Support

                • Subscription Plans
                • Contact Support
                • Product Lifecycle
                • Documentation

                News

                • Media Coverage
                • Press
                • Events

                Resources

                • Blog
                • FAQ
                • Find a Partner
                • Resource Library
                • Security Information

                Company

                • About Us
                • Careers
                • Partners
                • Contact Us
                • Legal
                Our Mission

                We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                Subscribe to our Newsletter

                Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                © 2021 Rubicon Communications, LLC | Privacy Policy