After update from Aug 3 to Aug 5 two of my WAN-interfaces are down



  • I just upgraded from the August 3rd version which I installled from CD
    After the system rebooted I lost 2 of my WAN-interfaces and my systemlog is filled with "arpresolve: can't allocate llinfo for 192.168.168.1" and "arpresolve: can't allocate llinfo for 192.168.188.1"

    The 2 (from 4) WAN-interfaces that are down are both behind a NAT-router and have a fixed IP.
    The 2 WAN-interfaces that are still up have a real WAN-connection. One is DHCP and the other one has a static IP.

    I have a 2nd system that I need to build anyhow (as a spare device).
    I will install it with the August 3rd CD and load the XML it is running now.

    I didn't see any (significant) difference between the XML before the upgrade and after.
    I will report more after I have more info.



  • I have upgraded to 5 Aug on a nanoBSD system that has:

    • WAN with a real public static IP address directly connected to the ISP
    • OPT1 that uses a private little subnet with static IPs (like 10.49.17.1 to 10.49.17.2) to get to the LAN side of an ADSL router that is doing its normal home-style thing (NAT to a dynamic IP on the phone line).

    Both interfaces are up and working. The gateway monitoring is doing its thing and looks good. I use the Google addresses for gateway monitoring 8.8.8.8 on WAN and 8.8.4.4 on OPT1.

    So I don't think the 5 Aug build is particularly broken for these combinations. Must be something moere special about your configuration.



  • I've built my spare machine using the Aug 3rd CD, the one I also used to setup the other machine.
    Hardware is identical.
    I used the XML of yesterday evening, the one that has been running all night.

    It did the same thing.

    I was running it for a while and then 1 of the two NAT-connections came online.
    I decided to reboot some switches.
    The only thing that happened was losing that NAT-connection that came online.

    I still think it has got something to do with arptables in the switches.
    I don't understand why it happened after I upgraded this morning….
    AFAIK problems with ARP-tables should resolve within 2 minutes.

    I will continue to troubleshoot.

    My pfsense has indeed a special config.
    I have to turn off vlan hardware tagging to get my VLANs working.



  • After extensive testing and troubleshooting I came to the conclusion that the 2 NAT-routers are the culprit.
    Why exactly it happened after the upgrade I don't know, but I also have this problem if I switch the machine running pfsense.
    Just did a little test and it happened again.

    I have 2 identical Intel Atom D2500CC motherboards running the same config.
    If one machine breaks down or has some kind of other error I can quickly replace it with the other one.

    That's also the reason why I'm using a static IP configuration for the 2 NAT-routers.
    If I don't do this, the Fritzbox will give the other pfsense-machine another IP-address and all the portforwards will go wrong.

    It seems this "solution" gives me a new problem.
    Apparently the ARP-tables or something else in that Fritzbox is giving this other MAC a hard time.
    I'm still not a 100% sure of the reason, but I can quickly solve it by putting the pfsense interface into DHCP and then back into its static config.

    Maybe someone else can shed a light?

    BTW
    This thread has now become a bit off-topic as the upgrade wasn't the reason.
    My apologies for this.



  • Pfsense has CARP for running two boxes in failover.

    Instead of trying to reinvent the wheel, why not setup your two units the way pfsense was designed?


Locked