Navigation

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

    Virtual IP addresses not working?

    HA/CARP/VIPs
    2
    10
    8035
    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.
    • N
      netsysadmin last edited by

      Hello all,

      My setup is as follows:
        WAN interface IP: .19/28
        Virtual IPs of type IP Alias on WAN: .20/28 up to .30/28

      I was not sure whether to use a subnet mask of /32 or /28, but pfSense mentions that "This must be the network's subnet mask. It does not specify a CIDR range.".

      I am port forwarding public IP .20 ports 80, 8080 and 8086 to an internal private IP.
      NB: I've used one alias for all the ports 80, 8080 & 8086 in the port forwarding rule, ie, "Dest. ports" and "NAT Ports" fields are set to the alias name. Is this OK?

      Now, the problem is that when someone tries to access these ports from outside, the ports seem to be closed (I used yougetsignal.com to test).
      I did a packet capture on the WAN interface, but no interesting packet is seen.

      Strangely, if I change the Virtual IP "Type" from "IP Alias" to "Other", the ports seem to become open.
      However, after some time, they are again closed.

      Can anyone help please?

      Thanks in advance.

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

        For proxy-arps, use /32. I usually use alias vips for IP's that are not on the main subnet. Try using a CARP vip. Set the subnet mask to /28 to match the interface ip.

        1 Reply Last reply Reply Quote 0
        • N
          netsysadmin last edited by

          Thanks for replying.

          Any idea where I can find the exact differences between the different types of virtual IPs, ie, IP Alias vs CARP vs Proxy ARP vs Other?

          Why do you think I need to use "Proxy ARP"?

          The problem is that, as per the note at the bottom of the page, "Proxy ARP and Other type Virtual IPs cannot be bound to by anything running on the firewall, such as IPsec, OpenVPN, etc".

          By "main subnet", do you mean the WAN subnet?

          I'll try "Proxy ARP" and let you know if it works.

          Thanks.

          1 Reply Last reply Reply Quote 0
          • N
            netsysadmin last edited by

            Proxy ARP does not work.
            I tried putting it back to "IP Alias" and setting the subnet mask to /32 and it is working.
            But, as I mentioned before, I believe it will stop working after some time.

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

              The help from the vip page is pretty good: https://doc.pfsense.org/index.php/What_are_Virtual_IP_Addresses%3F
              Proxy-arps are easy, but I find CARP vips to be the most flexible.
              Yes, I meant WAN subnet by 'main'.
              If it stops working, that could be an upstream problem. But again, I would try with a CARP first if you have any issues.

              1 Reply Last reply Reply Quote 0
              • N
                netsysadmin last edited by

                Sorry for the late reply.

                I tried CARP, as you suggested, and again it works for a few minutes and then stops working again!

                Any clue what could be happening?

                Thanks

                1 Reply Last reply Reply Quote 0
                • N
                  netsysadmin last edited by

                  Proxy ARP and "Other" do not work at all.

                  1 Reply Last reply Reply Quote 0
                  • N
                    netsysadmin last edited by

                    I see messages like the following in the Systems >> General logs:
                    kernel: arp: XX:XX:XX:XX:XX:XX is using my IP address A.B.C.20 on re3_vlan77!

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

                      There is a device with the same IP address on it as your firewall. Check the first half of the mac address against the IEEE list of assignments and find out what manufacturer is conflicting with your IP.
                      A device with the same IP would cause the issues you are describing.

                      1 Reply Last reply Reply Quote 0
                      • N
                        netsysadmin last edited by

                        That was the problem.
                        However, it was actually a virtual IP address on the second pfSense box.
                        CARP was not configured yet.

                        Thank you.

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

                        Products

                        • Platform Overview
                        • TNSR
                        • pfSense
                        • 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