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

    Virtual IPs went temporarily down?

    Scheduled Pinned Locked Moved HA/CARP/VIPs
    3 Posts 2 Posters 2.4k 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.
    • M
      miguimon
      last edited by

      Hello all,

      After reading different posts on the forum / wiki I could not figure out this by myself so here I go.

      Environment:

      1x virtualized pfSense 2.0.1 (amd64) in a vSphere 5 cluster (one vSwitch with multiple port groups)
      2x Dell PowerConnect 8024F 10GbE with trunk VLANs: DMZ, FGOC, vMotion, NFS, Backup, Mgmt

      pfSense has four e1000 interfaces:

      WAN: xxx.xxx.34.49
      FGOC: 192.168.22.0 /24
      Mgmt: 10.19.1.0 /24
      Backup: 10.19.2.0 /24

      VIP (Proxy ARP) xxx.xxx.37.[175-182] is mapped to virtual machines on the FGOC network with NAT 1:1 and manual outbound for flexible rules. This set up is been working good since initial deployment but the other day I noticed the VIP range was not available for a certain period of time. I believe my range was the only one affected as I checked other IP's on the xxx.xxx.37.x /24 and no dramas there.

      Ping to the firewall WAN interface from out/in was ok. VM's were up and running but not accessible from the outside and no outbound ping to 8.8.8.8 or any other destination except internal networks.

      The problem disappear after going to NAT 1:1 , Outbound and Virtual IP and save the settings again.

      Would setting up a cron job to reload the filter (as mentioned in http://redmine.pfsense.org/issues/1493) avoid this in the future?

      Does anyone know what this could be related to or why?

      Thanks for your help.

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

        Reloading the filter definitely won't do anything. That's related to something at layer 2, possibly upstream. Rarely, some routers don't like proxy ARP, where IP aliases are fine. IP aliases have the benefit of letting you know when there is an IP conflict, something else taking over the upstream ARP cache by claiming those IPs is commonly the cause of issues like this.

        1 Reply Last reply Reply Quote 0
        • M
          miguimon
          last edited by

          Thanks for your answer cmb.

          I will consider switching to IP aliases. Seems the right move specially having the advantage of log notifications in case of IP conflict.

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