update: actually I have the bridge between wifi and ethernet fully working but: there is no way to tell the fw to pass connection to a server that resides on a 3rd lan over ethernet and block it over wifi. I mean the rule should be in the bridge tab so will work for both and filtering by ip or mac is not an option. rules on eth and wifi only works between the two (I can block any wifi from accessing a machine connected to eth for example). also sidesync does not work, I can see cp and smarphone tries to connect but no way. broadcast is the same because I had only assigned ip and dhcp to the bridge interface. should I assign ip and dhcp to both wifi and eth but on same broadcast? I can't try if it works because sidesync is not working so result will not change. I guess that if I do that I will have a gateway on each eth and wifi interface so I Can decide who can see server on the 3rd lan. IS this my fault or should this config work even if it does not? Also I am not abla to go over 600mbps without jumbos and with jumbo I trigger lot of problems in the wifi that is the only 1500mtu lan here (still not debugged) thank you for the time you put on this post  :)

Yes. Polling fixed it.

Thanks for the rapid feedback.  I was afraid that would be the answer.  I'm comfortable enough with the recovery process.  It's only inconvenient because the hardware I need to boot from the console is buried in the back of a room full of boxes right now, and I'm disabled.  I guess, I'll call a friend to come over and help dig it all out. Much appreciated. Dave

@Potestatem: Is there some setting I'm missing or something? Hard to say (based on the provided information) Check: https://doc.pfsense.org/index.php/Connectivity_Troubleshooting

I can't customize directly on the proxy servers that i want to monitor but your suggestion is a very good one and i will make some test to see if i can produce the report the HTTP monitor need across the proxy to that custom URL on a web server we own. Here an example of a simple script i run on the pfsense box that give me the right result but unable to get work using the usual HTTP monitor. #!/bin/sh GETPROX=printf "GET http://www.google.com\r\n\r\n"" | nc $1 80 | head -n1 PROXR=echo $GETPROX | grep "200 OK" if [ -z "$PROXR" ] then         echo 0 else         echo 1 fi

Have you tried with the Interface in promiscuous mode ? (as mentioned at the linked article)

