Bug #16806
open
DHCP client sends packets to the wrong interface with Multi-WAN
0%
Description
I have ix0 parent interface with 3 VLANs, one for each ISP: 10 (WAN), 20 (WAN2) and 30 (WAN3).
All ISPs use DHCP to assign IP addresses.
The issue is that pfSense often sends DHCP requests through the wrong interface.
For example, it sends packets from WAN2 IP address to WAN2's gateway, but using WAN interface (confirmed by doing packet capture both on the ix0.10 and on ix0 with VLAN 10).
Naturally, this causes DHCP issues on top of other unresolved DHCP client bugs I have been struggling with over the years.
Updated by Nazar Mokrynskyi 24 days ago
I narrowed it down to broadcast working correctly, while unicast not working correctly.
This it caused by dhclient not installing routes for `dhcp-server-identifier` returned by DHCP server when DHCP server and gateway are on different subnets.
As the result, unicast packets go through the default gateway instead of the correct interface.
I bet this is also fixed upstream like https://redmine.pfsense.org/issues/14604, but the version included in pfSense/FreeBSD is ancient and not spec-compliant.
Updated by Nazar Mokrynskyi 24 days ago
Updated by Marcos M about 7 hours ago
- Status changed from New to Incomplete
We haven't seen this issue in our testing yet. Additional troubleshooting is warranted to better understand what exactly is happening. If possible please detail steps to reproduce the issue between a pfSense server and pfSense client so we can look into it.
Updated by Nazar Mokrynskyi about 6 hours ago
I already explained what the issue is in the previous comment and even provided a pull request that fixes the issue.
What do you mean by "Status: Incomplete"???
All 3 ISPs I have exhibit this exact behavior: their gateways and DHCP servers are different machines on different subnets.
I imagine this is a very common thing in general.
Updated by Jim Pingle about 6 hours ago
We cannot reproduce this in lab or production conditions on any system. We cannot accept a change that could be potentially harmful to other configurations when we can't even reproduce the original problem.
When we packet capture DHCP requests and replies on Multi-WAN systems with more than one DHCP WAN, the expected addresses are used in all cases.
We need to know exactly how to reproduce this with a minimal configuration in lab conditions.
Updated by Nazar Mokrynskyi about 6 hours ago
Jim Pingle wrote in #note-5:
We cannot reproduce this in lab or production conditions on any system. We cannot accept a change that could be potentially harmful to other configurations when we can't even reproduce the original problem.
When we packet capture DHCP requests and replies on Multi-WAN systems with more than one DHCP WAN, the expected addresses are used in all cases.
We need to know exactly how to reproduce this with a minimal configuration in lab conditions.
Are your DHCP server and gateway on different subnets?
Please check PR, the changes there are fairly straightforward: it creates a new route for (previously ignored) `dhcp-server-identifier`.
It is obvious that without this explicit route the packet will not go to the correct interface (it will always go to the default gateway).