Thanks for the help guys. Bridging the interfaces is exactly what I needed. I was able to route traffic with no problem and have all of my rules setup as I wanted them. We can close this topic now

Ok, found it on another thread: remove network cables before install.

For / on the Hamakua, I believe so, due to its BIOS limitation as far as I remember. You can try a larger size, but it may not work.

Personally I would choose ESX. TO me it seems more stable and compatible than the rest.

Using Pc engines APU1C with latest bios Pfsense 2.1.2 x64 full install edition on a 20 GB USB 5400 rpm spinning HDD My boss ran the install script from webgui over the weekend to 2.1.3 and now it cannot find it's kernel. Running squid, lightsquid  and openvpn Thank god he didn't try it on the other one, 5 hours drive away in Toronto…  :-[ Any idea when the gold stars are going to be added to the forum? ** Edit This was caused by not enough space. The pfsense partition I'm using is just over 4 GB since it was originally dd'd from a SD card. I restored to a HDD image from last week and then I deleted the squid cache tree ( rm -rfv /var/squid/cache/* ) Then I invoking the upgrade script and it completed without issue.

Ok I got Squid to work. This thread may be considered closed.

That's one of the reasons I often take the "extra" (120-150 secs) time to do a manual install. It reinforces all those automatic details that happen behind the scenes - and come back to bite you  ;)

@Supermule: May I ask why?? The geek factor? It does sound like a fun project, though I wouldn't want to run it myself that way myself. I would want it installed locally so I don't have to worry about the NFS server going down and bringing down the whole network since the firewall/router would go down as well. In terms of actually getting it to work, try getting a regular FreeBSD machine booting via PXE first. I forget exactly how to do that, I'd have to check how I did it at work. Then just apply that to pfSense and it should work, unless the code that allows it has been removed. Once again, on a firewall, I don't think I would want to rely on another server working in order for it to work.

I'm with Steve on a possible hardware issue. As well as the memtest, I'd suggest a burnin routine.  The UBCD (Ultimate Boot CD, Google should easily find it) has some good all in one tools that are helpful in these scenarios. No point in using pfsense as your trusted firewall if you can't trust the hardware it runs on.

If you set it up with only a single interface it will appear as WAN but it will let you connect to the webgui via that. There won't be a DHCP server running on that interface so you'll have to set up a client with a static IP to connect to it. Once in the webgui you can add the wifi interfaces and swap the NIC assignments around. Keep in mind though that as soon as you add a further interface the default firewall rule that allowed you to connect to the WAN will move to the LAN so before you do that add a firewall rule yourself on the WAN if you'll still need to connect via it. What wireless NICs are you using? Many 'N' NICs are unsupported. Steve

FWIW, I ran into this same issue on a couple firewalls that were upgraded from 2.0.3 to 2.1.3. But not all of them for some weird reason. Seems to affect most traffic/packets graphs on the affected systems. Will try deleting the .rrd files I guess. There isn't a way to manually upgrade the affected .rrd files?

The vulerability was only introduced with 2.1 so you should not be vulnerable to heartbleed. Additionally OpenVPN is not vulnerable in its default configuarion: https://forum.pfsense.org/index.php?topic=74796.msg409174#msg409174 However that doesn't mean that your outdated install isn't vulnerable to all the other fixes that have gone in since 2.0.2.  ;) Steve

How do you have virtualbox configured for networking  I would assume the hosts interfaces are bridged to both interfaces and has no IP on its os for the WAN, and an interface on the LAN bridged to LAN of pfsense of pfsense with an IP on the lan interface of pfsense. If this is the case you should have no problems connecting to web gui of pfsense from your host machine.

@jimp: I've thought about that before several times. It would be useful, but it would be a lot of extra work and though it might help in some cases, it would make other parts more difficult/less intuitive. (e.g. when does a protocol choice on a rule get trumped by a protocol choice in an alias?) That's exactly what I meant. The priorization of that would be tricky to say the least. As PF rules don't mingle protos and port together, that would mean extra work to unravel the aliases into actual rules and what is the order of them. If PF's syntax were more along the lines of " <action>on <interface>src <ip alias="" table="">port <port group="" alias="">to <ip alias="" table="">port <port group="" alias="">[flags <flag flagmask="">]" and [port] was defined not as numerical but as combination like udp/137 or tcp/443, that would be easier to achieve in the GUI or with aliases alltogether. But as the "proto" section declares the protocol for the rule, it's quite a bit more complicated.</flag></port></ip></port></ip></interface></action>

For the  gateway monitoring I have setup 750ms/950ms and it seems to be stable since a few hours. And I have setup back the hardware stuff, because of the rules "one mod only at a time  :)". More to come later …

Thank you very much!

No its an old BIOS update, I read the link you give on me, the last option to fix BIOS Disk is to update the BIOS, but luckily I install my pfsense and maybe if I get pfsense work it out, that's the time I will update bios and try to setup pfsense in the SCSI raid setup.

Thank you :)