Hi Jimp, Yes 32bit. I am glad to hear this. So no need to worry about. Thanks alot! Kind regards,

Thanks for the help fellas, got it running  ;D

How is 1 adapter going to work??  When you clearly have 2 in your drawing.. As to how to setup networking in KVM, your going to have to ask KVM forums/docs Maybe someone help you in the virtual section of this forum, not sure why your post was not there to begin with? More than happy to walk you through how to do it on esxi..  But like I said before not 100% how how things done in KVM.. As heper mentioned that might not be the best choice for vm pfsense.  I can tell you with esxi its a no brainer and stable as all get out and performance is good..  Why are you picking KVM if you are not sure how to setup its network??

I would suggest to connect on device at one port and another PC to another port without VLANs because now you know only the inter VLAN throughput and nothing more. mbuf size to 1000000 PowerD (hi adaptive) enable TRIM support in pfSense Would be the most common settings to tune this board, but anyway if you are running pfSense 2.2.6 amd64 full install on a SSD or HDD it must be more available then ~250 MBit/s as others would report here in the forum. And for the LAN speed it should be nearly 1 GBit/s at all. For the WAN speed it is mostly only not so fast related to the circumstance that the PPPoE Internet connection is only running on a single CPU core.

Well, I made a progress on incoming errors.. These errors accumulated rapidly and while doing no observable harm. But about a week ago situation became worse. On a month of uptime system freaked out, error counter went through the roof and WAN went down. I rebooted.. And it repeated 3 times during 1st or 2nd 24 hours of uptime since then (under load). And that's when I started playing with hardware and poking drivers with a stick. So, the results: EXPI9301CT NIC itself is working fine, I tried swapping with the same exact model - same problems. Missed packets and "recv_no_buff" counters. Even on igb card, while this one is installed. So it should be driver (em) or this specific model. Changing model, at first I used I217-LM (one of onboard NICs, em driver) for WAN passthrough. According to vSphere Client it has own pci lane, unlike other one, which seems to be interconnected through PCH. "That one should be superior," - I thought - "as long as they are pretty similar looking on Intel ARK". As a result, there was no incrementing error counters from the start on any interface, but during 2nd 24 hours of "stressing" the system with 80 mbps on average, WAN timed out for couple seconds (I actually experienced it), interface dropped 923 errors and continued functioning. Flimsy.. Although no errors on dev.igb. So, again should be driver (em) or this specific model (if momentary glitch was unrelated) Then I switched WAN to another onboard NIC - I210 (igb driver). No incoming errors, no missed packets. Same on fiber card. I pushed roughly the same amount of traffic through system in 2 days which initially brought my WAN down after the month of runtime. System still stable. Missed packets and "recv_no_buff" at 0 on all NICs. To sum up, I still don't know whether it's the specific model that causes issue during passthrough (while it is actually functional and now acts as a secondary LACP port for ESXi management in place of onboard one that is now passed to pfSense for WAN) or the em driver and there could be other em NICs having same issue with passthrough or even the 82574L chip has something to do in hardware. EXPI9301CT is a very old model meant for desktops, not virtual environments, although it is still present in Intel's 2016 catalogue. And also given that em dirver in FreeBSD man pages is dated October 11, 2011 while igb is of March 25, 2013, I just made a conclusion for myself that later is just more stable and Intel NICs are not bulletproof as I thought. [image: XREfaHC.jpg] I don't know what are these outgoing errors.. I recall having them all the time, even on bare metal, even on other platform. There is literally no info I managed to find about any possible causes of them or at least the meaning of these counters, so if someone may enlighten me, please do.. At least, they seem to not be as harmless. $ sysctl dev.igb dev.igb.%parent: dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 2.4.0 dev.igb.0.%driver: igb dev.igb.0.%location: slot=0 function=0 handle=\_SB_.PCI0.PE40.S1F0 dev.igb.0.%pnpinfo: vendor=0x8086 device=0x1533 subvendor=0x15d9 subdevice=0x1533 class=0x020000 dev.igb.0.%parent: pci3 dev.igb.0.nvm: -1 dev.igb.0.enable_aim: 1 dev.igb.0.fc: 3 dev.igb.0.rx_processing_limit: 100 dev.igb.0.dmac: 0 dev.igb.0.eee_disabled: 0 dev.igb.0.link_irq: 0 dev.igb.0.dropped: 0 dev.igb.0.tx_dma_fail: 0 dev.igb.0.rx_overruns: 0 dev.igb.0.watchdog_timeouts: 0 dev.igb.0.device_control: 1478230593 dev.igb.0.rx_control: 71335938 dev.igb.0.interrupt_mask: 157 dev.igb.0.extended_int_mask: 2147483648 dev.igb.0.tx_buf_alloc: 0 dev.igb.0.rx_buf_alloc: 0 dev.igb.0.fc_high_water: 31328 dev.igb.0.fc_low_water: 31312 dev.igb.0.queue0.no_desc_avail: 0 dev.igb.0.queue0.tx_packets: 620869912 dev.igb.0.queue0.rx_packets: 618707893 dev.igb.0.queue0.rx_bytes: 851127332692 dev.igb.0.queue0.lro_queued: 0 dev.igb.0.queue0.lro_flushed: 0 dev.igb.0.mac_stats.excess_coll: 0 dev.igb.0.mac_stats.single_coll: 0 dev.igb.0.mac_stats.multiple_coll: 0 dev.igb.0.mac_stats.late_coll: 0 dev.igb.0.mac_stats.collision_count: 0 dev.igb.0.mac_stats.symbol_errors: 0 dev.igb.0.mac_stats.sequence_errors: 0 dev.igb.0.mac_stats.defer_count: 0 dev.igb.0.mac_stats.missed_packets: 0 dev.igb.0.mac_stats.recv_no_buff: 0 dev.igb.0.mac_stats.recv_undersize: 0 dev.igb.0.mac_stats.recv_fragmented: 0 dev.igb.0.mac_stats.recv_oversize: 0 dev.igb.0.mac_stats.recv_jabber: 0 dev.igb.0.mac_stats.recv_errs: 0 dev.igb.0.mac_stats.crc_errs: 0 dev.igb.0.mac_stats.alignment_errs: 0 dev.igb.0.mac_stats.coll_ext_errs: 0 dev.igb.0.mac_stats.xon_recvd: 0 dev.igb.0.mac_stats.xon_txd: 0 dev.igb.0.mac_stats.xoff_recvd: 0 dev.igb.0.mac_stats.xoff_txd: 0 dev.igb.0.mac_stats.total_pkts_recvd: 618715218 dev.igb.0.mac_stats.good_pkts_recvd: 618707618 dev.igb.0.mac_stats.bcast_pkts_recvd: 1428 dev.igb.0.mac_stats.mcast_pkts_recvd: 3090 dev.igb.0.mac_stats.rx_frames_64: 601133 dev.igb.0.mac_stats.rx_frames_65_127: 13638243 dev.igb.0.mac_stats.rx_frames_128_255: 10436929 dev.igb.0.mac_stats.rx_frames_256_511: 9534739 dev.igb.0.mac_stats.rx_frames_512_1023: 13436838 dev.igb.0.mac_stats.rx_frames_1024_1522: 571059736 dev.igb.0.mac_stats.good_octets_recvd: 853601812367 dev.igb.0.mac_stats.good_octets_txd: 71259681700 dev.igb.0.mac_stats.total_pkts_txd: 620869651 dev.igb.0.mac_stats.good_pkts_txd: 620869651 dev.igb.0.mac_stats.bcast_pkts_txd: 3 dev.igb.0.mac_stats.mcast_pkts_txd: 3 dev.igb.0.mac_stats.tx_frames_64: 3612420 dev.igb.0.mac_stats.tx_frames_65_127: 560906135 dev.igb.0.mac_stats.tx_frames_128_255: 28742303 dev.igb.0.mac_stats.tx_frames_256_511: 8907879 dev.igb.0.mac_stats.tx_frames_512_1023: 4722579 dev.igb.0.mac_stats.tx_frames_1024_1522: 13978335 dev.igb.0.mac_stats.tso_txd: 0 dev.igb.0.mac_stats.tso_ctx_fail: 0 dev.igb.0.interrupts.asserts: 965490770 dev.igb.0.interrupts.rx_pkt_timer: 618687254 dev.igb.0.interrupts.rx_abs_timer: 0 dev.igb.0.interrupts.tx_pkt_timer: 0 dev.igb.0.interrupts.tx_abs_timer: 0 dev.igb.0.interrupts.tx_queue_empty: 620853924 dev.igb.0.interrupts.tx_queue_min_thresh: 618707618 dev.igb.0.interrupts.rx_desc_min_thresh: 0 dev.igb.0.interrupts.rx_overrun: 0 dev.igb.0.host.breaker_tx_pkt: 0 dev.igb.0.host.host_tx_pkt_discard: 0 dev.igb.0.host.rx_pkt: 20364 dev.igb.0.host.breaker_rx_pkts: 0 dev.igb.0.host.breaker_rx_pkt_drop: 0 dev.igb.0.host.tx_good_pkt: 15727 dev.igb.0.host.breaker_tx_pkt_drop: 0 dev.igb.0.host.rx_good_bytes: 853601838827 dev.igb.0.host.tx_good_bytes: 71259681700 dev.igb.0.host.length_errors: 0 dev.igb.0.host.serdes_violation_pkt: 0 dev.igb.0.host.header_redir_missed: 0 dev.igb.0.wake: 0 dev.igb.1.%desc: Intel(R) PRO/1000 Network Connection version - 2.4.0 dev.igb.1.%driver: igb dev.igb.1.%location: slot=0 function=0 handle=\_SB_.PCI0.PE50.S1F0 dev.igb.1.%pnpinfo: vendor=0x8086 device=0x10e6 subvendor=0x8086 subdevice=0xa02f class=0x020000 dev.igb.1.%parent: pci11 dev.igb.1.nvm: -1 dev.igb.1.enable_aim: 1 dev.igb.1.fc: 3 dev.igb.1.rx_processing_limit: 100 dev.igb.1.link_irq: 0 dev.igb.1.dropped: 0 dev.igb.1.tx_dma_fail: 0 dev.igb.1.rx_overruns: 0 dev.igb.1.watchdog_timeouts: 0 dev.igb.1.device_control: 1087117889 dev.igb.1.rx_control: 67141634 dev.igb.1.interrupt_mask: 157 dev.igb.1.extended_int_mask: 2147483648 dev.igb.1.tx_buf_alloc: 0 dev.igb.1.rx_buf_alloc: 0 dev.igb.1.fc_high_water: 58976 dev.igb.1.fc_low_water: 58960 dev.igb.1.queue0.no_desc_avail: 3 dev.igb.1.queue0.tx_packets: 1749306695 dev.igb.1.queue0.rx_packets: 631652753 dev.igb.1.queue0.rx_bytes: 827196373649 dev.igb.1.queue0.lro_queued: 0 dev.igb.1.queue0.lro_flushed: 0 dev.igb.1.mac_stats.excess_coll: 0 dev.igb.1.mac_stats.single_coll: 0 dev.igb.1.mac_stats.multiple_coll: 0 dev.igb.1.mac_stats.late_coll: 0 dev.igb.1.mac_stats.collision_count: 0 dev.igb.1.mac_stats.symbol_errors: 0 dev.igb.1.mac_stats.sequence_errors: 0 dev.igb.1.mac_stats.defer_count: 0 dev.igb.1.mac_stats.missed_packets: 0 dev.igb.1.mac_stats.recv_no_buff: 0 dev.igb.1.mac_stats.recv_undersize: 0 dev.igb.1.mac_stats.recv_fragmented: 0 dev.igb.1.mac_stats.recv_oversize: 0 dev.igb.1.mac_stats.recv_jabber: 0 dev.igb.1.mac_stats.recv_errs: 0 dev.igb.1.mac_stats.crc_errs: 0 dev.igb.1.mac_stats.alignment_errs: 0 dev.igb.1.mac_stats.coll_ext_errs: 0 dev.igb.1.mac_stats.xon_recvd: 0 dev.igb.1.mac_stats.xon_txd: 0 dev.igb.1.mac_stats.xoff_recvd: 0 dev.igb.1.mac_stats.xoff_txd: 0 dev.igb.1.mac_stats.total_pkts_recvd: 631666455 dev.igb.1.mac_stats.good_pkts_recvd: 631652747 dev.igb.1.mac_stats.bcast_pkts_recvd: 77781 dev.igb.1.mac_stats.mcast_pkts_recvd: 145425 dev.igb.1.mac_stats.rx_frames_64: 356 dev.igb.1.mac_stats.rx_frames_65_127: 81351672 dev.igb.1.mac_stats.rx_frames_128_255: 5213675 dev.igb.1.mac_stats.rx_frames_256_511: 1833018 dev.igb.1.mac_stats.rx_frames_512_1023: 1375058 dev.igb.1.mac_stats.rx_frames_1024_1522: 541878968 dev.igb.1.mac_stats.good_octets_recvd: 832249572479 dev.igb.1.mac_stats.good_octets_txd: 1817163097562 dev.igb.1.mac_stats.total_pkts_txd: 1749306409 dev.igb.1.mac_stats.good_pkts_txd: 1749306409 dev.igb.1.mac_stats.bcast_pkts_txd: 10921 dev.igb.1.mac_stats.mcast_pkts_txd: 408712 dev.igb.1.mac_stats.tx_frames_64: 7075834 dev.igb.1.mac_stats.tx_frames_65_127: 524157938 dev.igb.1.mac_stats.tx_frames_128_255: 17279963 dev.igb.1.mac_stats.tx_frames_256_511: 10565548 dev.igb.1.mac_stats.tx_frames_512_1023: 14796151 dev.igb.1.mac_stats.tx_frames_1024_1522: 1175430975 dev.igb.1.mac_stats.tso_txd: 0 dev.igb.1.mac_stats.tso_ctx_fail: 0 dev.igb.1.interrupts.asserts: 1372961031 dev.igb.1.interrupts.rx_pkt_timer: 631643467 dev.igb.1.interrupts.rx_abs_timer: 0 dev.igb.1.interrupts.tx_pkt_timer: 0 dev.igb.1.interrupts.tx_abs_timer: 631652747 dev.igb.1.interrupts.tx_queue_empty: 1749288623 dev.igb.1.interrupts.tx_queue_min_thresh: 0 dev.igb.1.interrupts.rx_desc_min_thresh: 0 dev.igb.1.interrupts.rx_overrun: 0 dev.igb.1.host.breaker_tx_pkt: 0 dev.igb.1.host.host_tx_pkt_discard: 0 dev.igb.1.host.rx_pkt: 9280 dev.igb.1.host.breaker_rx_pkts: 0 dev.igb.1.host.breaker_rx_pkt_drop: 0 dev.igb.1.host.tx_good_pkt: 17786 dev.igb.1.host.breaker_tx_pkt_drop: 0 dev.igb.1.host.rx_good_bytes: 832249624227 dev.igb.1.host.tx_good_bytes: 1817163097562 dev.igb.1.host.length_errors: 0 dev.igb.1.host.serdes_violation_pkt: 0 dev.igb.1.host.header_redir_missed: 0 dev.igb.1.wake: 0 dev.igb.2.%desc: Intel(R) PRO/1000 Network Connection version - 2.4.0 dev.igb.2.%driver: igb dev.igb.2.%location: slot=0 function=1 dev.igb.2.%pnpinfo: vendor=0x8086 device=0x10e6 subvendor=0x8086 subdevice=0xa02f class=0x020000 dev.igb.2.%parent: pci11 dev.igb.2.nvm: -1 dev.igb.2.enable_aim: 1 dev.igb.2.fc: 3 dev.igb.2.rx_processing_limit: 100 dev.igb.2.link_irq: 0 dev.igb.2.dropped: 0 dev.igb.2.tx_dma_fail: 0 dev.igb.2.rx_overruns: 0 dev.igb.2.watchdog_timeouts: 0 dev.igb.2.device_control: 1087117889 dev.igb.2.rx_control: 67141634 dev.igb.2.interrupt_mask: 157 dev.igb.2.extended_int_mask: 2147483648 dev.igb.2.tx_buf_alloc: 0 dev.igb.2.rx_buf_alloc: 0 dev.igb.2.fc_high_water: 58976 dev.igb.2.fc_low_water: 58960 dev.igb.2.queue0.no_desc_avail: 0 dev.igb.2.queue0.tx_packets: 476889 dev.igb.2.queue0.rx_packets: 623282493 dev.igb.2.queue0.rx_bytes: 74446064995 dev.igb.2.queue0.lro_queued: 0 dev.igb.2.queue0.lro_flushed: 0 dev.igb.2.mac_stats.excess_coll: 0 dev.igb.2.mac_stats.single_coll: 0 dev.igb.2.mac_stats.multiple_coll: 0 dev.igb.2.mac_stats.late_coll: 0 dev.igb.2.mac_stats.collision_count: 0 dev.igb.2.mac_stats.symbol_errors: 0 dev.igb.2.mac_stats.sequence_errors: 0 dev.igb.2.mac_stats.defer_count: 0 dev.igb.2.mac_stats.missed_packets: 0 dev.igb.2.mac_stats.recv_no_buff: 0 dev.igb.2.mac_stats.recv_undersize: 0 dev.igb.2.mac_stats.recv_fragmented: 0 dev.igb.2.mac_stats.recv_oversize: 0 dev.igb.2.mac_stats.recv_jabber: 0 dev.igb.2.mac_stats.recv_errs: 0 dev.igb.2.mac_stats.crc_errs: 0 dev.igb.2.mac_stats.alignment_errs: 0 dev.igb.2.mac_stats.coll_ext_errs: 0 dev.igb.2.mac_stats.xon_recvd: 0 dev.igb.2.mac_stats.xon_txd: 0 dev.igb.2.mac_stats.xoff_recvd: 0 dev.igb.2.mac_stats.xoff_txd: 0 dev.igb.2.mac_stats.total_pkts_recvd: 697958370 dev.igb.2.mac_stats.good_pkts_recvd: 623282231 dev.igb.2.mac_stats.bcast_pkts_recvd: 129434 dev.igb.2.mac_stats.mcast_pkts_recvd: 17096 dev.igb.2.mac_stats.rx_frames_64: 1 dev.igb.2.mac_stats.rx_frames_65_127: 563028186 dev.igb.2.mac_stats.rx_frames_128_255: 28151786 dev.igb.2.mac_stats.rx_frames_256_511: 9427339 dev.igb.2.mac_stats.rx_frames_512_1023: 5069891 dev.igb.2.mac_stats.rx_frames_1024_1522: 17605028 dev.igb.2.mac_stats.good_octets_recvd: 79432278514 dev.igb.2.mac_stats.good_octets_txd: 52903487 dev.igb.2.mac_stats.total_pkts_txd: 476888 dev.igb.2.mac_stats.good_pkts_txd: 476888 dev.igb.2.mac_stats.bcast_pkts_txd: 11 dev.igb.2.mac_stats.mcast_pkts_txd: 165656 dev.igb.2.mac_stats.tx_frames_64: 7 dev.igb.2.mac_stats.tx_frames_65_127: 300650 dev.igb.2.mac_stats.tx_frames_128_255: 172846 dev.igb.2.mac_stats.tx_frames_256_511: 3385 dev.igb.2.mac_stats.tx_frames_512_1023: 0 dev.igb.2.mac_stats.tx_frames_1024_1522: 0 dev.igb.2.mac_stats.tso_txd: 0 dev.igb.2.mac_stats.tso_ctx_fail: 0 dev.igb.2.interrupts.asserts: 591617753 dev.igb.2.interrupts.rx_pkt_timer: 623273921 dev.igb.2.interrupts.rx_abs_timer: 0 dev.igb.2.interrupts.tx_pkt_timer: 0 dev.igb.2.interrupts.tx_abs_timer: 623282231 dev.igb.2.interrupts.tx_queue_empty: 476827 dev.igb.2.interrupts.tx_queue_min_thresh: 0 dev.igb.2.interrupts.rx_desc_min_thresh: 0 dev.igb.2.interrupts.rx_overrun: 0 dev.igb.2.host.breaker_tx_pkt: 0 dev.igb.2.host.host_tx_pkt_discard: 0 dev.igb.2.host.rx_pkt: 8310 dev.igb.2.host.breaker_rx_pkts: 0 dev.igb.2.host.breaker_rx_pkt_drop: 0 dev.igb.2.host.tx_good_pkt: 61 dev.igb.2.host.breaker_tx_pkt_drop: 0 dev.igb.2.host.rx_good_bytes: 79432278736 dev.igb.2.host.tx_good_bytes: 52903487 dev.igb.2.host.length_errors: 0 dev.igb.2.host.serdes_violation_pkt: 0 dev.igb.2.host.header_redir_missed: 0