I have no trouble checking, downloading, nor installing packages, via: ../pkg_mgr.php In General Settings I have "Do not use the DNS Forwarder or Resolver as a DNS server for the firewall" left UNCHECKED. DNS Fowarder is set for all interfaces, including outbound. I am able to use DNS Lookup for: updates.pfsense.org  127.0.0.1    2884 msec 208.67.222.222    150 msec 208.67.220.220    95 msec (I'm on a high latency connection.) I'm able to ping, IPv4, from localhost: PING updates.pfsense.org (162.208.119.39) from 127.0.0.1: 56 data bytes 64 bytes from 162.208.119.39: icmp_seq=0 ttl=47 time=81.618 ms 64 bytes from 162.208.119.39: icmp_seq=1 ttl=47 time=82.650 ms 64 bytes from 162.208.119.39: icmp_seq=2 ttl=47 time=106.709 ms 64 bytes from 162.208.119.39: icmp_seq=3 ttl=47 time=119.578 ms 64 bytes from 162.208.119.39: icmp_seq=4 ttl=47 time=84.123 ms 64 bytes from 162.208.119.39: icmp_seq=5 ttl=47 time=83.495 ms 64 bytes from 162.208.119.39: icmp_seq=6 ttl=47 time=84.426 ms 64 bytes from 162.208.119.39: icmp_seq=7 ttl=47 time=83.794 ms 64 bytes from 162.208.119.39: icmp_seq=8 ttl=47 time=156.653 ms 64 bytes from 162.208.119.39: icmp_seq=9 ttl=47 time=107.951 ms –- updates.pfsense.org ping statistics --- 10 packets transmitted, 10 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 81.618/99.100/156.653/23.155 ms I have IPv6 disallowed. Traceroute, IPv4, localhost, with Reverse Address Lookup, and Use ICMP, worked, showing 20 hops: 20  162.208.119.39 (162.208.119.39)  104.809 ms  132.864 ms  103.264 ms I'm using:      2.2.5-RELEASE (i386) built on Wed Nov 04 15:50:18 CST 2015 FreeBSD pfSense.localdomain 10.1-RELEASE-p24 FreeBSD 10.1-RELEASE-p24 #0 f27a67c(releng/10.1)-dirty: Wed Nov 4 16:13:40 CST 2015 root@pfs22-i386-builder:/usr/obj.RELENG_2_2.i386/usr/pfSensesrc/src.RELENG_2_2/sys/pfSense_SMP.10 i386 This was a clean, full install.  Right "out of the box", it couldn't check.  All I did at initial install was set the minimum interfaces, to get to the GUI web configurator.  You know, even the last version I had, couldn't check updates. NOW.... on ../system_firmware_settings.php The setting to allow, Unsigned Images, is NOT checked.    The setting to disable, Dashboard Check, is NOT checked, obviously.  BUT, I've tried it WITH, and withOUT:  "Use an unofficial server for firmware upgrades" Setting the dropdown to the correct i386 sets that setting checked, and the url to:  https://updates.pfsense.org/_updaters I see an ../amd64 subdir', for there, but no ../i386 I again tried it manually, ../system_firmware_check.php , with the default, or seeing, filled in, https://updates.pfsense.org/_updaters Downloading new version information…done Unable to check for updates. Could not contact pfSense update server https://updates.pfsense.org/_updaters I noticed that just going to https://updates.pfsense.org shows a "hello world" type page, with the text: updates.nyi.pfsense.org and I noticed that in one of the traceroute results. So, I tried, as a custom update address: https://updates.nyi.pfsense.org/_updaters , which is valid, and shows the same index, as the default link, above.  The resulting output of  ../system_firmware_check.php was: Downloading new version information…done Unable to check for updates. Could not contact custom update server. Hmmm…  I wonder about the certificate, and, I wonder... [image: 404image.png] :P

@JuSt: @dkrizic: I forgot to mention in the other thread: I also have Bios 8 (not 8.1) Hi, any news about glitches? I want to buy a 550e and make sure its running without problems. Is your setup stable until now? thx Stefan A little update on the problem with stability. With Bios v8.0 there is no option in the Bios for enabling ACPI, that's why i had good results with that Bios version. But later on, i discovered that the combination of ACPI enabled and the option "interfaces" enabled, under "screens" in the package LCDprov dev was causing this stability issue. Solution for the x550e is : Do not check "interfaces" under "screens" in the package LCDproc dev Solution for the x750e is : Do not check "interfaces" under "screens" in the package LCDproc dev Put these 2 lines in your /loader/boot.conf.local : /boot/loader.conf.local hw.pci.enable_msix=0 hw.pci.enable_msi=0 With these tweaks, i have no issues anymore with the x550e and x750e Good luck Grtz DeLorean

Register with a DynDns service of your liking and add a DynDns client for your GSM interface in pfSense. Do so at  Services: Dynamic DNS

Yes. You may run multiple VPN servers as well as multiple clients at the same time.

The t41 will work for a simple pfsense install. I'm not sure how much bandwidth you can get out of it, but if you have something like 3mb DSL, you'd be fine. You will be limited to 32 bit versions of pfsense. Most software seems to be going 64 bit only, so I'm not sure how long pfsense will continue with 32 bit versions. My first pfsense router was on an old 400MHz Celeron. It handled my 3mb DSL just fine. I've been using IBM/Lenovo t series laptops for 25 years. The T40 series was one of my favorites.

The downloader is SABnzbd, set up to use 6 connections to the server. Whenever a part is downloaded, the connection is closed and a new one opened to download the next part. When this issue appears, establishing new connections works just fine for the downloader. Anything else times out.

Download on a different PC, copy to thumb drive/thumb drive to pfSense box or scp to pfSense box?

So far, the only problem you've stated you're having is getting traffic to flow across your VPN to the 10.5.10.x/24 network, but your network plan doesn't show this at all. If that really is the problem, then it might help showing where the VPN pipe fits into all this. Unless you're having some other issue, in which case mentioning it might help too.