indeed now its very responsive on save(s), thanks!

Well I managed to fix the iTunes issue. Apparently you have to add in the IPs that is linked to iTunes under Target Categories and adding; 54.214.28.210 17.158.28.83 17.172.116.74 17.172.116.75 17.158.10.52 17.172.116.36 17.154.66.156 23.9.237.102 150.101.152.240 17.173.255.108 17.167.138.24 150.101.98.211 150.101.98.200 150.101.98.226 150.101.98.211 150.101.98.234 150.101.213.173 150.101.98.211 17.151.36.30 17.142.160.7 208.72.242.165 173.192.76.134 66.235.139.206 150.101.96.224 150.101.96.232 17.154.66.11 69.54.181.89 17.111.65.223 23.37.139.27 23.37.139.27 150.101.98.200 23.7.18.217 17.151.36.30 17.149.240.70 151.101.152.219 150.101.152.234 17.154.66.38 It worked fine after that.

11 can't come soon enough, but PFSense 2.3 will keep me excited for a bit.

Hi, We had a new freeze  but  with local collectd we have more informations : http://www.unicaen.fr/pfsense/freeze-20150915.xhtml The system is not completely freeze, just console and network. After some searches on the web we have modified the following values in bios  : disable "logical processor" disable "virtualization technology" disable "SRIOV" on intel X520 network card We also tuned following values in /boot/loader.conf.local : cc_htcp_load="YES" net.link.ifqmaxlen="4096" hw.igb.num_queues="1" hw.ix.num_queues="8" net.isr.maxthreads="1" net.isr.defaultqlimit="2048" hw.igb.max_interrupt_rate="32000" hw.ix.rx_process_limit="-1" net.inet.tcp.syncache.hashsize="1024" net.inet.tcp.syncache.bucketlimit="100" net.isr.bindthreads="0" Now we have to wait.

If the AP supports Multiple SSIDs on different VLANs and you have a VLAN-capable switch (or a port on pfSense to dedicate to the AP, but a switch is better/more flexible) then yes.  If not, no. [image: Wi-Fi-VLANs-Apple.png] [image: Wi-Fi-VLANs-Apple.png_thumb]

It's also hard to help when there are no details whatsoever.  Symptom of your problem?  WAN/LAN interface details?  Firewall rules?

I would like to see a "proper" solution.  Single IP monitoring is causing us no end of issues.  Gateways being marked as down, but really the monitor IP has dissapeared, or ICMP is blocked but real world taffic tcp/udp is flowing perfectly. My concept would include many IP's and have some weighted rules.  Something like www.policyd-weight.org comes to mind. This would allow a list of say 20 IP's to monitor and allow for x number to be down and some marked as higher "number value" than others, then only mark the gateway as down if the sum of these values is below y.  Could even use the same IPs for many gateways and if one ip down on one gateway the IP can be checked against another gateway. I have no development skills, but would be willing to test and give feedback. –Paul

If you could get me a backup of your config, that would definitely help. Can PM it to me here, or email to cmb at pfsense dot org, or email me to arrange other means of transfer. I don't see a means of replicating from that, so that should help.

Great, thanks! I'll try this next time I have a network maintenance window (aka the gf isn't home and won't mind the Internet being out) and I'll post back if I get any good results!

It just occurred to me that I had a traffic shaper enabled, specifically CODELQ. I tried to delete those queues, but after applying changes I lost all connectivity with the box. I used the console to restore to a point before I delete and then restarted the box. After I got control back I deleted it again, and this time they are gone and the box is still running. I repeated the CIFS test and the performance problem seems to have been resolved. But now the question turns to why would the traffic shaper do that?

So I received a 6620L and tethering does not work by default: Anyone know if a a compiled driver will work? ugen1.3: <mifi 6620l="" novatel="" wireless="">at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) bLength = 0x0012   bDescriptorType = 0x0001   bcdUSB = 0x0201   bDeviceClass = 0x0002   bDeviceSubClass = 0x0006   bDeviceProtocol = 0x0000   bMaxPacketSize0 = 0x0040   idVendor = 0x1410   idProduct = 0xb00c   bcdDevice = 0x0228   iManufacturer = 0x0001  <novatel wireless="">iProduct = 0x0002  <mifi 6620l="">iSerialNumber = 0x0003  <0123456789ABCDEF>   bNumConfigurations = 0x0002</mifi></novatel></mifi>

Ok just sent message to all of them in same format to: emailaddress subject: test message to emailaddress This is test message per thread on pfsense forum about strange email getting added to messages. Let me know what you get..

@doktornotor: Do NOT put gateways on your LAN! It's even written in the GUI! That did the trick thanks !

I have a small/home network. So with raspberry pi is enough just for collecting logs. But, I'm thinking in mount a virtual server (proxmox) and I could use a virtual machine for logs. Also I would like to install in that virtual server: kali linux, honeypots, web servers, etc. I have to start saving!  :) Thanks.

What? Yeah have lots of dc in multiple customers I support.. Not one of them has public internet talking to them for dns..  If they even suggested such I would think they are on drugs..  If you want to use MS to host dns - sure go for it.. But not your AD dns using the same domain for sure.. You still have the problem that you only have 1.. same freaking IP, that your registrar even let you do that is beyond me.. Fixing your DNS is priority one.. Your name delegation is completely borked no matter what you want to use to host it, etc..  FIX YOUR DNS!!!  I have already told you what is wrong with it.  First step is at your registrar - having actually 2 different dns serves that should NOT be on the same network that is for sure..  If you set on hosting your own public dns off your connection and off your DC ok.. But get s secondary somewhere else. If you do not know anything about dns - then get someone in your org that does.. Hire some one if need be..