How to hack built-in DHCP Client pfrule?
-
Hi All.
I’m trying to work around a bug I found in pfSense where DHCP RENEW frames are not correctly VLAN Priority tagged if you enable VLAN priority Tagging fx. On your WAN Interface. I already created a redmine on the issue.
https://redmine.pfsense.org/issues/14397
But I have a site in france where this is causing major problems. I have a daily outage when the renew timer expires and the ISP invalidates the lease because I send an incorrectly tagged Renew frame. (The ISP requires both Discover and Renew are correctly tagged).
I can’t seem to create a floating match rule that VLAN Priority tags the Renew frames, and I think I found the problem.
It seems it is because there is a builtin QUICK PASS rule from netgate to allow the DHCP Client on WAN with a permanent higher priority. Thus my match rule never comes into action.Where can I find the .inc file that defines and sources the used Builtin pfRules for fx. The DHCP Client, the WebUI and so on?
If i can hack that to priority tag the DHCP rule, it should work as a temporary workaround until Netgate fixes the bug (if ever). The alternative is to change to OPNsense, but I’d rather not :-) -
@keyser said in How to hack built-in DHCP Client pfrule?:
The alternative is to change to OPNsense, but I’d rather not :-)
Emotional trigger...I thought you found a temporary work-a-round. Use that until your "bug" get answered while you patiently wait. Contemplate that a mission critical as yours, vLAN might not be the best angle/strategy to your solution.
-
@nollipfsense Dropping this VLAN setup is not up to me. It’s the ISP that requires the use of a tagged VLAN on the fiber if you do not wish to use their CPE (Which cannot be bridged nor added routes/NAT ranges to). So its either this, or double NAT, two boxes and a terrible mess.
In the meantime I found the rules file /etc/inc/filter.inc, and reading through that, I may have found a “built-in” workaround, even though I’m sure it’s not intentional. I’ll test the outcome tonight at renew time, and post my findings here.
-
K keyser referenced this topic on
-
@keyser said in How to hack built-in DHCP Client pfrule?:
or double NAT
There is no problem double natted. I have been running double natted since I had been using pfSense in 2016. Also, since this year, I have been triple natted on half of my network with a CGNAT ISP. Sometime that's the only choice...it's not ideal, in my case, it's expensive having to run a second pfSense box to avoid the CGNAT for a specific application on the other half of my network; but, it works. You got to do what you got to do.
-
@nollipfsense i know it works, But like I said, not an option Here. Its a remote site, and i need permanent remote access and always up IPSec tunnels to the site. That’s just too flakey and untenable if it relies on the remote site initiating everything when doing upgrades and reconfigurations
-
@keyser curious but why do you need to add a priority? I’ve never heard of that at least here in the states
-
@michmoor said in How to hack built-in DHCP Client pfrule?:
@keyser curious but why do you need to add a priority? I’ve never heard of that at least here in the states
It’s the ISP doing what they can to prevent end users from using their own equipment directly on the GPON fiber (No ISP CPE box active).
Here in france Orange is quite agressive in their requirements. Fx, you need to simulate their CPE box by sending its model and make in DHCP options. You alson need to send a specially crafted unique login/customer encoded in HEX as a DHCP option.
You need to change the identity of your ONT module to what Orange uses, and last but not least all DHCP frames needs to be 802.1p tagged with priority 6 - otherwise no answer is given.Annoying that they make it so difficult, but I guess it insures only people that know what they are doing get to bring their own equipment on their Fiber GPON tree.
But it’s nice to save the power of the IPS box and have the public IPs directly on my own pfSense (for remote control and VPN), so it’s worth the trouble for me.
-
@keyser that is very aggressive.
Can you get a static IP then? Bypass the whole dhcp process -
@michmoor Static IP is possible, but it is only/still assigned by DHCP - If you do not pass DHCP, you never activate the other end of the GPON tree to your device/equipment.
-
As a hack/test you probably want to add it here:
https://github.com/pfsense/pfsense/blob/master/src/etc/inc/filter.inc#L3723Though it seems pretty well confirmed at this point.
-
@stephenw10 Thanks for pointing me to the line to “hack”.
However, I noticed the line already has a VLAN tagging option if it is enabled in the UI under DHCP options (VLAN Priority tagging).
So I tried setting that option to Priority 6 even though I know that its “vlan-pcp 6” setting in the dhclient.conf file is ignored and overwritten by my advanced DHCP settings (because I need to use that).
However - it seems that it still activates adding the VLAN priority to the built-in DHCP pass-out rule used for unicast (checked with pfctl -sa). So now I have both activated the priority setting and added vlan-pcp to the advanced option modifiers.I’ll let you know if it solves to problem tonight at the next renewal - I’m crossing my fingers.
-
Ok, so to be clear the generated ruleset did not include the prio-tagging on the dhcp out rule previously? Because the dhcp tag setting is dropped by the custom config override?
But now you have manually added it the tag shows in the running rule?
-
@stephenw10 said in How to hack built-in DHCP Client pfrule?:
Ok, so to be clear the generated ruleset did not include the prio-tagging on the dhcp out rule previously? Because the dhcp tag setting is dropped by the custom config override?
But now you have manually added it the tag shows in the running rule?
Not quite - I can understand the confusion. Here’s a screenshot:
I did not have the first red buble enabled (priority VLAN tagging) because several posts and a redmine says it’s overridden anyways when you enable “Advanced configuration”.
In Adv. Config I have enabled “vlan-pcp 6” (Second red buble) which supposedly does the same thing as the first.But that not actually quite true. The first buble - apart from adding “vlan-pcp x” to dhclient.conf - also adds the VLAN priority set to the automatic builtin “pass-out DHCP rule from WAN”.
Adding “vlan-pcp 6” to modifiers only adds “vlan-pcp x” to dhclient.conf but does not enable the “set vlan prio” in the auto rule - thus RENEWS are not priority tagged - only DISCOVER.But it seem by enabling both I get the best of both worlds - just need to make sure to set them to the same priority. Now i just need to confirm it actually works (I have a packet capture lined up for my upcoming renew in 10 min :-))
Update: I can confirm it works now. I just renew’ed my IP by doing my setup as described in my post.
I’ll update my redmine stating this “workaround”.
I’m a little confused if this is in fact intended behavior, but if it is, there is a lot of info online to the contrary - including redmine posts by Netgate -
This post is deleted! -
Hmm, interesting. Glad you found a workaround until we can rework this to something more usable.
I agree that comment implies that either advanced config or config override will remove that setting but it doesn't seem to be the case. And I'm not sure why it would. Config override certainly would but enabling advanced config should not. And doesn't.
However I also don't expect you to need to set 'vlan-pcp 6' as a manual option with that set. It should do the same thing. -
@stephenw10 said in How to hack built-in DHCP Client pfrule?:
I agree that comment implies that either advanced config or config override will remove that setting but it doesn't seem to be the case.
Not sure I agree - it does seem to be the case, because it’s not enough to only enable the first red buble settings. Then DISCOVER and RELEASE are not priority tagged correctly and there is no “vlan-pcp x” setting in dhclient.conf if I have advanved settings enabled. That seems to suggest it was overwritten by enabling advanced config. With dhclient using a bgf? Interface for discover and release, I assume the builtin pf-rule “set prio x” has no effect on packets through that and thus needs the dhclint.conf setting as well?
And I'm not sure why it would. Config override certainly would but enabling advanced config should not. And doesn't.
However I also don't expect you to need to set 'vlan-pcp 6' as a manual option with that set. It should do the same thing.Agreed, this probably should be made simpler in the interface.
-
Right so it overrides the actual 'vlan-pcp 6' entry, so the bpf rule, but not the fact it's enabled which is what sets the tag in pf.
-
@stephenw10 Yep, that’s what my testing shows.
-
K keyser referenced this topic on