All the above comments are spot on, it's tough to give good examples without knowing what you're trying to do. That said, this is an older link to a "taster" of some pfSense CLI commands:https://blog.linuxnet.ch/pfsense-important-cli-commands/ Between that link and the FreeBSD manuals, you should be getting started…..

The mem stick full version (or live cd) can be installed to a usb stick and then run from that one single usb stick.  Been installing and running that way for years.  The trick is knowing which usb stick to select during installation if they are both identical. With the full version on usb stick enable the /tmp and /var ram disk to reduce write cycles. I also like to use a short usb extension cable for thermal isolation from the computer.  Heat kills.

@BBcan177: For pfBlockerNG and Snort, anything that gets blocked will be reported in the 'Alerts' Tab. You need to review these Alerts tabs to remove any false positives. Snort, should be initially setup in 'non-blocking' mode. This way it will still report its activity to the Alert tab, but it will not block anything. This can be defined in the 'Global Settings' Tab. Once you run snort for a few weeks, you can tune the Rules so that they are appropriate for your network. Then you can enable 'Blocking Mode'. As said above, start with the base system debugging, then add one package at a time or you can chase your tail, unless your more comfortable with debugging the issues…. You can see the following threads for some additional details: https://forum.pfsense.org/index.php?topic=102470.0 https://forum.pfsense.org/index.php?topic=86212.0 https://forum.pfsense.org/index.php?topic=78062.0 By chance do you have a good advanced guide for setting up DNS, DHCP as well as overall system tuning?

