"
I am extremely optimistic that I have solved my problem so far. At the very least this reduced a lot of noise in the general log with DHCP renewal failures due to the way it was handling it before. It appears to be stable and definitely an improvement with the below. Anybody coming here after if you don't see me back here saying its still broken this likely fixed it. My ISP is Frontier FIOS in Texas in case somebody else is searching for this... Hope this helps somebody else!
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages1
#1
20.7 Legacy Series / Re: Loss of internet access and access to OPNSense
November 05, 2020, 04:02:05 PM #2
20.7 Legacy Series / Re: Loss of internet access and access to OPNSense
November 03, 2020, 12:44:34 AM
So I am optimistic that I've solved this and I want to update here in case somebody else comes looking for answers. If it doesn't work or still fails eventually I'll come back but based the behavior I'm seeing in my logs I'm feeling pretty good.
As I've done more digging around today and with a couple cut-outs from my connection I've started to identify more data points. I was noticing that when issues were occurring it was after multiple attempts to renew the DHCP address directly with the gateway of my ISP. This would keep going until it got to the point that the DHCP lease would expire and it would force dhclient to renew across the broadcast address instead of the gateway. When this happened, it would usually renew and go about its business. But there were occasions when it wouldn't renew seamlessly and an outage would appear. Interesting side note, I've been noticing random dropouts in my connection while on VoIP calls for work for a while now and I suspect it was caused by this. I discovered this because I started running a continuous ping in the background to 8.8.8.8 and saw random dropped packets and was able to correlate in the logs the DHCP lease expire.
So how do I think I fixed it? I found this: https://forum.netgate.com/topic/112869/dhclient-on-wan-occasionally-fails-to-renew-lease-with-cable-isp/3
The post is a little older and the custom compiling he did does not appear to be necessary. I was able to add the recommended option modifier for the DHCP client on my WAN interface and so far my DHCP renewals have been seemless as confirmed in logs and a tcpdump. Is this for sure fixed? No, not yet. But I have a high level of confidence that it is.
Very specifically, I went to Interface -> WAN -> Advanced (Under DHCP Client Config) -> and added the following to option modifiers at the bottom. Do NOT include a ';' as it is not required and will bork it. I found that out the hard way:
supersede dhcp-server-identifier 255.255.255.255
Hope this helps somebody else! I'll certainly be back if its not resolved!
As I've done more digging around today and with a couple cut-outs from my connection I've started to identify more data points. I was noticing that when issues were occurring it was after multiple attempts to renew the DHCP address directly with the gateway of my ISP. This would keep going until it got to the point that the DHCP lease would expire and it would force dhclient to renew across the broadcast address instead of the gateway. When this happened, it would usually renew and go about its business. But there were occasions when it wouldn't renew seamlessly and an outage would appear. Interesting side note, I've been noticing random dropouts in my connection while on VoIP calls for work for a while now and I suspect it was caused by this. I discovered this because I started running a continuous ping in the background to 8.8.8.8 and saw random dropped packets and was able to correlate in the logs the DHCP lease expire.
So how do I think I fixed it? I found this: https://forum.netgate.com/topic/112869/dhclient-on-wan-occasionally-fails-to-renew-lease-with-cable-isp/3
The post is a little older and the custom compiling he did does not appear to be necessary. I was able to add the recommended option modifier for the DHCP client on my WAN interface and so far my DHCP renewals have been seemless as confirmed in logs and a tcpdump. Is this for sure fixed? No, not yet. But I have a high level of confidence that it is.
Very specifically, I went to Interface -> WAN -> Advanced (Under DHCP Client Config) -> and added the following to option modifiers at the bottom. Do NOT include a ';' as it is not required and will bork it. I found that out the hard way:
supersede dhcp-server-identifier 255.255.255.255
Hope this helps somebody else! I'll certainly be back if its not resolved!
#3
20.7 Legacy Series / Re: Loss of internet access and access to OPNSense
November 02, 2020, 02:36:41 PM
This is still an issue, hoping someone else has come across this?
#4
20.7 Legacy Series / Re: Loss of internet access and access to OPNSense
October 21, 2020, 09:55:37 PM
I'm having the exact same issue. This github issue seems to capture it exactly. My logs for dhclient look exactly like this one. In particular, it seems dhclient is already running so it bombs without getting the renewal handled and assigned. It's very weird and very frustrating.
https://github.com/opnsense/core/issues/4017
https://github.com/opnsense/core/issues/4017
#5
17.7 Legacy Series / Re: Weird issue after power loss/restart
December 11, 2017, 06:19:36 PM
Well I feel like a doofus. It was an asymmetric route that I continuously overlooked because I insisted... to myself... that I didn't have one.
Hope this helps somebody else as stubborn as I was.
Hope this helps somebody else as stubborn as I was.
#6
17.7 Legacy Series / [SOLVED] Weird issue after power loss/restart
December 11, 2017, 07:40:59 AM
Hello!
I made the move to Opnsense from VyOS several months ago and haven't looked back. Since everything was set up it's all been working swimmingly. But for some reason after a power blip 2 days ago I have not been able to get NFS traffic working again between a client/server across VLANs. I've been over the rules so many times and everything looks fine. I've rebooted everything again to make sure something didn't load incorrectly, I've done system updates to both client/server as well as upgrading opnsense. I cannot see any reason why traffic should be getting hung up. But when I move the client to be on the same VLAN as the server therefore bypassing Opnsense it works just fine. When I put it back, it fails. Doing a tcpdump on the client shows what appears to maybe be a timeout on port 2049 but opnsense should be allowing that through from the rules. I have even modified the rule at this point to allow all traffic from the client to server regardless of the port and it still hangs up.
Is there any reason why this would've worked for months and suddenly quit after a reboot? Anybody have any suggestions of something I might be missing? Anything is greatly appreciated!
Thanks!
I made the move to Opnsense from VyOS several months ago and haven't looked back. Since everything was set up it's all been working swimmingly. But for some reason after a power blip 2 days ago I have not been able to get NFS traffic working again between a client/server across VLANs. I've been over the rules so many times and everything looks fine. I've rebooted everything again to make sure something didn't load incorrectly, I've done system updates to both client/server as well as upgrading opnsense. I cannot see any reason why traffic should be getting hung up. But when I move the client to be on the same VLAN as the server therefore bypassing Opnsense it works just fine. When I put it back, it fails. Doing a tcpdump on the client shows what appears to maybe be a timeout on port 2049 but opnsense should be allowing that through from the rules. I have even modified the rule at this point to allow all traffic from the client to server regardless of the port and it still hangs up.
Is there any reason why this would've worked for months and suddenly quit after a reboot? Anybody have any suggestions of something I might be missing? Anything is greatly appreciated!
Thanks!
Pages1
