PfSense won't get IP on restart w/o physically disconnecting port
-
Hi, all -
I've encountered this problem with pfSense running on VirtualBox for a while now and I'm a bit stumped. I could use some suggestions on what to look at next.
A little about my system:
Host OS -> CentOS 6.4 w/ latest patches
pfSense -> 2.1-RC1 (but this happened under both RC0 and 2.0.3)
VirtualBox -> 4.2.16 r86992I finally got VirtualBox configured to start my pfSense VM at boot. The problem I've encountered is that when I reboot the Host OS machine, pfSense will not get a WAN DHCP address from the cable modem. The ONLY way I can seem to force the WAN to grab it's IP address is to physically disconnect and reconnect the interface to the cable modem. I am a little stumped as to why it takes the port going down to trigger the IP renewal. I can consistently reproduce this issue. My ISP is Comcast if that is of any significance.
Any ideas on what else I can do to force the WAN to get it's IP?
-
Looks like I solved my own problem.
Previously, the pfSense VM had a MAC address that was different from the physical NIC connected to the cable modem. This same MAC was configured as the MAC on the WAN interface in the pfSense configuration and in the VirtualBox configuration. This worked, but only after physically connecting/disconnecting the cable between the host machine and the cable modem or rebooting the cable modem.
The "fix" was to clone the MAC of the physical NIC in both the VirtualBox configuration for the VM and in the WAN configuration in pfSense. Once I did that all was good!
In summary:
CentOS:
Go to: System->Preferences->Network Connections->(your WAN interface NIC)
Under IPv4 Settings tab: set Method to "Disabled"
Under IPv6 Settings tab: set Method to "Ignore"VirtualBox:
Get the MAC address of your physical NIC connected to the WAN (ifconfig output, whatever you prefer…)
Use this MAC value in the WAN network adapter in your VM config
pfSense:
Use the same MAC value as the above in the pfSense WAN configurationNow reboot and see if your VM grabs a DHCP address properly.
I'm not sure why more than 1 MAC on the WAN was causing the conflict, especially since only the VM MAC was ever really in use. But this approach certainly seems to have resolved the issue for me. Hopefully it will help others.