Got a freeBSD-based VM that is set up as a plain gateway for now (no openvpn yet). It works alright, but when you suspend and resume it, WAN-side networking no longer works, unless you go and manually change the static IP of the WAN-side interface through the web configurator of the gateway (it is a pfsense one), which you do from a client VM and its browser. All IP's are static for now. Why might vmware suspend and resume break networking even when static IP's are used?
The guest operating system (freeBSD) seems to reset the settings of the WAN-side interface (which is a USB-to-ethernet adapter), after coming out of sleep, but keep the settings of the LAN-side interface which is a plain virtual network interface. Why would it do that? EDIT: Just found it only happens with this USB-to-ethernet adapter, not with a regular virtual network adapter on the WAN-side.
Could you clarify - you have this real USB-to-ethernet adapter on your host, correct? Is the VM bridging or NATing off that connection? The other issue is if the VM is trying to grab the USB device. Clearly any virtual ethernet network adapters will be pretty much vanilla as far as freeBSD is concerned, so you'd expect the virtual LAN side to work fine - after all, pfsense can cope with a whole range of them.
Yes, this is a real physical USB-to-ethernet adapter whose usb plug is virtually connected to the VM automatically at resume. The guest then ends up seeing a network interface that the host cannot see. The physical ethernet port of the USB-to-ethernet adapter is connected to the ADSL router. So the guest sees the router but the host does not (that's for security). So no bridging or nating. So why would the VM forget the static IP of the network interface provided by the USB-to-ethernet device when resumed?
Ah, got it, understand. What version of pfsense are you on? I guess the host will "see" the usb device again while the pfsense box is suspended and maybe write to it, and I don't know whether the adapter will be properly initialised once it's resumed. Is there anything too bad with shutting down/restarting?
Shutting down and restarting works indeed, it just takes much longer and I'm not sure it is safe if done by just closing the VM window (instead of the proper way by typing 6 and then y inside the VM). This is the latest version 2.2.2 of pfsense. The windows 8 host has been set up to have the device disabled when it sees it, don't want to risk any internet access by the host.
Is there something I can type in a command line in the VM to find out what the guest thinks is happening with the device?
I don't think pfsense is doing anything particularly fancy about the halt as far as the OS is concerned, though obviously you want to avoid leaks as it's going down. If the system has initiated that (as it will if vmware tells it to), pfsense has to respond properly to the kill, but in all other respects the OS should shutdown as normal. But I guess if you don't want to test all that, entering 6 on the pfsense console isn't so bad. In some ways I'd feed safer with the full shutdown/restart, because sleep/resume can make assumptions about state that aren't justified (as you've seen from the adapter issue). It might take longer, but I'd shutdown the VM client, then halt the pfsense from the console, and reverse the order on restart, because then the state is better known.
The VM client is perfectly happy after a suspend and resume and so is the LAN side of the pfsense VM, you can access the webgui immediately. The WAN side only is in trouble. You can manually set the static IP there by typing 2 and then 1 every time, or even get a dhcp IP from the ADSL router from that menu. It's just a pain that you must do it over and over after every resume. About as much of a pain as shutting down manually. Wondering if there is a "wake up from sleep" script somewhere in pfsense to edit.
