OPNsense Forum
Archive => 23.1 Legacy Series => Topic started by: skool on April 03, 2023, 07:55:47 pm
-
Hello,
Since ~10 days, without doing anything on the router, we are multiple opnsense/pfsense users having the same issue with Orange in France. Every ~24h, our internet connection drops on IPv4/IPv6.
On a IP point of view, on opnsense, all is good (routes, interfaces, etc…) but the gateway dont ping.
We need to manually restart dhclient (by unplug/replug cable, or restarting interface, or …)
I had done it yesterday at 18:40. just after that, my dhcp lease looked like that :
lease {
interface "vlan0.832";
fixed-address 83.202.25.xx;
next-server 80.10.234.173;
option subnet-mask 255.255.248.0;
option routers 83.202.24.1;
option domain-name-servers 80.10.246.1,81.253.149.9;
option host-name "opnsense";
option broadcast-address 83.202.31.255;
option dhcp-lease-time 604800;
option dhcp-message-type 5;
option dhcp-server-identifier 80.10.234.173;
option dhcp-renewal-time 84672;
option dhcp-rebinding-time 483840;
option dhcp-client-identifier 1:ac:84:c9:xx:xx:xx;
option option-90 0:0:0:0:0:0:0:0:0:0:0:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx;
option domain-search "MSR.access.orange-multimedia.net.";
option option-125 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx;
renew 1 2023/4/3 16:34:08;
rebind 2 2023/4/4 10:12:32;
expire 0 2023/4/9 17:02:56;
}
lease {
interface "vlan0.832";
fixed-address 83.202.25.xx;
next-server 80.10.234.173;
option subnet-mask 255.255.248.0;
option routers 83.202.24.1;
option domain-name-servers 80.10.246.1,81.253.149.9;
option host-name "opnsense";
option broadcast-address 83.202.31.255;
option dhcp-lease-time 604800;
option dhcp-message-type 5;
option dhcp-server-identifier 80.10.234.173;
option dhcp-renewal-time 84672;
option dhcp-rebinding-time 483840;
option dhcp-client-identifier 1:ac:84:c9:xx:xx:xx;
option option-90 0:0:0:0:0:0:0:0:0:0:0:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx;
option domain-search "MSR.access.orange-multimedia.net.";
option option-125 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx;
renew 1 2023/4/3 16:34:20;
rebind 2 2023/4/4 10:12:44;
expire 0 2023/4/9 17:03:08;
}
(dhcp lease is present twice on the file)
Today, my system.log contained this log lines :
<27>1 2023-04-03T18:54:37+02:00 opnsense.local dhclient 77948 - [meta sequenceId="1"] send_packet: No route to host
<27>1 2023-04-03T18:56:29+02:00 opnsense.local dhclient 77948 - [meta sequenceId="1"] send_packet: No route to host
<27>1 2023-04-03T18:56:57+02:00 opnsense.local dhclient 77948 - [meta sequenceId="2"] send_packet: No route to host
<27>1 2023-04-03T18:57:19+02:00 opnsense.local dhclient 77948 - [meta sequenceId="3"] send_packet: No route to host
<27>1 2023-04-03T18:57:50+02:00 opnsense.local dhclient 77948 - [meta sequenceId="4"] send_packet: No route to host
<27>1 2023-04-03T18:58:27+02:00 opnsense.local dhclient 77948 - [meta sequenceId="5"] send_packet: No route to host
<27>1 2023-04-03T18:59:10+02:00 opnsense.local dhclient 77948 - [meta sequenceId="6"] send_packet: No route to host
<27>1 2023-04-03T19:00:16+02:00 opnsense.local dhclient 77948 - [meta sequenceId="1"] send_packet: No route to host
<27>1 2023-04-03T19:02:32+02:00 opnsense.local dhclient 77948 - [meta sequenceId="1"] send_packet: No route to host
<27>1 2023-04-03T19:05:53+02:00 opnsense.local dhclient 77948 - [meta sequenceId="1"] send_packet: No route to host
<27>1 2023-04-03T19:12:47+02:00 opnsense.local dhclient 77948 - [meta sequenceId="1"] send_packet: No route to host
<27>1 2023-04-03T19:20:33+02:00 opnsense.local dhclient 77948 - [meta sequenceId="1"] send_packet: No route to host
<27>1 2023-04-03T19:30:19+02:00 opnsense.local dhclient 77948 - [meta sequenceId="1"] send_packet: No route to host
until I was back at home and restarted it, at 19:34 today.
Now, my lease file is
lease {
interface "vlan0.832";
fixed-address 83.202.25.xx;
next-server 80.10.234.173;
option subnet-mask 255.255.248.0;
option routers 83.202.24.1;
option domain-name-servers 80.10.246.1,81.253.149.9;
option host-name "opnsense";
option broadcast-address 83.202.31.255;
option dhcp-lease-time 604800;
option dhcp-message-type 5;
option dhcp-server-identifier 80.10.234.173;
option dhcp-renewal-time 84672;
option dhcp-rebinding-time 483840;
option dhcp-client-identifier 1:ac:84:c9:xx:xx:xx;
option option-90 0:0:0:0:0:0:0:0:0:0:0:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx;
option domain-search "MSR.access.orange-multimedia.net.";
option option-125 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx;
renew 1 2023/4/3 16:34:20;
rebind 2 2023/4/4 10:12:44;
expire 0 2023/4/9 17:03:08;
}
lease {
interface "vlan0.832";
fixed-address 83.202.25.xx;
next-server 80.10.234.173;
option subnet-mask 255.255.248.0;
option routers 83.202.24.1;
option domain-name-servers 80.10.246.1,81.253.149.9;
option host-name "opnsense";
option broadcast-address 83.202.31.255;
option dhcp-lease-time 604800;
option dhcp-message-type 5;
option dhcp-server-identifier 80.10.234.173;
option dhcp-renewal-time 70604;
option dhcp-rebinding-time 483840;
option dhcp-client-identifier 1:ac:84:c9:xx:xx:xx;
option option-90 0:0:0:0:0:0:0:0:0:0:0:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx;
option domain-search "MSR.access.orange-multimedia.net.";
option option-125 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx;
renew 2 2023/4/4 13:10:56;
rebind 3 2023/4/5 03:53:29;
expire 1 2023/4/10 17:34:12;
}
I dont know where to look at to debug what happened.
If someone having an idea…
Many thanks :)
-
Today, when my DHCP lease expired, I removed /var/db/dhclient.lease file before renewing IP
To renew, I used GUI, ask for a release before a renew.
And now, the dhclient.lease file contains only 1 lease that seems correct.
I will see tomorrow at 17:15 if something changes.
-
And tomorrow, same issue…
As I see on /var/db/dhclient.leases… the client added a 2nd lease when manually renew.
That's my new dhclient.lease file :
lease {
interface "vlan0.832";
fixed-address 83.202.25.xx;
next-server 80.10.234.173;
option subnet-mask 255.255.248.0;
option routers 83.202.24.1;
option domain-name-servers 80.10.246.1,81.253.149.9;
option host-name "opnsense";
option broadcast-address 83.202.31.255;
option dhcp-lease-time 604800;
option dhcp-message-type 5;
option dhcp-server-identifier 80.10.234.173;
option dhcp-renewal-time 93695;
option dhcp-rebinding-time 483840;
option dhcp-client-identifier 1:ac:84:c9:da:93:40;
option option-90 0:0:0:0:0:0:0:0:0:0:0:xxxxxxxxxxxxx;
option domain-search "MSR.access.orange-multimedia.net.";
option option-125 0:0:5xxxxxxxxx;
renew 3 2023/4/5 15:15:14;
rebind 4 2023/4/6 10:46:20;
expire 2 2023/4/11 13:13:39;
}
lease {
interface "vlan0.832";
fixed-address 83.202.25.xx;
next-server 80.10.234.173;
option subnet-mask 255.255.248.0;
option routers 83.202.24.1;
option domain-name-servers 80.10.246.1,81.253.149.9;
option host-name "opnsense";
option broadcast-address 83.202.31.255;
option dhcp-lease-time 604800;
option dhcp-message-type 5;
option dhcp-server-identifier 80.10.234.173;
option dhcp-renewal-time 88197;
option dhcp-rebinding-time 483840;
option dhcp-client-identifier 1:ac:84:c9:da:93:40;
option option-90 0:0:0:0:0:0:0:0:0:0:0:xxxxxxxxxxxxx;
option domain-search "MSR.access.orange-multimedia.net.";
option option-125 0:0:5xxxxxxxxx;
renew 4 2023/4/6 16:12:39;
rebind 5 2023/4/7 10:35:05;
expire 3 2023/4/12 15:42:42;
}
The two leases are exactly the same except the renew dates and renewal times.
Is there a way to enable more verbose on dhclient, to see what Orange answers when we made a dhclient query ?
And is it normal to have 2 leases on the file ?
-
Yes lots of people with this issue. I have been okay until yesterday when I lost my connection
It may not be the same issue as it’s less than 24 hours since I rebooted the router. Time will tell
I think something has changed at Orange as like you I didn’t change anything
@franco which logs should we capture
-
Confirming my connection no longer renews I’m on 23.1.5_4
The french forum suggest that this issue is not present in 22.7
Is there an easy way to revert so I can test
-
Seems the issue has appeared since 23.1.3_4-amd64
People on that version are ok
What is the process to revert, is this the correct syntax
opnsense-revert -r 23.1.3 opnsense
-
Same issue for me, it seems the dhclient is not renewing the IPv4 once the lease has expired.
-
If it helps for debugging, I started a packet capture of all DHCP (v4 and v6) trames.
I see the initial query and answer, but on the packets, all seems to be correct.
-
I have reverted to 23.1.3
Lets see if the renewal works
-
I'm not sure we have substantial changes here, especially when pfSense users are reporting the same problem.
I'm not at the office this week. Not sure how to proceed as well. Even packet captures might be useless if the other side simply refuses to respond. In that case a packet capture from their router would be the only choice...
Cheers,
Franco
-
I’m not back in France for a few months
I’m connecting to the router over VPN so can’t swap the livebox in to test
@skool & @sisyphe are you able to connect the livebox and capture the packets at renewal
-
Hi,
I looked at what happened when renew tested, having an eye on lease file and on packet capture.
Before renewing, I had a lease file with 2 blocs, identical except dates. One lease had a renew date at this morning, a second at 13:35:30 UTC
On my capture, before 13:35:30 UTC, nothing else that the initial dhcp request yesterday. No packet were sent or received (that seems normal)
Today at 13:35:30 UTC exactly, I see a dhcp request sent to the previous DHCP server, but no response. This packet is resent every ~10s, but no response.
At this time, the lease file didnt change.
On the GUI, i clicked on the Renew button (without trying to release before), and I see 3 dhcp packets sent to broadcast. The 2 first are flagged as DHCP Requests by Wireshark, the 3rd is a « DHCP Discover », and after this 3rd packet, I see a response from my ISP with a « DHCP Offer » packet.
I see a final exchange between my router and the dhcp server before my connection goes UP again.
Between 13:35:30 UTC and the last dhcp response, my internet acces was down.
On the lease file, when I clicked on the renew button, the first lease disappeared (the one with a renew date at this morning), and after the final dhcp exchange, I now have 2 leases : the one that was renewed today, and a new one with a renew date for tomorrow.
So, my first supposition is wrong. the client is sending a DHCP request when needed, the problem seems that the DHCP server dont received/answered to it.
@nivek1612: I dont have harware to capture the renew packets between the livebox and Orange dhcp server.
edit: I re-read what the Orange guy said on the french forum, the DHCP on v4 need to follow the lifecycle DORA, and as I understand, it's a « discover, offer, request, ack »
it's what I viewed on the capture when manually renewed my IP
but the automatic way is only a Request, not preceded by the discovery/offer exchange.
my new suppositition is :
- Orange see a first dhcp request for the renew
- it's not what expected (he want a Discover)
- Orange drop the connection
- when renewing manually, we respect the DORA lifecycle, all back to normal
it's the same thing on DHCPv6. the first requests was DHCP Renew, not Solicit, but when we manually renew, it send a solicit, receives an Advertisement, send a Request, and receive a Reply (SARR lifecycle)
edit2:
following man page of dhclient, it's normal it keeps all dhcp leases that are not expired.
if I unplug/replug the cable, the old lease is kept, but as it's not correctly renewed, a new one is requested, it's why we have 2 leases on the db file.
-
So, after reading some docs, I suppose the DORA cycle is not a problem.
But maybe the vlan-pcp option is not correctly used on renew packets. It's mandatory for Orange to set a priority of 6 on every requests.
My capture is made before vlan tagging, so I cant see if it's set or not.
But I can confirm that the initial DHCP packet is correctly tagged with a priority of 6. the default vlan priority is set to 0.
Edit: I added a pf rule to set priority to 6 for all dhcp outgoing queries, to see if it changes something…
-
Looking forward to seeing the outcome of you tests. Being remote I can’t play around too much
-
I confirm that adding a firewall rule to re-tag priority to 6 for DHCP packets (outgoing UDP packets to 67 and 546, ipv4 and ipv6) fix the issue.
As I read on other forum, it seems this problem is also present on Mikrotik equipment, that probably use the same dhclient app.
So the bug is that dhclient dont use vlan-pcp 6 when renewing a lease.
I dont know if someone is possible on opnsense side or if we need to check with dhclient team.
-
Nice work.
I have set a similar rule and I'm now waiting for the renewal 12 pm tomorrow to confirm.
I worked on the original DHCP and DHCPv6 cos 6 tagging with @marjohn. I seem to remember that the firewall rule would not set the cos for dhcpv6 traffic so if this is working ORANGE must only be checking the DHCP call. Did you capture the packets?
Have you also checked your speed is not reduced after renewal?
-
Have you also checked your speed is not reduced after renewal?
No issue regarding network speed. It's still at the max I always had.
-
I think I've found what's happen on dhclient, but I'm definitively not able to try to fix something on a 10 year C code probably used by a lot of routers.
OPNsense use the FreeBSD dhclient.
This client uses BPF features : https://man.freebsd.org/cgi/man.cgi?query=bpf&sektion=4&manpath=FreeBSD (https://man.freebsd.org/cgi/man.cgi?query=bpf&sektion=4&manpath=FreeBSD)
source code is available here : https://cgit.freebsd.org/src/tree/sbin/dhclient/bpf.c (https://cgit.freebsd.org/src/tree/sbin/dhclient/bpf.c)
When dhclient starts, it creates a bpf device that set the vlan priority if needed : https://cgit.freebsd.org/src/tree/sbin/dhclient/bpf.c#n96 (https://cgit.freebsd.org/src/tree/sbin/dhclient/bpf.c#n96)
It also creates a simple socket for unicast usages.
And when dhclient need to send a packet, depending on the target, it uses the bpf tagged one or a simple socket
https://cgit.freebsd.org/src/tree/sbin/dhclient/bpf.c#n376 (https://cgit.freebsd.org/src/tree/sbin/dhclient/bpf.c#n376)
(the interface->wfdesc is the bpf one, the interface-ufdesk is a simple socket)
I dont know why it works like that, but it explain that the vlan priority is not set when sending an unicast packet.
-
well adding the firewall rule has allowed me to keep my connection 24 hrs later so we have a workaround pending a patch
-
Perhaps something like this as a POC? https://github.com/opnsense/core/commit/d08a425759190
# opnsense-patch d08a425759190
Assuming IPv6 is set up correctly as well. I take it nowadays you guys have to set vlan-pcp value in advanced DHCPv4 settings?
Either we have to parse them or add a field back to the GUI.
Cheers,
Franco
-
PS: I guess Orange "fixed the glitch" that existed for a few years on their end. It seems to prove the point that the restriction is quite arbitrary if they didn't catch that for all these years... It should have never worked without this on their end -- perhaps they just drop "faulty" packets using a firewall rule?
-
They have been cleaning things up over the last few months and migrating people to the new config
But at least now they are telling the world what they need so we can be sure.
I’m unsure about ipv6 on renew as I remember when marjohn worked on it with me we couldn’t change the dhcp6c request in the firewall but I can’t remember why
My assumption is that for now they are only checking the dhcpv4 request but for how long
Skool May be able to capture the packets to confirm
-
Skool May be able to capture the packets to confirm
When capturing trafic from the GUI, there is no vlan information. (maybe we can add something like `-e vlan` on tcpdump)
I missed my today's renew to test the patch, I will try it tomorrow.
About IPv6, maybe the existing rule already works : https://github.com/opnsense/core/blob/master/src/etc/inc/filter.lib.inc#L371 (https://github.com/opnsense/core/blob/master/src/etc/inc/filter.lib.inc#L371)
Edit: I disabled my rule, applied the patch and I can see these rules on pfctl -sr
pass out log quick on vlan0.832 proto udp from any port = dhcpv6-client to any port = dhcpv6-server set ( prio 6 ) keep state label "af991f951c9d5dd7679e1defbf9ee033"
pass out log on vlan0.832 proto udp from any port = bootpc to any port = bootps set ( prio 6 ) keep state label "ef42d12f986749549ec90dcd3d0e3521"
so it looks good. I will confirm it tomorrow.
-
Yes, for now let's assume the IPv6 rule works as is and do the same for IPv4. :)
I just need confirmation for the 'adv_dhcp_send_options' used for DHCP IPv4 -- I'm assuming vlan-pcp is set there (to the same value as IPv6 priority).
Cheers,
Franco
-
I just need confirmation for the 'adv_dhcp_send_options' used for DHCP IPv4 -- I'm assuming vlan-pcp is set there (to the same value as IPv6 priority).
Not sure to understand, but on my setup, I added `vlan-pcp 6` on DHCPv4 `Option Modifiers`field on the GUI.
-
Looking at Franco's code it seems that the prio on DHCPv4 will be set from the prio configured for DHCPv6 with the proposed patch:
if (isset($intfinfo['dhcp6vlanprio'])) {
$dhcpv4_opts['set-prio'] = $intfinfo['dhcp6vlanprio'];
}
If that works, it will be good to have a prio field in the UI like the "Use VLAN priority" drop-down for DHCPv6. Alternatively it should be possible to parse the DHCPv4 "Option Modifiers" field as we used it to set prio with value 'vlan-pcp 6' for Orange FR.
Thanks.
-
updated to latest version (I had rolled back to test)
applied patch and removed firewall rule
Need to wait 24 hours now for renewal
-
Hello,
My DHCP renew didnt worked today, with the patch.
I tried to capture the packets with vlan informations but my tcpdump filter was not correct.
I will made other tests with tcpdump and try to capture my renewal tomorrow.
edit: it seems that this tcpdump command works to capture dhcp packets with vlan informations
/usr/sbin/tcpdump -i igb5 -n -U -w test_dhcp.pcap -c 100 -e vlan and ip and port 67 and udp
I need to capture on the main interface (igb5 for me) not on vlan0.832
-
If you share the filters I can also do a capture
My renewal is at noon tomorrow
-
something interesting
without the patch :
root@opnsense:~ # pfctl -sr | grep vlan0.832 | grep "pass out"
pass out log quick on vlan0.832 proto udp from any port = dhcpv6-client to any port = dhcpv6-server set ( prio 6 ) keep state label "af991f951c9d5dd7679e1defbf9ee033"
pass out log on vlan0.832 proto udp from any port = bootpc to any port = bootps keep state label "b8e1da9ac60ce8edb8e5a84bc5cec53e"
pass out log route-to (vlan0.832 83.202.24.1) inet from (vlan0.832) to ! (vlan0.832:network) flags S/SA keep state allow-opts label "6790f631ba77b3835a88204bb2162f65"
and with the patch
root@opnsense:~ # pfctl -sr | grep vlan0.832 | grep "pass out"
pass out log quick on vlan0.832 proto udp from any port = dhcpv6-client to any port = dhcpv6-server set ( prio 6 ) keep state label "af991f951c9d5dd7679e1defbf9ee033"
pass out log on vlan0.832 proto udp from any port = bootpc to any port = bootps set ( prio 6 ) keep state label "ef42d12f986749549ec90dcd3d0e3521"
pass out log route-to (vlan0.832 83.202.24.1) inet from (vlan0.832) to ! (vlan0.832:network) flags S/SA keep state allow-opts label "6790f631ba77b3835a88204bb2162f65"
I can see the patch correctly set the prio to 6 on the default rule
but it's not a quick rule, maybe another one interfer.
-
If you share the filters I can also do a capture
My renewal is at noon tomorrow
Seems it's not possible from the GUI,
but on SSH, you can try it :
/usr/sbin/tcpdump -i igb5 -n -U -w test_dhcp.pcap -c 100 -e vlan and ip and port 67 and udp
replacing igb5 by the main public interface (not the vlan interface)
Note: I just done lot of tests, and it seems that priority set by PF rule is not shown on the capture… I seen a renew using priority 0 but correctly answered (without a rule, it breaks the connection).
-
So the patch doesn’t work but the firewall rule does
-
but it's not a quick rule, maybe another one interfer.
Nice catch. Let's change it to mimic IPv6 behaviour:
https://github.com/opnsense/core/commit/3ed4f6d2
# opnsense-revert opnsense && opnsense-patch d08a425759190 3ed4f6d2
And sorry, I said "adv_dhcp_send_options" but I meant "adv_dhcp_option_modifiers". Just got back home to a useful computer ;)
Cheers,
Franco
-
Cheers Franco
still not seeing quick in the output should we?
root@home:~ # pfctl -sr | grep igb0_vlan832 | grep "pass out"
pass out log quick on igb0_vlan832 proto udp from any port = dhcpv6-client to any port = dhcpv6-server set ( prio 6 ) keep state label "af991f951c9d5dd7679e1defbf9ee033"
pass out log on igb0_vlan832 proto udp from any port = bootpc to any port = bootps set ( prio 6 ) keep state label "ef42d12f986749549ec90dcd3d0e3521"
pass out log route-to (igb0_vlan832 x.x.x.x) inet from (igb0_vlan832) to ! (igb0_vlan832:network) flags S/SA keep state allow-opts label "0706ba41b95e2917cd5e0c8c641862d1"
-
Can you reload firewall filter?
Cheers,
Franco
-
that did it
root@home:~ # pfctl -sr | grep igb0_vlan832 | grep "pass out"
pass out log quick on igb0_vlan832 proto udp from any port = dhcpv6-client to any port = dhcpv6-server set ( prio 6 ) keep state label "af991f951c9d5dd7679e1defbf9ee033"
pass out log quick on igb0_vlan832 proto udp from any port = bootpc to any port = bootps set ( prio 6 ) keep state label "1379874b63290e4ce50d44de5cd544e5"
pass out log route-to (igb0_vlan832 x.x.x.x) inet from (igb0_vlan832) to ! (igb0_vlan832:network) flags S/SA keep state allow-opts label "0706ba41b95e2917cd5e0c8c641862d1"
root@home:~ #
-
just to say, I tested lot of cases, and as I seen, the vlan-pcap option is still mandatory even if I have a firewall rule.
maybe because the broadcasted packages uses a custom bpf filter that breaks the « set priority » option on a rule.
I'm waiting for tomorrow with the latest patch.
but if it works, I suppose that a good thing would be to have a « vlan priority » on dhcpv4 like on dhcpv6, that sets « vlan-pcp » on dhclient config file and update the automatic rule.
thanks all for your help on this issue, I definitively like opnsense team and community :)
-
we sort of have that already with option modifers
-
we sort of have that already with option modifers
yes, but it's not so user friendly, and if we need to generate a pf rule, it will be easier with the same field that already exists for ipv6
easy to develop, easy to use, sounds good to me :)
-
Yep, I just have to check if double setting of vlan-pcp doesn't cause an error in dhclient and of course Orange users will have to make the switch to the new setting, but we can document in the release notes and probably spread the information to other forums.
Cheers,
Franco
-
24 hours later and I'm still connected
Looking good.
-
Neat, here is the official PR, but still working on it: https://github.com/opnsense/core/pull/6485
To test:
# opnsense-revert opnsense && opnsense-patch 2e4a1ea98d74
Cheers,
Franco
-
Nice!
I've removed vlan-pcp in "Option modifiers" and set "Use VLAN priority" in the UI, now waiting 24h. Thanks!
-
Hi,
first, I also confirm that the 2 patchs d08a425759190 and 3ed4f6d2 are working for me. I just had my renew without any issue.
I reverted and applied 2e4a1ea98d74, removed the vlan-pcp option from the modifiers, defined the priority to 6, and applied (that causes a dhclient restart)
after that :
- pfctl rules are ok, the same that with the 2 old patches
- /var/etc/dhclient_wan.conf contains the vlan-pcp option
- after a restart, I correctly got my dhcp lease.
so, it looks good ! see you tomorrow to confirm that the new patch is correct.
many thanks for the job !
-
new patch applied and changes were made to GUI removed the vlan-pcp option from the modifiers and defined the priority to 6
Like Skool, this caused a dhclient restart.
All looks good however in the logs for dhcp6c I noticed this error. Not sure if it was there before as I wasn't checking IPv6. I'm remote so I can't fully check but I'm getting a 19/20 on ipv6-test which is what I would expect.
2023-04-11T19:21:36 Notice dhcp6c dhcp6c REQUEST on igb0_vlan832 - running newipv6
2023-04-11T19:21:34 Notice dhcp6c RTSOLD script - Sending SIGHUP to dhcp6c
2023-04-10T12:04:53 Notice dhcp6c dhcp6c REQUEST on igb0_vlan832 - running newipv6
2023-04-10T12:04:51 Error dhcp6c transmit failed: Can't assign requested address
2023-04-10T12:04:50 Notice dhcp6c RTSOLD script - Starting dhcp6 client
-
2023-04-11T19:21:36 Notice dhcp6c dhcp6c REQUEST on igb0_vlan832 - running newipv6
2023-04-11T19:21:34 Notice dhcp6c RTSOLD script - Sending SIGHUP to dhcp6c
2023-04-10T12:04:53 Notice dhcp6c dhcp6c REQUEST on igb0_vlan832 - running newipv6
2023-04-10T12:04:51 Error dhcp6c transmit failed: Can't assign requested address
2023-04-10T12:04:50 Notice dhcp6c RTSOLD script - Starting dhcp6 client
I dont have this error
you can see on /var/log/system/*.log if it's present in the past days
-
I only have yesterday's log (updated yesterday) but the error was there then as well. Could have been there a while. BUT all seems to be working well.
Franco any clues about where to look at what address it's trying to assign?
-
I have this too with dhcp6c, but it seems this is mostly a hiccup during SIGHUP reload of the configuration (initiated via GUI or by a link even on the WAN interface).
Thanks for testing. I'll merge to development version and fix possibly remaining issues there and we have a fix for 23.1.6 :)
Cheers,
Franco
-
Just renewed on time no issues with the new patch.
19/20 score on https://ipv6-test.com/
-
The latest patch worked also for me. I have the dhcp6c error in my logs.
Thank you Franco!
-
No thank you guys for helping this over the finish line :)
Just one missing internal review for the rules and then it'll be merged.
Cheers,
Franco
-
# opnsense-patch 2e4a1ea98d74
This patch works on my side to. 3 days uptime without problem.
I have the dhcp6c error in my logs.
-
Thanks, it was merged to stable and we are ready for 23.1.6. Just need to remember updating the documentation if no one beats me to it?
Cheers,
Franco
-
I confirm that adding a firewall rule to re-tag priority to 6 for DHCP packets (outgoing UDP packets to 67 and 546, ipv4 and ipv6) fix the issue.
As I read on other forum, it seems this problem is also present on Mikrotik equipment, that probably use the same dhclient app.
So the bug is that dhclient dont use vlan-pcp 6 when renewing a lease.
I dont know if someone is possible on opnsense side or if we need to check with dhclient team.
Hello all. I am on:
OPNsense 22.7.11_1-amd64
FreeBSD 13.1-RELEASE-p5
OpenSSL 1.1.1s 1 Nov 2022
And I face the exact same issue: I need to reboot every day to get the Orange France connection to work again...
I am using IPv4 only (no IPv6). Could you please explain how to add this firewall rule (via the GUI if possible, or via command line)?
Thanks for any help!
-
I would just recommend updating to 23.1.6 and adding the VLAN Priority for DHCPv4 as well in your WAN settings.
Cheers,
Franco
-
Hello Franco and thanks for your answer.
Do you mean 23.1.6 fixed this issue entirely? If not, I'd like to wait before upgrading because I have another opnsense router in another location and I will update both at the same time when I am ready (I like to keep both on same version)
So at the moment, I am still on 22.7.11_1 and I do have "vlan-pcp 6" in the "Option Modifiers" of the IPv4 WAN settings. All works flawlessly but only for ~24 hours (just like what skool described in his first post).
For a moment, I was wondering if you were talking about the setting in Interfaces -> Other types -> VLAN -> igb0_vlan832 -> VLAN priority. So I briefly set it to "Internetwork Control (6)" instead of "Best effort (0)" but the connection was much slower so I had to revert.
Regarding Skool's solution:
I confirm that adding a firewall rule to re-tag priority to 6 for DHCP packets (outgoing UDP packets to 67 and 546, ipv4 and ipv6) fix the issue.
It looks like an easy fix (in case 23.1.6 doesn't fix entirely) but I am not sure how to add this rule. Could you please explain how to add this firewall rule (via the GUI if possible, or via command line)?
Thanks for any help!
-
> So at the moment, I am still on 22.7.11_1 and I do have "vlan-pcp 6" in the "Option Modifiers" of the IPv4 WAN settings. All works flawlessly but only for ~24 hours (just like what skool described in his first post).
Yes you are late to the party. The fix is only in 23.1.6 OR you add the firewall rule yourself.
The fix has been confirmed by multiple people in this thread before 23.1.6 came out so we can be 100% sure it works in 23.1.6.
The power of the community. ;)
Cheers,
Franco
-
OK understood. I will update both my routers to 23.1.6 and I will report here
-
Hello Franco.
I upgraded to 23.1.6 but I am still facing the same problem unfortunately (it works for ~24H only)
- The release notes at https://forum.opnsense.org/index.php?topic=33643.0 mentions Orange FR users be aware that your ISP now requires strict VLAN PCP on all DHCPv4 requests so please do set 'Use VLAN priority' interface setting for both DHCPv4 and DHCPv6. The 'Option Modifiers' override for "vlan-pcp" in DHCPv4 can be removed and the documentation was updated accordingly.
- The documentation at https://docs.opnsense.org/manual/how-tos/orange_fr_fttp.html mentions Some areas of France require that the DHCP and DHCP6 requests are made with a VLAN-PCP of 6. If you are in one of these regions then this can be done via ‘Use VLAN priority’ interface settings. Make sure to set this for both DHCP and DHCP6 at the same time.
I am a bit confused because the pictures in the documentation still show "vlan pcp 6" in the "Option Modifiers" and a pcp of "0" in VLAN priority
So where should I set the VLAN priority of 6 exactly? Note I use IPv4 only and I already tried to setup the VLAN priority as "Internetwork Control (6)" in "Interfaces:Other types:VLAN -> igb0_vlan832 -> VLAN priority" but the connection was much slower so I didn't let it run for ~24 hours
-
@zibloon
No set this option for both DHCP and DHCPv6 on the interface settings INTERFACES-->WAN
-
Ooh I see! Thank you very much
So here is what I did:
- in Interfaces:WAN:
- "Use VLAN priority" = "Internetwork Control (6)"
- I removed "vlan-pcp 6" from the "Option Modifiers"
- in Interfaces:Other types:VLAN -> igb0_vlan832:
- "VLAN priority" = "Best Effort (0, default)"
I'll report in ~24 hours
-
Ooh I see! Thank you very much
So here is what I did:
- in Interfaces:WAN:
- "Use VLAN priority" = "Internetwork Control (6)"
- I removed "vlan-pcp 6" from the "Option Modifiers"
- in Interfaces:Other types:VLAN -> igb0_vlan832:
- "VLAN priority" = "Best Effort (0, default)"
I'll report in ~24 hours
Hello, it's been a few days and I can report the above configuration works smoothly on 23.1.6! Thanks all for your great help!