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?