WAN DHCP fails after 7 minutes 13 minutes later up again for 7 minutes (ARP)
-
Recently our WAN DHCP started to fail. The ISP provider renewed the (cable) modem but the problem persists. After some monitoring we noticed that it goes offline after 7 minutes and is getting back online 13 minutes later (see attachment). Because the default ARP cache timeout is 20 minutes in pfSense we figured out it had to be something with ARP.
- Adding an Arping in Cron is keeping it online. /usr/local/sbin/arping -A -c 1 -i <interface><gateway>- Changing the ARP cache timeout is also keeping it online. sysctl net.link.ether.inet.max_age=60
But what is happening and why do i have to make these changes to force it online?
</gateway></interface>
-
Is the gateway IP changing MACs frequently? Check 'arp -an' output, see if it changes.
-
MAC address today is the same as yesterday so i don't think it changes frequently. The pfSense keeps his ip address only the traffic is dead. It looks like the GW is forgetting the pfSense but i don't understand why.
-
You have anything in your system log " <mac address="">is using my IP <ip>"? Only circumstances I can recall where I've seen something that needy for ARP is an IP conflict. Granted, there could be one and you wouldn't see it, but it's worth checking. Sending arping frequently would help ensure you "win" an IP conflict.
A properly-functioning ISP router would issue an ARP request to you if its ARP cache entry timed out. There would never be a need to force traffic to it. But I've seen some stupid layer 2 things at times on cable networks, so it doesn't necessarily surprise me. I checked your profile to see if you happened to be in Canada by chance, seems their ISPs are usually the ones where we see layer 2 stupidity more than anywhere else. You're a long ways from there though. :)</ip></mac>
-
No, nothing like that in the log. We spoofed the WAN MAC address several times so the ip address changes but the problem persists. Don't think all ip addresses had an ip conflict.
ISP provider suggested last week to connect a Windows machine for the weekend (after replacing the modem again). The Windows machine kept his connection. Searching the net for Windows ARP cache timeout (15 to 45 seconds) made us decide to change the ARP cache timeout to 60 seconds on the pfSense.
Don't know if the problem started with this or with the replacement of the modem. New modem is a Ubee evw3226 UPC/Ziggo Netherlands. Old modem probably a Cisco. It's a private UPC/Ziggo connection (not a business connection). Modem is manually set to bridge mode. If the cable modem is set to router mode everything keeps working. Didn't monitor ARP request with that configuration.
This configuration is at a clients office. Our own office also uses a UPC/Ziggo (business) connection with a different modem (Hitron). Business connections are preset to Bridge mode and uses static IP. Our pfSense is working perfectly fine with UPC/Ziggo cable connection.
This isn't the first problem we had with UPC. Last year we had some issues with CARP and a Cisco EPC3925 modem at a clients office. Problem is still not resolved. Our Hitron modem seems to work fine with CARP. Maybe the problems resides with the modems (quality).
-
Yeah that definitely sounds like a case where the modem's weird (read: seriously messed up :)). You've tried everything I would have suggested to narrow down the issue.
Should be OK to keep things as is. Short of getting a diff modem, I don't think you have another option.
-
I have the opposite issue with my ISP. If I get my IP to change by changing my MAC, I will still receive traffic for my old IP including the old MAC until the DHCP lease ends, which is like a week.