Bug #8882
open
Interface assignments lost on reboot
Added by Jaime Geiger over 6 years ago.
Updated 7 months ago.
Affected Architecture:
amd64
Description
I'm running pfsense in AWS and I'm trying to route out of xn1 (second interface) instead of xn0 (using it as a sync interface).
LAN is xn0, WAN is xn1 in the interface assignment page.
Both interface assignments (LAN and WAN) get set to xn0 after a reboot, which causes everything to break.
This should not happen. If I set xn0 to WAN and xn1 to LAN then it does not lose the configuration on reboot.
Is WAN required to be the first interface (xn0)?
Let me know if you need other details.
- Status changed from New to Incomplete
Jaime Geiger wrote:
I'm running pfsense in AWS and I'm trying to route out of xn1 (second interface) instead of xn0 (using it as a sync interface).
LAN is xn0, WAN is xn1 in the interface assignment page.
Both interface assignments (LAN and WAN) get set to xn0 after a reboot, which causes everything to break.
This should not happen. If I set xn0 to WAN and xn1 to LAN then it does not lose the configuration on reboot.
Is WAN required to be the first interface (xn0)?
Let me know if you need other details.
I can confirm a similar issue occurs with the pfsense 22.01-RELEASE AWS AMI (ami-0b2dd686e811d2f6b). My experience was that if the network interface intended for LAN is ena0, and the WAN is ena1, then pfsense won't maintain interface mappings or IP configuration after every reboot of the pfsense instance. In fact, what happens was that both LAN and WAN get assigned interface ena0 after a reboot, which is the exact experience listed in this original bug. The only fix I found was to ensure that the WAN interface is ena0.
I can also confirm the same issue. But the issue come when you use a backup file from a vmware Pfsense and use the same restore file on physical devices. So now a customer have an 6100 where it ask for reassigment of the network interface after reboot...
Also available in: Atom
PDF