pfSense router does not receive IP adress from ISP
-
@Gertjan said in pfSense router does not receive IP adress from ISP:
Router is pfSense, not your ISP router, right ?
Correct. My router is pfSense. My ISP fiberbox is an Icotera
This is what the interface widget looks like:
This is the DHCP log right after boot up, where the router fails at getting an IP:
Aug 1 14:17:05 dhcpd 53198 Internet Systems Consortium DHCP Server 4.4.2-P1
Aug 1 14:17:05 dhcpd 53198 Copyright 2004-2021 Internet Systems Consortium.
Aug 1 14:17:05 dhcpd 53198 All rights reserved.
Aug 1 14:17:05 dhcpd 53198 For info, please visit https://www.isc.org/software/dhcp/
Aug 1 14:17:05 dhcpd 53198 Config file: /etc/dhcpd.conf
Aug 1 14:17:05 dhcpd 53198 Database file: /var/db/dhcpd.leases
Aug 1 14:17:05 dhcpd 53198 Internet Systems Consortium DHCP Server 4.4.2-P1
Aug 1 14:17:05 dhcpd 53198 PID file: /var/run/dhcpd.pid
Aug 1 14:17:05 dhcpd 53198 Copyright 2004-2021 Internet Systems Consortium.
Aug 1 14:17:05 dhcpd 53198 All rights reserved.
Aug 1 14:17:05 dhcpd 53198 For info, please visit https://www.isc.org/software/dhcp/
Aug 1 14:17:05 dhcpd 53198 Wrote 0 class decls to leases file.
Aug 1 14:17:05 dhcpd 53198 Wrote 0 deleted host decls to leases file.
Aug 1 14:17:05 dhcpd 53198 Wrote 0 new dynamic host decls to leases file.
Aug 1 14:17:05 dhcpd 53198 Wrote 8 leases to leases file.
Aug 1 14:17:05 dhcpd 53198 Listening on BPF/igb1/64:62:66:21:23:e1/192.168.1.0/24
Aug 1 14:17:05 dhcpd 53198 Sending on BPF/igb1/64:62:66:21:23:e1/192.168.1.0/24
Aug 1 14:17:05 dhcpd 53198 Sending on Socket/fallback/fallback-net
Aug 1 14:17:05 dhcpd 53198 Server starting service.
Aug 1 14:17:12 dhcpd 53198 DHCPDISCOVER from 50:67:ae:f0:5d:71 via igb1
Aug 1 14:17:12 dhcpd 53198 DHCPOFFER on 192.168.1.5 to 50:67:ae:f0:5d:71 via igb1
Aug 1 14:17:12 dhcpd 53198 DHCPREQUEST for 192.168.1.5 (192.168.1.1) from 50:67:ae:f0:5d:71 via igb1
Aug 1 14:17:12 dhcpd 53198 DHCPACK on 192.168.1.5 to 50:67:ae:f0:5d:71 via igb1The router never gets an IP unless I unplug/replug the WANcable.
-
@Schmeling that is not the dhcp client that is pfsense dhcp server.
-
@Gertjan said in pfSense router does not receive IP adress from ISP:
(all the lines with dhcpc, as this log is shared with the DHCP v4 and v6 server, and the dhcp6c if you use it).
I was wrong / sorry : it's called dhclient
A copy from my logs :
<13>1 2023-07-31T07:27:41.491659+02:00 pfSense.bhf.net dhclient 71901 - - PREINIT <30>1 2023-07-31T07:27:41.503620+02:00 pfSense.bhf.net dhclient 24464 - - DHCPREQUEST on ix3 to 255.255.255.255 port 67 <30>1 2023-07-31T07:27:41.508664+02:00 pfSense.bhf.net dhclient 24464 - - DHCPACK from 192.168.10.1 <27>1 2023-07-31T07:27:41.508950+02:00 pfSense.bhf.net dhclient 24464 - - unknown dhcp option value 0x7d <13>1 2023-07-31T07:27:41.513156+02:00 pfSense.bhf.net dhclient 74114 - - REBOOT <13>1 2023-07-31T07:27:41.517228+02:00 pfSense.bhf.net dhclient 74895 - - Starting add_new_address() <13>1 2023-07-31T07:27:41.521867+02:00 pfSense.bhf.net dhclient 75591 - - ifconfig ix3 inet 192.168.10.4 netmask 255.255.255.0 broadcast 192.168.10.255 <13>1 2023-07-31T07:27:41.532702+02:00 pfSense.bhf.net dhclient 77215 - - New IP Address (ix3): 192.168.10.4 <13>1 2023-07-31T07:27:41.534628+02:00 pfSense.bhf.net dhclient 77723 - - New Subnet Mask (ix3): 255.255.255.0 <13>1 2023-07-31T07:27:41.538606+02:00 pfSense.bhf.net dhclient 78566 - - New Broadcast Address (ix3): 192.168.10.255 <13>1 2023-07-31T07:27:41.542286+02:00 pfSense.bhf.net dhclient 79644 - - New Routers (ix3): 192.168.10.1 <13>1 2023-07-31T07:27:41.548085+02:00 pfSense.bhf.net dhclient 80306 - - Adding new routes to interface: ix3 <13>1 2023-07-31T07:27:41.568726+02:00 pfSense.bhf.net dhclient 83164 - - /sbin/route add -host 192.168.10.1 -iface ix3 <13>1 2023-07-31T07:27:41.572065+02:00 pfSense.bhf.net dhclient 83662 - - /sbin/route add default 192.168.10.1 <13>1 2023-07-31T07:27:41.574570+02:00 pfSense.bhf.net dhclient 84231 - - Creating resolv.conf <30>1 2023-07-31T07:27:41.624504+02:00 pfSense.bhf.net dhclient 24464 - - bound to 192.168.10.4 -- renewal in 43200 seconds.
From start to end : less then 200 ms.
On line 7 the ix3 (my WAN interface) is configured with the obtained info.
Your LAN uses the default 192.168.1.1/24
Now I hope that you confirm that your ISP router doesn't also use 192.168.1.1/24 as that would introduction world's most common network failure : a router can't route between identical networks.As you can see, my ISP router uses 192.168.10.1/24.
It was using 192.168.1.1/24 ** so I changed that before using it with pfSense.** as nearly all routers use 192.168.1.1/24 as their default LAN network.
pfSense is 'just' a router as any other router out there. -
Sorry about posting the wrong log. I do not seem to be able to find a log section marked dhclient, but searching for "dhclient" in the log I find the following lines in the timeframe for the bootup:
Aug 1 14:16:21 php 432 rc.bootup: The command '/sbin/dhclient -c /var/etc/dhclient_wan.conf igb0 > /tmp/igb0_output 2> /tmp/igb0_error_output' returned exit code '1', the output was ''
and
Aug 1 14:16:09 dhclient 8495 Cannot open or create pidfile: No such file or directoryThese are the only lines, I can find around that time. The WAN and LAN IP ranges are completely different LAN 192... WAN 80...
-
@Schmeling this seems to be same problem
https://forum.netgate.com/topic/142695/dhclient-doesn-t-work-after-boot-up-for-wan-conected-to-modem
From the last post it seems just updating the timeout in the advanced section fixed it for them.
-
@johnpoz said in pfSense router does not receive IP adress from ISP:
Schmeling this seems to be same problem
https://forum.netgate.com/topic/142695/dhclient-doesn-t-work-after-boot-up-for-wan-conected-to-modem
Setting Timeout = 900 as pr. the other post does nothing. Behavior is exactly the same.
The aprox. boot up time for the ISP fiber modem is only 90 seconds.
-
It's a timing issue. If the modem brings down the link during it's boot process pfSense will not start the dhclient on it. Normally the client would start as soon as the link comes back up but if that is while pfSense is still booting it will ignore the link-up event.
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.Steve
-
@stephenw10 said in pfSense router does not receive IP adress from ISP:
If the modem brings down the link during it's boot process pfSense will not start the dhclient on it
I presume that pfSEnse is up and running at that moment.
A down event doesn't produce any dhclient activity, that's ... understandable.
If the ISP router brings down (de activates) it's LAN interface, - presuming its booting or at the end of the boot prcoess, then this will be followed by an activation == UP event. As pfSense is still on hold, and has activated the (WAN) link on his side, this will be detected and a dhclient exchange will (should) happen.@stephenw10 said in pfSense router does not receive IP adress from ISP:
Normally the client would start as soon as the link comes back up but if that is while pfSense is still booting it will ignore the link-up event.
In this case, I presume the ISP router is up and ready, and has its LAN interface activated.
pfSense boots, activates the WAN, and if the link is up, this will (should) fire up a dhclient event right away.
This is exactly what happens when we reboot pfSense - while the ISP router is 'untouched'. -
But when both are rebooted simultaneously, like if there's a power outage, then you can hit this issue.
-
@stephenw10 said in pfSense router does not receive IP adress from ISP:
But when both are rebooted simultaneously, like if there's a power outage, then you can hit this issue.
This is exactly my problem. Power outages are not uncommon where I live, which is exactly why this is a problem for me. I have a public IP, with ports open and if the power goes, and the router cant get an IP address, I'm screwed.
I'm assuming, that I just connect with ssh/Putty chose shell in the menu and use VI to edit the file, and as far as I can see right now, the autoboot_delay =3 is that in seconds? Second I do not seem to be able to find the file loader.conf.local in the boot directory. Am I looking in the wrong place?
-
Yes, or you can edit the file in gui in Diag > Edit File. Or use the easy editor (
ee
) in the gui if you're not familiar with vi.Yes the default delay is 3 seconds. I'd try 30 seconds and see if that fixes it.
You will see in the boot logs if it doesn't, it reports/rc.linkup: Ignoring link event during boot sequence.
Yes, you need to create /boot/loader.conf.local
Steve
-
@Schmeling
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 shellecho "autoboot_delay=\"30\"" >> /boot/loader.conf.local
to create it and enter the option for 30 s delay.
-
I just tested with autoboot_delay=80 and cut the power. The bootup actually worked, but when I open loader.conf with vim, the delay is back at 3. Is this expected behaviour and was the value of 80 even used?
When trying: echo "autoboot_delay="30"" >> /boot/loader.conf.local I get: Unmatched '"'.
-
@Schmeling you would have to create the loader.conf.local file
You need the \ in there to escape those " etc..
-
I have encountered excactly this issue too, on power outage.
If the Wan Etherlink isn't up at pfSense boot time, pfSense never retry to get a DHCP ip address.
Disconnecting the WAN or reboot pfSense would solve it ... But my summerhouse is in SwedenI had to put a "fast booting" switch between the pfSense Wan & ISP Ether.
Nice to see there is a "better" solution
Even though i still think pfSense should keep retrying, instead of just "give up".
/Bingo
-
What if you give PfSense WAN a static IP in the ISP router subnet ? Then there should be no DHCP issues..
-
@pwood999 said in pfSense router does not receive IP adress from ISP:
What if you give PfSense WAN a static IP in the ISP router subnet ? Then there should be no DHCP issues..
That would work too.
But at least where i live, there aren't many ISP's that offer a static IP. ... (For home use)
They often use pure DHCP , or "MAC Locked DHCP"/Bingo
-
@bingo600 Surely if the ISP router gives you a 192.168.10.x /24 address, then it's doing NAT to a public IP on the ISP WAN side ?
-
@Schmeling said in pfSense router does not receive IP adress from ISP:
When trying: echo "autoboot_delay="30"" >> /boot/loader.conf.local I get: Unmatched '"'.
[23.05.1-RELEASE][root@pfSense.bhf.net]/root: echo 'autoboot_delay="30"' >> /boot/loader.conf.local [23.05.1-RELEASE][root@pfSense.bhf.net]/root: cat /boot/loader.conf.local .... autoboot_delay="30"
@pwood999 said in pfSense router does not receive IP adress from ISP:
What if you give PfSense WAN a static IP in the ISP router subnet ? Then there should be no DHCP issues..
Depends.
Who/where is de DHCP server ?
Is it the ISP router ? In that case, a RFC1918 will be obtained, and a static setup for IPv4 can be used.If the ISP router isn't a router at all, but some sort of device that behaves like a modem, then the situation becomes a bit more complex.
This type of device can, in the early boot phase, activate the LAN asap, use their on board DHCP server to hand out RFC1918 to the (only ! - must be a router) LAN based device.
This lease obtained isn't use for routing at all, just so the user can access its GUI to change the modem's settings. As soon as the ISP modem WAN side has a good working connection, it toggles the LAN side (up => down => up) and this will signal pfSense to restart its DHCP client - forcing it to redo the lease. This time, the ISP modem device is 'transparent' and the request will be send over the line to the ISP DHCP server. This one will hand over a lease that can be used to route, as it will contain a 'real' WAN IP, a usable gateway etc.@Schmeling : can you tell us what you use ?
-
Thanks. The "edit file" option in the GUI was very easy, and then I can disable ssh as well.
I edited /boot/loader.conf / autoboot_delay=80 and /boot/loader.conf.local / autoboot_delay=80 and tested. This seems to fix the problem and I even had a chance to do a firmware upgrade top 2.7. The changes in /boot/loader.conf.local persisted even after the firmware upgrade, so this seems like a real permanent solution.
Just one question: the changes in /boot/loader.conf reverted back to 3 seconds after first reboot/powercut. I'm assuming this is expected behavior and that the autoboot_delay in loader.conf is overruled by autoboot_delay in loader.conf.local. Am I correct here?