After pfsense boots, DHCP offer does not contain `Option: (3) Router` so client has no default route

left4apple

Recently there was two power outages at my home. Even after the power is back, I'm not able to ping 8.8.8.8 from my desktop. Initially I thought it's because pfSense boots too fast, faster than the modem getting ready. But then I found that all my devices that has static IP all work just fine.

The next thing I found was that there's no default route(0.0.0.0/0) on my MacOS, and I realized it might be DHCP issue.

Restarting pfSense solves the problem, but I eagerly want to know what's going on to prevent it from happening again. So I manually cut of the power and reconnect it to mimic the incident. The problem continued as expected. I use Wireshark to capture the DHCP packets in both cases, and I found that in the bad cases, DHCP OFFER packet does not contain Option: (3) Router which is exactly what tells the client to update their routing table.

# Only the good case has this section in DHCP offering
    Option: (3) Router
        Length: 4
        Router: 10.0.0.1

Can I get some hint about what's happening? Does pfSense DHCP service require the WAN to be up?

Thanks!

left4apple

Upon checking the DHCP server settings in pfSense, I'm not seeing where 10.0.0.1 as router/gateway (Option 3) is set anywhere which makes me wonder how DHCP figures out 10.0.0.1 in the first place? I guess it's using the IP of the LAN interface?

bingo600

@left4apple

On the DHCP Server settings, this is the Opt3 settings

I have no idea if Opt3 would be suppressed of the fwall has no valid gateway.
I use ISC-DHCPD on linux as my DHCP server.

That said , you might want to goto system --> routing , and force def-gw to the WAN-GW (bottom)

Leaving that one "default".
Was once biting my "behind" hard, as it due to a small "glitch" on WAN , decided to use the "next" gateway .... And not switching back, when WAN came back.

left4apple

@bingo600 Thanks for the info. To find out if DHCP setting option 3 has anything to do with an active Internet gateway, I did some experiments:

Observation:

If pfSense and Modem are powered on at the same time, pfSense boots too fast will first get 192.168.100.x IP, and then change to the actual Internet IP(65.x.x.x). In this case, DHCP OFFER does not contain option 3, but pfSense has correct routing table.

Experiments(each carried out independently):

Boot pfSense 120 seconds after the modem. pfSense only sees 65.x.x.x.
Result: Everything works correctly now.
In the DHCP server setting, manually set the Gateway IP to 10.0.0.1. This works
Result: DHCP contains Option (3) (for sure since it's hardcoded)
Set the Default Gateway to WAN.
Result: Doesn't Help. Even worse, after getting the 65.x.x.x IP, pfSense does not have default route table item, thus cannot ping any public IP. Restarting the interface works.

So I guess the workaround(not even a solution) is:

Manually set the Gateway IP in DHCP server. It's fine since my LAN interface won't change.
Add a delay when booting the pfSense server.
(Added) Reject 192.168.100.1 as DHCP server in WAN interface setting so that pfSense doesn't get 192.168.100.20. This slows down the booting a little as pfSense will wait on "Configuring WAN" to get the real Internet IP

bingo600

@left4apple said in After pfsense boots, DHCP offer does not contain `Option: (3) Router` so client has no default route:

@bingo600 Thanks for the info. To find out if DHCP setting option 3 has anything to do with an active Internet gateway, I did some experiments:

Observation:

If pfSense and Modem are powered on at the same time, pfSense boots too fast will first get 192.168.100.x IP, and then change to the actual Internet IP(65.x.x.x). In this case, DHCP OFFER does not contain option 3, but pfSense has correct routing table.

Experiments(each carried out independently):

Boot pfSense 120 seconds after the modem. pfSense only sees 65.x.x.x.
Result: Everything works correctly now.

In the DHCP server setting, manually set the Gateway IP to 10.0.0.1. This works
Result: DHCP contains Option (3) (for sure since it's hardcoded)

Set the Default Gateway to WAN.
Result: Doesn't Help. Even worse, after getting the 65.x.x.x IP, pfSense does not have default route table item, thus cannot ping any public IP. Restarting the interface works.

So I guess the workaround(not even a solution) is:

Manually set the Gateway IP in DHCP server. It's fine since my LAN interface won't change.

Add a delay when booting the pfSense server.

I think our local pfSense Guru stephenw10
posted this as a workaround (delay)

https://forum.netgate.com/post/1118393

Edit /boot/loader.conf and set autoboot_delay to something larger so that the modem has brought the link up by the time pfSense tries to start the dhclient.
If that works create the loader entry in /boot/loader.conf.local so it never gets overwritten.



Yes, the delay time is in seconds.

The /boot/loader.conf.local doesn't exist out of the box. You have to create it.
Just enter in the shell

echo "autoboot_delay=\"30\"" >> /boot/loader.conf.local

to create it and enter the option for 30 s delay.

BassStation70

@left4apple FWIW, I noticed this behavior on my pfSense instance as well. I ended up setting DHCP Gateway IP manually, as you did in option 2. Seemed like it shouldn't have been necessary, but it did solve my problem.

left4apple

@bingo600 said in After pfsense boots, DHCP offer does not contain `Option: (3) Router` so client has no default route:

I use ISC-DHCPD on linux as my DHCP server.

Curious. What's the benefit of using a 3rd party DHCP server, instead of the one that pfSense integrates?

johnpoz

@left4apple said in After pfsense boots, DHCP offer does not contain `Option: (3) Router` so client has no default route:

What's the benefit of using a 3rd party DHCP server

Would depend on the dhcp server - for example if your MS shop, prob better to just run dhcp on you windows server - so it can integrate easier with your AD. Along with dns

As to running the same ISC-DHCPD which is what pfsense runs anyway - prob not much. But with using just the .conf vs what is exposed in the pfsense gui for the dhcp server. More complex configurations would prob be the advantage here. If they are running that - prob time to move on, since isc dhcpd is eol.. And the version currently running on pfsense 4.4.3-P1 is currently the last plan release.

If you were already running a well rounded dhcp server, you prob wouldn't want to switch over to running it on pfsense since you already have something setup and stable, etc. But to advantages - again would depend on exactly what dhcpd you were or plan on running.

bingo600

@left4apple

1:
I already had the setup running, with Bind & ISC-DHCPD

2:
I had a fully working DDNS (Dynamic DNS) setup , where DHCP clients are realtime registering with the DNS part (Bind).
And i liked to be able to resolve my DHCP clients. - Unbound and DDNS sucks.

So DNS & DHCP runs on my linux server(s) , and pfSense (Unbound) uses my linuxes as DNS servers.
Since t have set my clients to ask pfSense for DNS, and pfSense asks linux for DNS records, I "get the best from both worlds" ... (Ie. i can still do dns overrides in pfSense)

/Bingo