I seem to have somewhat similiar problem: https://forum.pfsense.org/index.php?topic=97431.0 Began after last update.

@Derelict: Sounds like Wi-Fi just isn't your thing. (Did you disable the DHCP server on the TP-Link?) (I said "AP" (Access Point).  Not "Router") Correct. I never had much time fooling around with it. Except once trying to turn a usb-dongle into a AP..after many hours/days of cursing, it worked…but whatever. Yes, I disabled DHCP. Androids can finally connect. Now it's just the darn Chromecast left. I remember some setting when I had the AP running at the pfsense which made the Chromecast work, can't find it on this cheap TP-Link-thing though.

"ftp bounce attack, victim is 192.168.1.4:2266, action, DROP" Opening and forwarding the ports would be one thing, but then setting up rules that are matching exactly this ports and services is also a must be. Could it be that only the firewall rules are not matching this behavior? Using FTP.exe imply to me that you were also able to use something likes FileZilla Server software because it is also free of charge and offers on top S/FTP service. Also a script that opens a SSH connection to your home firewall would be nice running and able to do.

Yeah. Check for a BIOS update. If you've changed anything in your BIOS, try changing it back, or just resetting the BIOS settings to defaults.

I used standard procedure to install in FreeBSD OS correspondíng to the pfsense versión.  Look into the ports folders for the MySQL server version in the port to identify the correct name of the package. It will install the dependencies.

Good question! You are exporting the logs to some external syslog server? Steve

@pigdogs It's not obvious what equipment you're using here. The most recent BT hubs have the VDSL modem integrated so you'd need to either put it in bridge mode or setup pfSense behind it ina double NAT scenario which is not ideal. As the others have said you want to have a separate VDSL modem really such as those BT supplied for use with their ealier hubs. Steve

@doktornotor: Because it's extremely well hidden in the GUI! Interfaces - WAN - scroll to the bottom. :o ::) I've assumed this an written it above, but was not sure if it helps.

May actually be in SMB3.0 http://blogs.technet.com/b/josebda/archive/2012/05/13/the-basics-of-smb-multichannel-a-feature-of-windows-server-2012-and-smb-3-0.aspx SAMBA 4.0 is currently working on SMB3.x, but doesn't support multi-channel yet https://wiki.samba.org/index.php/SMB3_kernel_status#SMB_3.0

Usually that's because either something else is using that IP address, or it's not really usable in that subnet (e.g. it's a null route or broadcast address) Can you show what IP addresses you are using and the subnet mask? You can block out the first three portions, the last IP part is what is significant here.

Thanks! This helps a ton!

Nested VMs on your side would do NOTHING to hide your connection point..  Hiding your traffic from your connection provider requires just one layer of encryption.  putting a tunnel inside a tunnel inside a tunnel is pretty pointless.. Create a tunnel to a trusted endpoint on the outside of your connections providers network.  If you then want to bounce a connection off of that through multiple proxies, turn tor through that connection even to hide your actual connection point from the tor network or proxies you use. But running nested vms to accomplish this goal is just wasted resources time and performance.

@doktornotor: No idea where do rules on OPTx come into play here. This line should have been 1st, then it would make more sense. Personally I'd not bridge the way you have as you can isolate traffic more with things like snort using custom rules & schedules along with various fw rules a little better and dhcp on each OPTx interface In answer to your question, its because of the bridge problem, which you mentioned to the OP. Of course this might help as others have reported things not working properly since freebsd 9, that might explain why bridges are a pain, bit like the states not working as expected. https://www.mail-archive.com/freebsd-pf@freebsd.org/msg05983.html Edfit. Might also be useful. http://home.nuug.no/~peter/pf/newest/bridge-freebsd.html

@SageIT: I forgot to mention…my previous gateway, the one I'd like to replace with the pfsense box, is just an asus AC-rt66u router running dd-wrt.  It has an ip address of 192.168.0.26, and all of my clients on the LAN are static IP's, pointing to that router (0.26) as the gateway, and to my primary DC for dns (0.2)  I have tried changing the gateway on my server to point to pfsense (0.41), as well as trying another PC set to dhcp...neither one will reach the internet.  The odd thing is...when i do an ipconfig /release/renew on a dhcp machine, it renews with the old gateway address (0.26), despite it being turned off and disconnected entirely from my network.  Am i missing something? Have you got the pfsense lan interface setup with the default ip address range ie 192.168.1.1 or have you changed the lan interface to 192.168.0.26 to be identical to your old router?

i'm a little bit further, after giving my laptop a static IP. in most cases all AP are acceceble but not pfsense. there is one thing when i ping them there is sometimes a timout and most of the time the ping time is at 250 ms

"So the performance hit of the resolver walking the chain is not actually all that significant" Exactly and the resolver will cache it as well for the ttl of whatever is you looked up, so the guy next to you also using your resolve that wants to get to www.pfsense.org the resolver doesn't have to look it up again.  But if you have sites that have low ttls and shitty dns servers there can be a hit now and then when you first go to look it up your browser times out on it, etc. Where if its popular and lots of users hit it with the common forwarder your using - which is normally like 1000's and 1000's of ISP customers vs just the hand full of machines using your resolver. As stated out of the box pfsense blocks all unsolicited inbound traffic - so nobody can query your resolver from the outside unless you open up the firewall and even have your resolver listen on your wan.  You can pick what interfaces it listens on in the pfsense page for it.  Why should it even listen on your wan??? I would not use a forwarder unless you wanted to leverage filtering they provide, or you have a really shitty network connection and doing all the dns yourself ends up being slower then just asking your isp dns. [image: listeninterfaces.png] [image: listeninterfaces.png_thumb]