Any firewall rules on your WAN interface for your PBX? Since your using Siproxd, make sure the destination address is "WAN address".

Yes the gateway would be whatever you make pfsense IP in the 192.168.2.0/24 network. VM networking is very simple on esxi… Just think as your vswitches as real switches and the network card you connect to them are just uplinks to your real switch.. So with pfsense on your esxi host you end up with something like attached.  Blue stuff is virtual switches and nics, pfsense is VM as well. While your vmkern could have a gateway - to be honest unless you want it to have internet access no real reason to point it to pfsense lan IP.  If your just going to ba accessing it from something else on the 192.168.2.0/24 network be it virtual or physical.  See attached my esxi host vswitches.  While I do have my vmkern broke out on its own vswitch and its own physical nic uplink.. Its still on my lan network 192.168.9.0/24 in my case.  So pfsense has 192.168.9.253 on lan which is gateway for anything on that network.  While it has other networks as well for example the dmz is 192.168.3.253 -- see attached pfsense interfaces. The only difference in your setup and mine is your behind a double nat, since you don't have a public IP on pfsense wan.. So more than likely you would want to make the pfsense wan IP the dmz host in your isp device.  So that all ports get sent to pfsense wan.  Or if you want to do any port forwarding you will have to do both on your isp device and pfsense. [image: typicalesxi-doublenat.jpg] [image: typicalesxi-doublenat.jpg_thumb] [image: esxinetworking.png] [image: esxinetworking.png_thumb] [image: pfsenseinterfaces.png] [image: pfsenseinterfaces.png_thumb]

@zer0: @Derelict: Yeah you need a separate pfSense interface for your guest wi-fi.  Something like this: https://forum.pfsense.org/index.php?topic=88942.msg491700#msg491700 Thank you for reply, did you mean a separate NIC or a VLAN on the LAN interface. Either. Also, can VLANs actually work given my setup and switches? No idea I didn't research those switches. They need to support 802.1q to do VLANs.

I can see VIP and the desired server on the subnet are different addresses VIP .110 -> "real" .100 But I can't see how you can make it work if they're supposed to be the same VIP .100 -> "real" .100 for certain ports, which I think was the original question. After rereading the OP, I see this is indeed what he was probably after, the "Fantom" IP is a Virtual IP under "Firewall>Virtual IPs".

This is a 32-bit Intel system running a full install. 1 gig of RAM. The really weird thing is that the RRD graphs still show a completely steady low mbuf usage, much less than the limit set by kern.ipc.nmbufs.

But "verb 1" is a valid config entry, "verb default" isn't.

Really solid, we're days away from release candidate and not likely to make any changes once we hit RC, with release soon after.

Please get in touch via support.

Thank you for your reply divsys, @divsys: In order to get the VLAN solution working properly, you're going to need a VLAN capable switch of some kind. Can a router with dd-wrt software opearte as a managed switch? or am i far from it? Once you moved away from a "Single NIC" installation, your pfSense would have firewalls rules like a more traditional setup, WAN blocked and LAN allowing outgoing. did "pfctl -d" isnt this supposed to drop all firewalls? the USB NIC approach, they're pretty hit I was hoping that the fact that i get the message on connection was a good sign, isn't it? You're probably better off finding a reasonable VLAN switch and working forward from there. Im probably better off buying a more appropriate pfsense machine, but the whole point was to utilize stuff laying around :) thanks again

That's the thing, it cannot be 100% scheduled - it will be based on users checking-in to work, as we want to make sure they actually got to their machines to limit the "premium" bandwidth use. I can have all of the rules pre-set, I just need to selectively disabled/enabled.

@Derelict: Run a packet capture on VLAN60 and get a new or renew a lease. Great idea, will do that tonight and report back.

@mikesm: It sounds like you have the SMC router from Comcast.  While you can try putting it in bridge mode, my advice is to replace it with a pure cable modem, like the SB6183.  COmcast can provision that with static addresses if needed, and you don't have to fight the the SMC trying to act as a router. This se up will be more reliable, and you will avoid issues with double NAT and other problems by Comcast trying to provide "value added" routing when PFsense is far better a router than that POS SMC box.  :) Thx Mike You know what's funny? We just did that. Replaced it with a ubee. Finally got 2 charter reps to admit that SMC has a firmware issue with static ips. Network came back up immediately on that ubee modem when we got it provisioned :)

nginx is so good at its job of being a proxy, that nginx is probably the best place to filter your requests. Any other package that you use to filter it will make it slower. And I'm not sure what issue you're describing. nginx is a reverse proxy not a normal proxy. Completely different. You can't access the "Internet" through a reverse proxy, you can only access preconfigured sites. If you want, redirect them to https://www.fbi.gov/ or something.

^ What???  Did you read the thread?

DHCP leases can be viewed in pfSense by navigating to Status > DHCP Leases. Thanks…

The fix we put in to make pw's writes safe (fix for passwd file corruption) also made it slow in some circumstances, especially with large numbers of users. Short of thousands of users, I haven't heard of any delays of minutes attributable to that. In FreeBSD 10.3, a different fix for that problem has been implemented which doesn't have the performance issues in those circumstances. I've put it through our power cycle test rig upwards of 3000 power cycles immediately after passwd write, and it still survived fine. I haven't tested large scale performance, but the FreeBSD developers who reviewed and implemented the change have. So any portion of it attributable to that will be significantly faster in 2.3.

@cmb: Yes. In the plans for the future. Any idea of a possible time line? :) Thanks

No need with modern SSDs to disable logging. That option disabled all logging except filter.log, I just fixed that. https://redmine.pfsense.org/issues/6018