First off thank you very much for all the extremely detailed technical knowhow. I know it is more directed at the other person but I will respond anyways. In my case, i am sitting at MBUF Usage: 2026/26584. Is it worth increasing? i think not as that is like 10%…. The machine has 2gb of ram and its using 9% of that currently. Having said that, i have switched to 64 bit install and my install is stable for the last 2 days. fingers crossed. I dont have any vpn tunnels. Well i have an insecure pptp vpn tunnel sometimes but not really correlated to the times my connection fails. I am just a static IP connecting to another device with a static IP, (metrotik router).

Agreed IoT can be concern for security.. Which is why they are on their own SSID with their own psk and isolated to their own network segment. As to creation of vlan.. If you only have 1 physical lan interface on pfsense that is connected to your switch.. Yes you would create a new vlan, and add it to your physical interface. So for example here is my wlan_psk, this is where I put my nest and harmony for example. You can see its on em2.. This is a trunk port my switch that carries all the vlans that are on that physical nic. What specific switch do you have and can go over how you would setup the port that connects to a nic with vlans on it.. And then how you would setup your other ports on the switch to be in a specific vlan. So you can see the ports on my sg300 switch, The ports that are trunk, ge3 is connected to pfsense em2 that sits on my esxi host, ge4 is uplink to another smart switch in my living room av cab.  While ge9 is uplink to a AP.  Depending on your switch it might use the trunk term differently than cisco does.  But in general your going to have ports that have tagged traffic that need to carry more than 1 vlan, and then your going to have ports that only have 1 vlan on them.. Trunks that carry more than 1 vlan are connected to nics that have vlans on them like pfsense, switches that will have more than 1 vlan on that switch, and then to other devices that will also carry traffic this is on different vlans like access points that have different vlans assign to different ssids edit:  And before anyone mentions it, yes my default vlan is 1.. And while that is normally frowned upon - this is HOME network.. I think I am quite capable of knowing what I plug in and what it will have access to and what vlan the port is on, etc.  vlan 1 is no different than any other vlan..  Its just not common practice in the enterprise to use leave anything in the default vlan is all. [image: sg300switch.png] [image: vlans.png_thumb] [image: vlans.png] [image: sg300switch.png_thumb]

