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 18.104.22.168 on WAN and 22.214.171.124 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?
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?