APU/PFSense 2.3 hangs while booting on VLANs
-
Hi,
First and foremost I hope this is the right subforum for this question.
If not, I appologize.I am trying to install a new APU2 as fw in a network running pfsense 2.3.
Installation went fine and configuring the interfaces and basic settings via the GUI as well.
For the WAN to work I need to use a VLAN (131). When I do this via GUI the connection comes up as expected and I receive an IP over DHCP from the ISP.However, when I reboot the machine remains unreachable.
Looking via the console I see it is hanging. The last thing it says is:'Configuring VLAN interfaces…'
Rebooting results into the same.
Now, when I physically remove the WAN cable from the interface, pfsense does boot as expected.
When I plug back in the WAN cable and choose 'assign IP to interface' (or whatever its called) to force a new dhcpreq for my wan it mentions it is saving the WAN config.
This takes longer than I am used to (~15-20sec), but afterwards the interface and connection are UP though. (incl dhcp lease from my isp)When I reboot the apu2 again, it hangs again like before..
Anyone any clue?
Should I test anything, or ie provide logs, please be so kind to tell me how to collect them for you.
(I am a BSD noob and happy there is a menu in the console and an amazing GUI for further usage) ;-)Thanks in advance!
-
Anyone any idea or suggestions what to try/check please?
I am considering trying the latest pre-2.3 version.. would that be a good option?(not sure what exactly has been changed in 2.3.. Any vulnerabilities to take into account for example?)
-
Anyone, please..?
-
Did you get an answer to this? Having this issue with WAN INTERFACE right now.
-
Just in case anyone runs across this from Google, like I did --
TL;DR: Plug something in; set DHCP timeout to defaults.
Longer version:
If you have a WAN connection that is a mapped switch/VLAN port, it can hang on this boot step due to connectivity reasons.Having a link on the port (and a working one that gets an IP is even better) helps in this case.
It's also worth checking to see if you have a high DHCP timeout set for any devices, since boot seemed to wait for that amount of time to proceed past the step, if the connection was down.
I have a couple of flaky WANs, and had DHCP timeout to 1800, which meant it seemed like it was hanging forever -- but it was really just a super long timeout.
I suspect this also applies to other VLAN situations (re: link / timeout), but I haven't tested that theory.
Hopefully this helps!
-
pfSense certainly takes longer to boot with no WAN connection, there are a number of things that need to timeout. But it certainly shouldn't take 1800s! I assume you had set that specifically in that interface?
It can take a much longer time if you restore a config that had packages in it and it reboots. It will then try to pull in each package and fail. Even that situation has been improved in recent releases though. Far better than it was in 2016.
Steve
-
Yes, I'm sure it is much better! No disrespect intended for certain.
Correct, I had set it manually in the interface after some advice on the interwebs on similar flaky connections.
To be clear, this actually helped the problem, but because it kept pfSense from booting, that won't work.
I've moved on to attempt other workarounds, but figured I'd share the discovery, since I found this first when I was researching the issue (due to the keyword match with symptoms), but it took a while to get here.
-
No worries. Good to put info where it's likely to be found.