@Derelict: OK, then you need to Packet Capture to make sure the OpenVPN connections are hitting your WAN port then make sure there's a WAN rule passing the traffic. Well I found out the phone guy reconfigured my pfsense to use dhcp instead of static on the wan, so it wasn't the dmz port. I emailed him and he gave me what is supposedly the dmz port ip. So I assigned that static, and did a packet capture on port 1195 and it captured nothing at all. I guess the ball is in his court now -_-

@BlueKobold: Does "LAN net" only include the ipv4 subnet? Lies you was configuring it and it is using only ipv4 ip addresses. It looks like it's not including any if the ipv6 stuff. If the ipv6 stuff will be not needed, because it is not in use there will be no need for it to show up. I'm not sure what you're talking about?  My question arose after seeing local ipv6 traffic being actively blocked by the firewall even though there was the default accept rule for "LAN net."  It was later explained to me that the link-local ip6 stuff was not included in "LAN net."

@Derelict: But you can't use the whole /27 because 9 addresses are for the PPPoE. Regarding who can contact what, it sounds like it's functioning pretty much as expected. Now I'm not sure what "I cheated and said it was a /26 on the "servers" interface" means. It's either a /27 or it isn't. There really is no way to cheat. 76.10.190.224 /27 I was meaning by using my whole /27 subnet, everytime you split the subnet, you lose 4 hosts do you not? two ips for each subnet?

