ARP reply doesn't appear to make it back across Bridge



  • [New to both the forum and pfSense]
    We have a production ESXi (5.1) system configured with a TIER1 vSwitch with an uplink, and a TIER1_PRIVATE vSwitch with no uplinks:

    TIER1 is only connected to a pfSense (2.0.1-RELEASE amd64) Virtual Appliance.
    TIER1_PRIVATE is connected to a Linux VM and the pfSense Virtual Appliance.
    Within the pfSense Virtual Appliance, TIER1 and TIER1_PRIVATE interfaces are defined as BRIDGE1.
    (There are additional interfaces to other LANs on pfSense, but not used by this Linux VM)
    This configuration works fine.

    We are replicating this configuration in an upgrade Test, on ESXi (5.5) and pfSense 2.3.2-RELEASE (amd64):

    The configuration from the Production pfSense was exported, edited for subnet changes, then imported in the upgraded Test pfSense.
    In the Test configuration, we see ARP Requests (from the Linux-server to find its gateway) from TIER1_PRIVATE packet capture:
    <time-stamp-1>ARP, Request who-has <gateway>tell <linux-server>, length 46

    Packet capture on TIER1 also shows the ARP Requests, as well as ARP Reply from the switch with its MAC address:
    <time-stamp-2>ARP, Reply <gateway>is-at <mac-address>, length 46

    The ARP Replies are not seen in the packet capture on the TIER1_PRIVATE side of BRIDGE1, so our guest-server never gets network connectivity.
    I am able to get network connectivity by "moving" the Linux-server network-interface in vSphere from TIER1_PRIVATE to TIER1.
    Even moving the Linux-server back to TIER1_PRIVATE will work for some time, until it tries again to ARP the gateway, and lose connectivity.

    Did something change in pfSense from 2.0.1 to 2.3.2, which would block ARP replies?
    (I suspect a static entry is a possible workaround, but we would rather understand what is wrong here and resolve it)</mac-address></gateway></time-stamp-2></linux-server></gateway></time-stamp-1>



  • So we've put in static entries for the arp tables via /etc/ethers, as a temporary work around, in our RHEL 6.8 and 7.3 VMs.
    Is this configuration which works in pfSense 2.0.1 no longer supported in pfSense 2.3.2?


Log in to reply