Regression #14616
closeddpinger does not start after renewing DHCP
100%
Description
Default install on 2.7
WAN is on VLAN 201 of vtnet0 (vtnet0.201) vtnet0 is not assigned.
LAN on vtnet1
Create a gateway group. WAN DHCP already present, add any other gateway for testing. I used LAN. WAN DCHP is Tier 1, LAN is Tier 2
Interfaces release DHCP on vtnet0.201
default route goest to vtnet1
Interface renew DHCP on vtnet0.201
gateway is created and green
no default route.
In 2.6 this issue could be mitigated by setup_gateways_monitor(); exec
In 2.7 the route won't come back until rebooting, or manually 'route del default' followed by setup_gateways_monitor(); exec.
I've been trying to figure this out for weeks. This bug really spells it all out, I just tried in a factory install to highlight the issue: https://redmine.pfsense.org/issues/14171
This is occurring in a Proxmox 8 VM with virtio interfaces. I was going to see if the issue relates to a VLAN on WAN, but I've run out of time.
Related issues
Updated by Kris Phillips over 1 year ago
Hello,
Is there no default route defined when you go to Diagnostics --> Routes?
Updated by Kyouko M over 1 year ago
You can edit the "/conf/config.xml" file under "<system>" and add a new line with "<route-debug></route-debug>" to get debug output under "System Logs" and on console.
More detailed information about editing can be found here: https://docs.netgate.com/pfsense/en/latest/config/xml-configuration-file.html
Updated by Maternal Pause over 1 year ago
Kris Phillips wrote in #note-1:
Hello,
Is there no default route defined when you go to Diagnostics --> Routes?
Thanks for the reply.
In the example from the original description, the default route seen under "Diagnostics --> Routes" will stay on LAN, vtnet1 until manually running 'route del default' followed by setup_gateways_monitor(); exec.
The "Diagnostics --> Routes" page was one of the primary locations I was observing the fault
Updated by Jim Pingle over 1 year ago
- Related to Bug #14634: The default gateway icon is not updated when the default gateway is changed to none added
Updated by Marcos M about 1 year ago
- Tracker changed from Bug to Regression
- Subject changed from 2.7 Multi-WAN Default Route not Created On Cut-over to dpinger does not start after renewing DHCP
- Category changed from Routing to Gateway Monitoring
- Affected Architecture All added
- Affected Architecture deleted (
amd64)
I was able to replicate this on 2.8 dev. The default gateway correctly switches to the tier 2 gateway when the DHCP lease is released, but it remains on tier 2 after renewing the lease. This can happen due to the dynamic gateway missing from config.xml; see #12920
dpinger will not start and the gateway status will remain pending after releasing/renewing the WAN DHCP lease
However, there seems to be a related regression. Now even with the dynamic gateway in config.xml, dpinger does not start after a DHCP renew and the gateway remains pending. This pending status is why the default gateway is simply not re-added (and remains on the old gateway in the case of multi-WAN). Further indication of this is that when the dynamic gateway has monitoring disabled (i.e. is forced online), a DHCP release/renew works as expected - that is, the default gateway returns.
Updated by Marcos M about 1 year ago
- Related to deleted (Bug #14634: The default gateway icon is not updated when the default gateway is changed to none)
Updated by Marcos M about 1 year ago
- Related to Bug #12920: Gateway behavior differs when the gateway does not exist in the configuration added
Updated by Marcos M about 1 year ago
- Status changed from New to Pull Request Review
- Assignee set to Marcos M
Updated by Marcos M about 1 year ago
- Related to Regression #11570: Gateway monitoring services is not always restarted on interface events, which may prevent a WAN from recovering back to an online state added
Updated by Marcos M about 1 year ago
- Status changed from Pull Request Review to Feedback
- % Done changed from 0 to 100
Applied in changeset c830f50da98b2f91f15163ed21d5b6086f10fc24.
Updated by Danilo Zrenjanin about 1 year ago
I was able to reproduce the reported issue on the 23.05.1 release.
Updated by Danilo Zrenjanin about 1 year ago
- Status changed from Feedback to Resolved
The same test works as expected against 23.09.b.20231018.0600.
I am marking this ticket resolved.