DHCP client spoof/supersede with variables

[KernelMaker]

Hi all,

I am trying to adjust the pfsense DHCP client connected to a Huawei 5G/LTE modem which I would like to use as a fiber backup.

The problem, Huawei's bridge mode is just crap.
They assign a /8 fake subnet to the client which looks like this:

Public IP: 37.11.22.33
Mask: 255.0.0.0
Gateway: 37.0.0.1

This results in all 37. addresses being unreachable for pfsense.

I have already created a workaround using the "supersede" function in the DHCP client options:

This is working fine for both the netmask and the gateway but you need to "hard code" the gateway.
If you restart the modem, the public IP changes. Then you need to change the DHCP option manually.

Is is possible somehow to use variables inside the options?
Something like this:
supersede subnet-mask 255.255.255.0, supersede routers {3 blocks of Lease IP and ending 1}

I have already tried to use the DHCP client script function. But I am stuck here because you can only use environment variables (like interface or mtu) inside the script.

[johnpoz]

@kernelmaker said in DHCP client spoof/supersede with variables:

Huawei's bridge mode is just crap.

I'm a bit confused.. So they give you a valid IP but then they screw up the mask? And the router IP?

How would it even do that? Your saying if not bridge mode the mask and router address is correct?

[KernelMaker]

@johnpoz said in DHCP client spoof/supersede with variables:

I'm a bit confused.. So they give you a valid IP but then they screw up the mask? And the router IP?

How would it even do that? Your saying if not bridge mode the mask and router address is correct?

Yes, you are right.

The real IP would be something like 37.../32
But the Huawei Router creates a L3 bridge (instead of a true L2 bridge) and routes all traffic coming from the fake subnet to the cellular network.

This tends to be a common way for LTE modems offering "bridge mode".

BTW the Netgear LTE modem is doing the same but only wasting the /24 network instead of the hole /8:
https://community.netgear.com/t5/Mobile-Routers-Hotspots-Modems/LB1120-Bridge-Mode-No-Connectivity/m-p/1404666

They patched the firmware for this.
Before that, the supersede workaround was used.

But Huawei's support is stupid. I already raised a ticket there. They won't fix this.
On older routers, you were able to manipulate the firmware config in order to adjust DHCP ranges. But this is not working on the latest models (until now).

I also tried the "Gateway IP outside of subnet" option in pfsense to use the 37.0.0.1 gateway together with a /32 address but this is not working for DHCP assigned gateways. This means, I would need to create a manual gateway which is not working together with a DHCP client used on the interface.
This seems to be a bug in pfsense.

So, in conclusion: Two problems at once, Huawei's crappy bridge mode + bug in pfsense for gateway outside the subnet.

This is a screenshot of the interface without custom options:

You can't access all public host inside the 37. range at all.
It is even more worse if your ISP is using CG-NAT / private IPs. Then you get something like this:

10.11.12.13
255.0.0.0
10.0.0.1

Then your hole 10.0.0.0/8 RFC1918 is completely wasted.

[johnpoz]

@kernelmaker said in DHCP client spoof/supersede with variables:

pfsense for gateway outside the subnet.

So your saying this option isn't working

This is in the advanced options when you add a gateway manually.. Is there a redmine for that?

Yeah sure sounds like a horrible setup.. I wish I could be more help - but never in my life seen such a situation.. 30 years in the business.. At a complete loss to why they would do such a thing.

Maybe its common in the LTE gateway world? Have limited experience with cradle point doing LTE, but never ran into such a thing - but we never used "bridge mode" on them.. Always just let them nat.. Can you not just nat what amounts to this transfer network between pfsense and the LTE device. Let the LTE device nat, and then pfsense nat to whatever rfc1918 address it gives you on the wan connection on pfsense from the LTE device?

[KernelMaker]

@johnpoz said in DHCP client spoof/supersede with variables:

@kernelmaker said in DHCP client spoof/supersede with variables:

pfsense for gateway outside the subnet.

So your saying this option isn't working

This is in the advanced options when you add a gateway manually.. Is there a redmine for that?

Yes, this option is not working.

Steps I did:
supersede netmask to 255.255.255.255

Which results in:
37.11.22.33
255.255.255.255
37.0.0.1

Then checked the option above for the gateway created automatically.

But this can also be a bug in the Huawei firmware which declines such packets
Unfortunately, debugging or package capture is quite difficult here.

Therefore, I haven't created a redmine for that until now

[KernelMaker]

@johnpoz said in DHCP client spoof/supersede with variables:

Yeah sure sounds like a horrible setup.. I wish I could be more help - but never in my life seen such a situation.. 30 years in the business.. At a complete loss to why they would do such a thing.

Maybe its common in the LTE gateway world? Have limited experience with cradle point doing LTE, but never ran into such a thing - but we never used "bridge mode" on them.. Always just let them nat.. Can you not just nat what amounts to this transfer network between pfsense and the LTE device. Let the LTE device nat, and then pfsense nat to whatever rfc1918 address it gives you on the wan connection on pfsense from the LTE device?

Yeah, really stupid thing ;)

I could use normal router mode with NAT but then you run in different problems like Huawei only doing TCP/UDP NAT.
And it doesn't respond to pings even with "Disable WAN Ping" unchecked lol

I would like to use GRE and Wireguard over the LTE backup to get some sort of failover.
But GRE is only working in bridge mode.

[KernelMaker]

Another approach would be the creation of a DHCP forwarder.
This will listen to the lease offered by the modem and creates a new lease with adjusted data.
Then you can decline the modem DHCP server in pfsense.

But quite much afford for this sh*t, isn't it?