Ok noted. Thanks again!

I had this issue with Comcrap. When I switched from a hardware firewall to my pfsense box on esxi I had to reboot my cable modem 2-3 times and spam the "dhcp renew" button in pfsense for it to grab an IP. I can't speak for other ISPs but it has something to do with Comcrap using sticky IPs that are tied to the MAC address of the device requesting a DHCP IP.

I noticed that if I switch back to the hardware firewall, I revert back to an old "dynamic" IP, and if I switch back to pfsense I get the same new "dynamic" IP. I put dynamic in quotes because even though it's not considered static, I always get the same IP based on the firewall I'm using aka sticky IP

root@pve-dol1:/var/lib/vz/template/iso# ip link show eth2 2: eth2: <broadcast,multicast,up,lower_up> mtu 1500 qdisc mq master ovs-system state UP mode DEFAULT group default qlen 1000     link/ether 0c:c4:7a:75:8b:90 brd ff:ff:ff:ff:ff:ff     vf 0 MAC 0c:c4:7a:75:8b:9a, spoof checking on, link-state auto     vf 1 MAC 0c:c4:7a:75:8b:9b, spoof checking on, link-state auto     vf 2 MAC 0c:c4:7a:75:8b:9c, spoof checking on, link-state auto     vf 3 MAC 0c:c4:7a:75:8b:9d, spoof checking on, link-state auto root@pve-dol1:/var/lib/vz/template/iso# ip link show eth3 3: eth3: <broadcast,multicast,up,lower_up> mtu 1500 qdisc mq master ovs-system state UP mode DEFAULT group default qlen 1000     link/ether 0c:c4:7a:75:8b:91 brd ff:ff:ff:ff:ff:ff     vf 0 MAC 0c:c4:7a:75:8b:9e, spoof checking on, link-state auto     vf 1 MAC 0c:c4:7a:75:8b:9f, spoof checking on, link-state auto     vf 2 MAC 0c:c4:7a:75:8b:92, spoof checking on, link-state auto     vf 3 MAC 0c:c4:7a:75:8b:93, spoof checking on, link-state auto</broadcast,multicast,up,lower_up></broadcast,multicast,up,lower_up>

Nevermind, solved my own problem again, after I manually assign MAC to VF…. the live cd installer works...  shame on me

It's not supposed to show anything in kldstat. The vmxnet driver is built in. The other kernel modules aren't all that useful and some of them cause stability issues. If vmware-guestd is running, open-vm-tools is fine.

Another thing you need to make sure of is that the modem from your ISP is in bridge mode as well. If your using DSL the login info four your DSL needs to be put into PFsense. I am successfully running PFSense at home

Centurylink–>PFSense Virtual interface 1--->PFSense virtual interface 2---> 16 port switch--> Lan and beyond

I installed pfsense with the basic installer, confiqured the WAN interface (PPOE with DSL Username+Password) and the Lan interface (Static + DHCP server) and was online immediately.
Hope this helps a little.

@adamsuail:

This looks very promising, when I get my new reg, i will try this first then ESXI and my last option is the same windows 10 host with guest VMs.

https://youtu.be/LuJYMCbIbPk

Ummm, looks interesting, that's something new to me :)

Thanks! ;D

That needs kicked up to FreeBSD, not a bug we can do anything for.

You might be able to disable checksum offloading, and while you're at it make sure TSO and LRO are always off

Dear gjaltemba & alfjonny
I have machine that runs Windows Server 2008 R2.
In order to run Pfsense over Hyper-v we have two scenarios:

Giving Legacy Network Interfaces for PfSense VM

Give Real Interface for VM with full speed.

Drawbacks

With Legacy Interface we don't have to install BIS/ Since its built in

With Legacy Interface Pfsense can control and discover the interface, but Mostly the IRQ will be wrong which reveals for no way to make transparent MODE

With dedicated Interface (Full Speed), Pfsense Can't control it until installing BIS (Since FreeBSD 10.2) it build in.

Result:

Pfsense does not has Ports so no further drivers can be loaded.
Example IBM Server RAID controller

Using transparent mode not working with hyper-v

Suggestions
have you ever make testing for this methodology?
And what is yours suggestions?

Wishes

What??

Dude if you want your firewall to be transparent - then make it TRANSPARENT… it is not the GATEWAY in that sort of setup..  Its a BRIDGE!!!

x.x.x.222 --- pfsense (bridge) ----- x.x.x.209, points to .222 as its GW, it doesn't point to pfsense!!

Or if your /28 was actually routed to you!!!

ISP x.x.x.1 - transit network x.x.x/30 - x.x.x.2 pfsense x.x.x.209 ---- x.x.x.208/28 devices

If your wanting to use pfsense as a gateway, then your going to have to NAT if the /28 is not routed too you!!!

Thanks, so %wait doesn't matter as much as %vmwait which looks fine to me!

Just want to make sure my pfsense VM is happy with it's resources. tx for the links.

Exactly and now your running non supported configuration so either go back to version of pfsense that is supported on your esxi version, or update esxi to support pfsense version your running.

@papotz:

Hi! actually i'll run pfsense with the host OS (Windows Server 2012) my VM machine will also run Windows server 2012 but will configure exchange server 2013 and AD DS separately with 2 VM.

I can't answer your question, but I was a little surprised by this.  Are your sure you want to run your ADDC, Excchange Server, and pfSense on the same physical machine?  MSDN and Technet forums are full of warnings against doing such a thing, even under virtualization.  Perhaps you are a developer doing this on purpose as a laboratory environment, but for actual deployment you might want to reconsider your provisioning strategy.  I am setting up a similar arrangement, but using a separate physical box dedicated as my ADDC.

@cmb:

VMware's quirky with vmxnet3 NICs on newer versions if you add NICs later on. If you add one, you can end up reordering some or all of your other NICs (eg. vmx0 becomes vmx3). Make note of the MACs and associated NIC, then check the MACs in 'ifconfig' output after you power up the VM, then you can associate what their actual order is and re-assign the NICs accordingly.

You're a genius and a life saver! Thank you so much! This completely fixed it  :)

5.5 with Update 3a?  Are you using E1000 or VMXNET3 NICs?

Hi,

I have successfully set up a transparent firewall environment on ESXi 6.

However, I set Promiscuous Mode to "accept" on the vSwitch level, not on port group level - both for the WAN-side vSwitch and the LAN-side vSwitch. Maybe you try that, not sure if it makes a difference?

Best regards

@macralf, did you ever find out what caused this? I am facing a similar problem.

Did either of you find a resolution for this issue?