@cmb: No real danger, but no point in doing so either. You're not going to help anything by passing the traffic, so why do it. But that's exactly what "LAN net" is already doing.  It allows all kind of traffic in that pfsense doesn't need to see. Broadcast traffic is hitting the system right now. Is it unreasonable to see "Lan net" as synonymous with "local traffic?" LAN = Local Area Network.  Why is link-local traffic not "local" enough? (lol, I just realized that every time we say "Lan Net", we're like those people who say "ATM Machine") If that argument isn't compelling enough, one reason to add link local addresses to "Lan net", would be to stop the unnecessary flooding of the firewall logs. Everyone who uses ip6 has to create additional rules to filter out this harmless broadcast traffic. Until we do, the Firewall Logs widget under the Status -> Dashboard is worthless. @cmb: @Tantamount: Is there a way to specify "all traffic on interface" instead when creating firewall rules? @cmb: That's what source "any" is for. I think what I'm looking for is "all traffic on an interface where the interface is configured to listen for."  I think "any" goes beyond this.

@cmb: Odd looking. Is it just that one iPad? Other wireless devices fine? I think it's just the one device, but I'm not positive.  In this case my Windows 10 laptop had issues at the same time, but it recovered very quickly (~30s).  I was connected to another machine on my LAN via RDP and saw a lot of latency.  Ex: Each key press would take 500-1000ms to show up on the other end. I should have been clear, I don't necessarily think it's an issue with pfSense.  It's most likely an edge case where something doesn't recover correctly from a wireless error.  Since it happens so infrequently I might not ever track it down. I'll definitely try capturing on the wlan interface the next time it happens.  I wish I would have thought of that yesterday.  Thanks for the suggestion.

Have you ever figured this out? I'm having the same issue.

@Derelict: I just saw the printer is connected to wireless too so another possibility is wireless client isolation being enabled on the WLAN. Yeah where they're both wireless that's a pretty good possibility.

OK. Thanks FYI… the unit was not really dead. We were told that the capacitors in this model takes a while to discharge. When we had a blip on our power, the ups where the unit was plug into somehow did not hold the unit up. All we had to do was unplug the power cable from the unit for a few minutes to let the capacitors discharge. It came back up after plugging the power cable back in. Thank you

I have a pair of pfSense boxes that I use for our guest networks. Up until 2.2.4 RADIUS authentication for the Web GUI was working fine. It appears 2.2.5 broke it and even trying several variations of the "Class" attribute doesn't seem to help. The RADIUS servers are Windows 2012 R2 NPS servers. Is there a patch on the way? Can the pfSense team revert to the pre- 2.2.5 code? I never had to worry about group info before….the setup was using the users I entered and local groups to determine permissions. The only thing RADIUS was doing was making sure the user account existed in the directory and verify the password that was entered is correct. Thomas