MoCA.  Screw the powerline stuff. http://www.amazon.com/Actiontec-Ethernet-Adapter-without-Routers/dp/B008EQ4BQG And a high-pass filter for your entry point: http://www.amazon.com/Filter-MoCA-Cable-Coaxial-Networking/dp/B00DC8IEE6

Thanks for the replies, anything is an option right now. After another long wait i got: Fatal error: Maximum execution time of 900 seconds exceeded in /etc/inc/xmlparse.inc on line 0 Starting CRON… done. So you are probably right, i just don't know what could have caused it which is a shame. Better get started. Thanks

Thanks for the pointers about Snort. Blocks and passes were observed in logs.  Once I noticed the issue, I logged all LAN traffic. Still not understanding how my LAN traffic would be effected by Snort on the WAN? Please note that the router is now operating correctly through a reinstall and configuration from previous saved configuration including Snort.  Therefore I can not repeat/test.  Heavy handed yes, but I needed to get onto real work, not debugging a firewall and not replying to emails, etc for days. Peter

the 'nanobsd' versions of pfsense generally don't write to disk (a lot). but there are downsides to the nanobsd/embedded releases …. see: https://doc.pfsense.org/index.php/Installing_pfSense#Full_vs_Embedded_vs_LiveCD

Good night everyone, I was having the same issue after implementing the Hurricane Electric's IPv6 tunnel service. I ended up checking "Prefer to use IPv4 even if IPv6 is available" in System: Advanced: Networking. This solved my problem and I didn't have to deactivate IPv6. Good luck Francis V Garcia

Thanks Steve - it was a blind alley as I am trying to get an obscure FTP client working to a server behind pfsense rather than the other way round, which is what this option affects….

pfBlockerNG Service Watchdog

@Carreswag: … but im pretty sure it should still connect ... Well no, you have to decide a sensical setup first. Trial & Horror, with double routers, doesn't cut it. Suggest make it work with Bell-router, if signal true then replace Bell-router with pfSense.

If you are looking for a consultant, then I suggest you hire one. Otherwise RTFM. Its a 2-4hr job if they know what to do and can easily be done remotely. You just need one sitting at the office to establish the remote connection when switching from TMG to pfSense. @germain.safari: Hello, Currently we using TMG Server 2010 for publish our company website (using https and http), Exchange email, VPN for staffs to access company from outside, internet access and etc…. Kindly advice how can i take all those rules and policies from TMG to PFsense. Regards, GS

Yes I know this but how can I get the log of connection without it ? I mean that if I disable the transparent ip I will read that connection are coming from pf. I need that only for ipsec tunnel or for a specific address webservers that are behind haproxy have to answer back directly. I mean that if I'm on 192.168.x.x and connected via ipsec to pf the LAN side of pf having 10.1.x.x , on this network we have  haproxy working on port 80 and 443, if i try to do an http://10.1.x.x it won't respond back ( any other port like ssh do ). Best regards

https://redmine.pfsense.org/issues/4664

Like I just said, pfSense's captive portal is time-based, not usage-based.  There is nothing in the gui that will tell you how much a user has transferred because pfSense doesn't care.  It cares how long a user has been connected.

Many Thanks for your reply. Worked like a charm.

Hi hsale, Disabling ACPI in BIOS worked for me. Anyhow "Thermal Sensors" monitoring wouldn't work.

@cmb: @firewalluser: Govt's especially the military have far greater resources than most businesses. Which was exactly my point. They also likely wouldn't be so sloppy about it as to get caught repeatedly. You have to be deploying systems over and over again with the same security hole(s) that eventually someone scanning finds and owns. Unless you're a high profile target, no one's going to waste a high value 0 day on you. Every time you use it, it's more likely to be found out. Who needs a 0 day as you rightly point out below, but then do you buy the stories the Govt dont have the money for xyz? @firewalluser: I think that only one device namely a rpi was used to access and configure pfsense on the default lan and all other additional nics to internal machines had to be enabled to the extent I have detailed here https://forum.pfsense.org/index.php?topic=92804.msg517267#msg517267 would suggest reasonable precautions had been taken? I would call that reasonable precautions. That's far better than most people. Still plenty of ways to be compromised. Some incident response definitely would be justified to figure out how that's happening to you. Well if my hd's with packet capture data and others werent being trashed I'd be able to provide something, unfortunately my hd's keep being trashed, making it difficult to provide any such data for analysis. But if you needed a backdoor into a system, hardware is where I'd put it as its virtually impossible to inspect as this vid explains from 2007. https://www.youtube.com/watch?v=VV_v_OEOhH0 Wake on lan has been around years since 1996. http://en.wikipedia.org/wiki/Wake-on-LAN#History So do you (or anyone else*) have any suggestions to overcome the hw issues? Apart from using older hw and perhaps usb nics (although some would suggest not using them) I dont have any other ideas to avoid getting hacked which could prove the hacking methods used especially considering this post of mine from earlier on in the year. https://forum.pfsense.org/index.php?topic=88180.msg486376#msg486376 *Like I said to Kejianshi, the logical thing to do is unplug from the net.

I turned off ipv6 (deselect allow ipv6), and now firewall logging is working fine.  ???

@hal99: I asked in case it had any restriction or the wireless card has something else weird that prevents you from changing the MAC. The only situation where I've ever heard of MAC spoofing being a problem is on a minority of the crap Realtek 8139 100 Mb NICs. Even then it works, but you have to keep the NIC in promiscuous mode all the time for it to function with a MAC other than its own. The NICs we sell, wired or wireless, certainly won't have any such issues. @firewalluser: Without all the data how can you form a judgement? It's really far-fetched to think there are wifi exploits out there so awesome they can own you through the air (a type of vulnerability that's proven very rare to date), but so lame they're foiled by changing your MAC address.

There's a very good chance that drive is dead. You can try a reinstall, but that's about as low level of a failure as you'll see short of the drive not being detected at all. I'd run the HD diag tool from the vendor of the hard drive first, and only reinstall if thorough tests come back clean.

@wifiuk: I'm assuming 2.2.2 fixes these? from that link: "Solution: Update to pfSense 2.2.1" 2.2.1 fixed that one.