• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

pfSense running under ESXi 5

Zarathustra[H]

Extremely [H]
2FA
Joined
Oct 29, 2000
Messages
42,303
Hey,

Is anyone else doing this?

I have been running this setup for a while, and I really like it, but I have been having some issues. My posts on the pfSense forums have not helped me much, so I figured I'd try here.

Essentially, pfSense randomly goes down.

I experience uptimes of anywhere between an hour and 4 months, but ever so often it goes down.

Symptoms are as follows:
- ESXi is up, and other VM's are running just fine.
- pfSense appears to be running from the shell and web interface
- Devices with active DHCP leases continue to work, until they are disconnected and reconnected again, at which point they don't get a valid IP address, and can access the internet.
- A quick restart of the pfSense VM buys me another ~1hour to 4 months of uptime.

Any thoughts on this?

Much appreciated,
Matt
 
are you running DHCP on the pfsense box itself?

We run pfsense in front of our vdi infrastructure and have only had a few minor issues with it, one being ospf causing weirdness with dhcp to our vdi images and us having to add a static route to the pfsense box so vdi could still get dhcp over the network. We werent running DHCP on our pfsense however.
 
Hmmm, dhcp via WAN? One thing I've noticed freebsd-based routers/firewalls having (rarely though) is inability to get a DHCP lease on the WAN. Rebooting clears it up. If there is no WAN link, it's possible other pfsense things stop working too.
 
I have 2 that run on esxi5 (well 3 now, the 3rd is only a week old), no lockup issues that I've seen.
 
are you running DHCP on the pfsense box itself?

We run pfsense in front of our vdi infrastructure and have only had a few minor issues with it, one being ospf causing weirdness with dhcp to our vdi images and us having to add a static route to the pfsense box so vdi could still get dhcp over the network. We werent running DHCP on our pfsense however.

Yeah, I am using it for home purposes as an all in one router/firewall/DHCP box. It simply just replaced my consumer routers when none of them worked the way I wanted.

I like the performance and feature set, but this one little issue is bugging me.
 
I have 2 that run on esxi5 (well 3 now, the 3rd is only a week old), no lockup issues that I've seen.

Do you have the network device direct IO mapped, or does it go through a vswitch?

I guess it is possible it could be a hardware issue, but I did my research and picked up a dual port Intel EXPI9402PT PCIe gigabit NIC for it. Right now it is running through a vSwitch on each side though as my server doesn't support VT-d.
 
Mine runs through a vswitch- just have both set for promiscuous mode. pfsense does all my DHCP, most reliable fast performing dhcp ive ever had.
 
Ditto what ChRoNo said. Mine's running on an old Rackable Sys server with Broadcom NIC's. Run through a separate WAN vSwitch and set for Promiscious mode.

OP, what kind of vNIC did you assign to the VM?
 
mine works great as well, I have recently upgraded to the 2.1 beta branch and it works great and seems a little faster. Have you loaded the openvm tools package? I am not sure if it is necessary but I have always loaded it.
 
Zarathustra[H];1039005347 said:
Do you have the network device direct IO mapped, or does it go through a vswitch?

I guess it is possible it could be a hardware issue, but I did my research and picked up a dual port Intel EXPI9402PT PCIe gigabit NIC for it. Right now it is running through a vSwitch on each side though as my server doesn't support VT-d.

vswitch on all.
 
Mine runs through a vswitch- just have both set for promiscuous mode. pfsense does all my DHCP, most reliable fast performing dhcp ive ever had.

Hmm.

Mine are not in promiscuous mode. Can this make the difference? What is your reasoning for using promiscuous mode?
 
Ditto what ChRoNo said. Mine's running on an old Rackable Sys server with Broadcom NIC's. Run through a separate WAN vSwitch and set for Promiscious mode.

OP, what kind of vNIC did you assign to the VM?

Both of the virtual NIC's for my pfSense box were assigned as E1000 as I heard BSD systems tend to have problems with VMXNET3.
 
Can you load a parallel instance and MANUALLY transfer your settings to it and cut over to it? Maybe some odd-ball install glitch?

As Rody mentioned, I installed the OpenVM tools as well.
 
ESXI 5 has a built in firewall. Lock it down and it is secure.

That, and the attacker would have to know ESXi is there in order to take advantage of any vulnerabilities it may have.

From the outside, it looks and behaves like the guest it is running (in this case pfSense).

This is especially true if you direct I/O map the NIC. In this case - from a network perspective - there is no ESXi, only pfSense.
 
is esxi secure enough to run it facing the wan like that?

hard to say for certain, but I don't lose any sleep at night over it, it's not like the esxi host itself is exposed to the wan (or at least shouldn't be). I would guess any vulnerability found would be patched up pretty quick by vmware.
 
it's not like the esxi host itself is exposed to the wan (or at least shouldn't be).

Exactly. While nothing is unhackable, in this case if direct I/o mapped it is as if the NIC is connected directly to the pfSense guest.

If not direct I/O mapped the adapter (and ESXi) doesn't even get an IP address (except for the management console which would be on the LAN side anyway). The IP is assigned to the guest on the other side of the vswitch.

Again, nothing is unhackable, but regardless of method I would think anything incoming over TCP/IP would be presented directly to the guest and it would not be immediately apparent (unless the guest was compromised) that VMWare was involved at all.

I would imagine direct I/O mapping being slightly more secure though as it would not depend on VMWares virtual networking, if a vulnerability were ever found there.

Essentially, my laymans take is that any vulnerabilities on the guest OS would be of greater concern than the small risk VMWare may or may not introduce on top of it.
 
Considering that there are a number of Virtual Firewall appliances from the major vendors, I'd say the risk is minimal if managed correctly.
 
Back
Top