WAN dhclient (DHCP) issues - bug in time intervals?
-
Hmm. So if the client doesn't send those request options it never gets a lease?
-
@stephenw10 No, they require all the options, and they require the client to respect the RFCs around them (even though their own server does not respect the RFC).
Obviously all a play to make it increasingly harder to use any equipment but their own livebox equipment (which they do not allow to be placed in bridgemode). So no public IP on your own equipment unless you go through all these hoops to get your own box to behave like theirs.
-
So what happens if you don't send all the request option?
What happens if you request a shorter lease?
-
@nollipfsense said in WAN dhclient (DHCP) issues - bug in time intervals?:
It would help a great deal to disclose the ....
ISP ? Orange ?
Fibre ? ADSL ? Box used ?Never mind : it's encoded : "Livebox4" so Orange and probably ADSL.
Fiber needs a version 5 box. Or the "6", I've one. ( but I'm not planning to remove ISP Orange Livebox, imo to much of a hassle )For more support, I would advice you to dig into https://lafibre.info/
@stephenw10 said in WAN dhclient (DHCP) issues - bug in time intervals?:
Hmm. So if the client doesn't send those request options it never gets a lease?
Yep. DHCP is used to get the IPv4, DHCPv6 is used to get all the IPv6 info, and options are used to identify the 'box', and send authentication/identification.
Par example : https://lafibre.info/remplacer-livebox/durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire/ to mention just one.
No "help me" PM's please. Use the forum, the community will thank you.
Edit : and where are the logs ?? -
@gertjan Hi @Gertjan
Thanks for chiming in. Yes, the ISP is Orange and yes, I have read a million posts on lafibre.info (though that’s tough when google translate is your only option)
I have had it running for about a year and a half without issues, but this winter Orange started tightening up the DHCP RFC requirements on the DHCP exchange, and I stopped being able to renew my IP.
I’m on fibre, and I replaced a Livebox5 with my SG-2100 (and a 4100 for a while). I have a fs.com ONT SFP module inserted, and it works flawlessly (https://www.fs.com/de-en/products/133619.html)Love the no fuss of using the official appliances :-)
-
@gertjan Maybe I should mention I never had IPv6 working because the DHCPv6 client in pfSense does not support dhcp RAW options - at least in 22.05.
But I only need IPv4 at this stage as the site is tied into a v4 IPsec infrastructure in a country that has very limited/no v6 support/availability. -
@stephenw10 It takes a while to do fault finding because I have to wait about 24 hours for the problem to occur. Also I’m only first now on-site to do proper diagnosing.
Later today when it fails again I will have a packet capture of DHCP exchanges when the issue occurs.
From then on I can start testing workarounds and fixes. But mainly I’m interested in keeping as many of the settings they use in their own livebox as possible. I find it likely they will continue tightning the DHCP exchange to make it more and more difficult to use equipment other than the supplied but crappy livebox.
For now it’s a major advantage for me if I can have the IPv4 public IP on my pfSense WAN instead of doing double NAT and miss the ability to remotely contact the box directly (IPsec/management) -
@gertjan About lafibe.info:
Seems there is a huge userbase in France that uses Mikrotik equipment for replacing the Livebox.
There used to be quite a pfSense gathering as well, but they have all migrated to OPNSense because the DHCPv6 client in OPNsense is much more flexible and supports RAW options. There are a few that stayed on pfSense but hacked it by replacing the DHCPv6 client with the OPNSense binary - but that is not without issues…. -
@keyser said in WAN dhclient (DHCP) issues - bug in time intervals?:
Orange started tightening up the DHCP RFC requirements on the DHCP exchange, and I stopped being able to renew my IP.
What I make of it ( I'm not French at all, but I can read 'french' very well ) : people still manage to connect, but the rules are more strict.
@keyser said in WAN dhclient (DHCP) issues - bug in time intervals?:
because the DHCPv6 client in pfSense does not support dhcp RAW options - at least in 22.05
Create you own /root/att-rg-dhcpv6-pd.conf file : the dhcpd6 config file, and you have full control ;) You only need to know how to create such a file : you have to look up the options yourself.
That worked for me to obtain more then one prefix from my Livebox 6 (but still, the second was not operational, not routed).@keyser said in WAN dhclient (DHCP) issues - bug in time intervals?:
replacing the DHCPv6 client with the OPNSense binary - but that is not without issues
As long as the ABi or FreeBSD kernel version is the same, changes are create it works.
I'm not sure if it needs a "non standard" dhcpd6 client version.
You'll lose the full GUI control .... but we never had full GUI control anyway, just look at all the Ipv4 option for dhcp-client : if you need them, you have to implement them manually with options or go for the :
-
@gertjan & @stephenw10
Okay, I have learned i lot so far:- PfSense does respect the renewal timer and sends a request when the renewal interval expires.
But i accidentally created my packetcapture on WAN (which is mvneta0.832) instead of the RAW mvneta0 interface, so while the renewal requests were sent, I could not see if they were 802.1p priority 6 tagged as they should be.
I cannot find a way to manually attempt to renew the DHCP lease without releasing it first (which leads to a discover instead of a request).
The closest thing I found was “/sbin/dhclient -l /var/db/dhclient.lease.mvneta0.832 mvneta0.832”
That command does trigger a dhcprequest, but it is broadcast instead of unicasted to the DHCP server, and it is critically NOT 802.1p priority 6 tagged.So my main suspicion now is that while DHCP discover packets are 802.1p priority 6 tagged (because of “vlan.pcp 6” in modifiers), the lease renew packets are not. Which would explain why Orange ignores them.
This then leads me to a bug I discovered in the packet capture UI dialog of pfsense. I cannot create a capture with a protocol or port filter that captures VLAN tagged packets on the RAW interface. I can only capture VLAN tagged packets if I do not filter for anything.
That makes it “impossible” for me to capture the actual renewal attempt tomorrow and see if it is VLAN priority tagged. My only option is to calculate approximate renewal time and prevent any clients from talking in that period, and then manually capture everything, and hope the size is “workable”, so I get the actual renew attempt. -
Probably better running a pcap at the CLI for something like that. In 23.01 at least. 23.05 has a whole new interface to allow that.
Have you tried setting pcp 6 on the VLAN intself? That would send all traffic priority tagged but that probably doesn't matter.
Steve
-
@stephenw10 Okay, but how would the command line version of a tcpdump on mvneta0 look if it should filter so only UDP packets with ports 67/68 in use are captured (regardless of having VLAN tags on them)? My intial try shows the same behavior as the UI - standard filters ignores VLAN tagged frames.
-
I would try:
tcpdump -eni ix3 -c 1000 -U '((udp) and (port 67 or port 68)) or ((vlan and (udp) and (port 67 or port 68)))' -
@stephenw10 I’ll give it a spin. When done from the CLI, do I have to keep the SSH session open to avoid it being killed if I’m disconnected or my ssh client goes to sleep?
Or should I do at the console to allow it to run?
How do i stop a cli driven tcpdump?Love the no fuss of using the official appliances :-)
-
Okay - I’m still waiting for my first renew attempt after changing thing around, but it seems it’s VERY likely a missing COS6 tagging of DHCPv4 Renew frames that is the culprit.
I found this thread on OPNsense’s forum (i check there because OPNsense is used a lot more in france because they are quicker and more flexible with DHCP client issues and options):
https://forum.opnsense.org/index.php?topic=33376.0
Very clearly the same issue, and clearly a floating rule with a match to change the VLAN COS tagging on renew frames is the solution. I have just implemented my rule now, and tonight at renew time we will know if this is the same bug in the DHCP Client (which is now patched on OPNsense).
-
Hmm, well it will be interesting to see if that works. It 'feels' like there might be a separate dhclient option for the renews.
I'd also be interested in knowing if just setting the PCP tag on the VLAN fixes it. -
@stephenw10 said in WAN dhclient (DHCP) issues - bug in time intervals?:
Hmm, well it will be interesting to see if that works. It 'feels' like there might be a separate dhclient option for the renews.
I'd also be interested in knowing if just setting the PCP tag on the VLAN fixes it.So, after following the renew attempt last night and analyzing the packetcapture of the process, two things seems obvious:
1: The pfSense DHCP Client renews does not use and follow the "vlan-pcp 6" modifier that I have configured on WAN. Only Lease releases and DHCP discovery is priority tagged properly. Renew attempts are tagged with 0 = best effort. So I'm now 99,9% sure that's why I'm unable to renew my DHCP release. Orange clearly states it is required, and the OPNsense forum also shows lots of people with the same issue, that fixed it by priority tagging the renew process with priority 6.
2: My attempt at having a floating rule match and set the vlan priority 6 tag on renews did not work. Regardless of what I tried, no packets where ever matched with my attempted floating rule. I might not fully understand how to create the rule properly, but it seems quite simple, yet it didn't work. Is there a "loophole" where packets originating from an actual daemon on pfsense itself is not passed through the firewall rules?
I first created a match IPv4 rule with source "firewall (self)" UDP 68 to destination any port 67, and direction out on both the RAW and my vlan 832 tagged WAN interface. I set the match rule to apply VLAN priority tag 6. Didn't work.
I then opened the rule up with source any port any - didn't work
lastly I enabled Quick even though that should not be needed as I understand it - Didn't work.
Nothing was ever matched by by floating rule.Any idea if I'm doing it wrong?
Any idea's on how to get the DHCP client to respect the configured VLAN priority tag on renews as well? This should probably be considered an actual bug, so I'll create a redmine on that later today.
-
@stephenw10 said in WAN dhclient (DHCP) issues - bug in time intervals?:
Hmm, well it will be interesting to see if that works. It 'feels' like there might be a separate dhclient option for the renews.
I'd also be interested in knowing if just setting the PCP tag on the VLAN fixes it.Hmm loking at /tmp/rules.debug I’m suspecting my VLAN priority set is newer applied because the built-in web-configurator rules has a quick pass rule for dhcp requests out of WAN that are higher up in the rules.debug file that probably invalidates my match rule?
-
Yes if it's a 'quick' rule it will override anything below it so the match won't happen.
Setting the tag on the VLAN should apply to all traffic leaving it though so I'd expect that to work. -
@stephenw10 said in WAN dhclient (DHCP) issues - bug in time intervals?:
Yes if it's a 'quick' rule it will override anything below it so the match won't happen.
Setting the tag on the VLAN should apply to all traffic leaving it though so I'd expect that to work.Yeah But not really a good solution as the ISP severely throttles the amount of COS6 traffic allowed compared to the fibers actual throughput.
