Thanks, I set it up like this: [image: PO3agBs.png] [image: UqdPjjl.png] [image: S3jNLy3.png]

I have this board as well.  I initially had this issue with the 64bit version, but when I reinstalled with the 32bit version I got a dhcp address on my wan link right away.  I did not have to change any ip v6 settings.

Yeah it is true, it creates the rule for you - doesn't mean there is not two rules ;) Do with it what you will, combinations of possibilities are almost endless..  But I can tell you, you get some other engineer that finds this - and he is going to go WTF were they smokin??  ;)

Hmm, not a significant number of errors then. I would suggest it's problem at their end. Do you have access to the modem web interface? You could try pinging that or checking its loading. Try changing your monitor IP to something other than the WAN gateway, say 8.8.8.8. The gateway router may be, justifiably, prioritising ping responses far below everything else. Steve

pfSense only supports X86 hardware and all the 'mifi' units I have ever seen are some type of SoC, ARM or MIPS. To use pfSense as a captive portal you need an additional X86 box that would use the mifi as its WAN and provide wifi on its LAN. You can use almost anything you have to hand for that box but you probably want something portable like say an Alix box. http://store.netgate.com/Desktop-Kits-C82.aspx Alternatively it may be possible to run the captive portal directly on the mifi using an alternative firmware such as OpenWRT. It depends entirely what the actual hardware you have is and whether you have done this sort of thing before, it can seem a bit daunting the first time!  ;) E.g.: http://wiki.openwrt.org/toh/zlmnet/mifif10n If you have a device that can run OpenWRT then there are several captive portal solutions available for it. Steve

Some research later. It looks like I'm well behind the times on this, schedules are now handled by pf not ipfw so you should have no problem. This has been the case since 2.0: @https://doc.pfsense.org/index.php/2.0_New_Features_and_Changes#Firewall: Schedule rules are handled in pf, so they can use all the rule options. Steve

Can you post screenshots of Interfaces->(assign)  Interfaces-(assign)->VLANs and the WAN, LAN, and OPT interface configs?

And naturally on further inspection I find it to be my fault. Ram disks are set to 512mb and ntop was running on said ramdisk. Neither of which are defaults.

@skysurf76: Please make whatever change is necessary so this doesn't happen to anyone else.  I've done 100's of port forwards in my life with no issues, and even did standard port forwards for xboxs with pfsense in the past and didn't have issues.  This was infuriating. What you call infuriating is actually a feature. https://doc.pfsense.org/index.php/Static_Port The last paragraph on the above web page is what you want to read.  You should have made a static port NAT rule for just the IP of your brother's Xbox, not your entire LAN subnet.

How are your subnets arranged? Either of these pfSense installs transparent? Do you have the correct update URL set in System: Firmware: Updater Settings: ? Try this: https://doc.pfsense.org/index.php/Controlling_IPv6_or_IPv4_Preference Steve

The only way anyone would recommend to do that would be to run pfSense in a VM and run another OS in another VM as a network share. There is no capability to it in pfSense and adding such capability is very much not recommended, though it has been done. Steve

Thanks for your quick replies guys! I actually found the problem. I couldn't see it at first, not until I logged in to one of the VM's and got the "shutdown alert log" or whatever it's called. In Windows when you boot up after dirty shutdown. This told me I've had a power failure, and looking a bit further I saw that the vlan settings on the vswitch in vmware was pretty much fu*ked up. I set it right and did a controlled reboot, and shalom. I'd say you were correct heper :)

If your on a cable modem and it is a bridge you might want to avoid using 192.168.100.0/ as a subnet if you still want to be able to access your modems gui. most bridge modems answer to 192.168.100.1

There is no way to do what you describe. If you post the link, we can offer further info.

Had to change the baud rate for my serial console in my BIOS if anybody else is having this issue.

So I have added multiple nics both physical and virtual to my esxi host and to the pfsense vm. So depending on what vswitches you connect your physical too and then how you assign them in pfsense doesn't really matter.  You can assign whatever nic you want to the lan, or opt, etc. So when I first brought up pfsense virtual it had em0 and em1 – I then added 2 more virtual nics in esxi.  em2, em3 -- see how assigned in screenshot attached. The you can assign them to whatever vswitches you want in esxi, does not matter if physical nic on this switch or not - for example my dmz vswitch does not connect to the physical world.  But pfsense sees it as interface on my lan, etc. When you add new virtual nics to the vm, reboot pfsense and it will see them - then you can assign them however you want in pfsense. [image: assign.png] [image: assign.png_thumb]

@elgaup0: Thanks guy's problem solved. I have deleted the failover rule, added general pass rule, then failover rule. now i can ping hosts. Your "general pass rule" needs to not be too general - it should be like suggested by Johnpoz and myself - just for destination "local LAN subnets". If it is very general and matches destination any, then that rule will pass everything, and no packets will get processed by the next rule into the Failover gateway group. Just suggesting you check how "general" that rule is and that your Failover actually works when 1 WAN goes down.

@stephenw10: Yep. Though I fully understand why you might be hesitant to try it in the middle of a work day when the box has an undiagnosed issue.  ;) Steve Sure, but if the thing is really breaking every single day anyway, I'm honestly confused as to why he hasn't just turned it off at a failure point.  Either the backup box will work or it won't.  Better to find out now than later when the first box flakes out permanently.