@jimp: Looks like /usr/local/sbin/gmirror_status_check.php lacked execute permissions in the repository, so this should fix it: chmod a+x /usr/local/sbin/gmirror_status_check.php Yes!! This fixed it, Thanks JIMP

"LAN on 192.168.1.0" won't work with a /24 (or 255.255.255.0, it's the same) netmask. Valid IPs are from 192.168.1.1 to 192.168.1.254 and your LAN has to be in that range! The same for your WAN networks, of course. .0 is the network's address and .255 the broadcast address (in a /24 network). @Ste178uk: … I can not connect to the webpage on the WAN interfaces... ??? If you want to connect FROM your WAN interface you have to add a rule to allow this.

Rebooting the modem on change of device connected to it is not faith based computing..  You have to clear its cache of the mac of the device it connected too..  Since they give you no interface into the things, the only way to reset that is reboot it. The instructions laid out marvosa are correct order of how you would swap out a device. What I do to get around having to reboot the modem when I play with different distros for firewall/router - I always go back to pfsense, but like to see what the other guys are doing every now and then.  Or if want to play with different version of pfsense, or want to try some with clean install of pfsense is just make sure all the VMs always use the same mac that is connected to the modem.  This way I don't have to reboot the modem and always have my same public IP as well.

found out it was the shutdown wake on lan that was the issue, changed it to enable and while i was in there i enabled patter match, dont know if i need this but oh well shutdown WOL - enable wake on pattern match - enable job done

Hi jonathanbaird, Well - after some serious head scratching you'll NEVER guess what the issue was.  Some joker (hilarious I think not) had added an EAST coast IP address to my WEST coast system.  This not only explained why I wasn't getting responses back from the other side of the VPN, but also why the response was coming from an IP address that I hadn't even asked for.  So all my logic into when a ping gets a response but with no destination was a little misguided. For shiggles, I'll explain what happened in more detail : On my WEST system (192.168.101.123) someone had added 192.168.100.3 to its IP stack. This obviously explained why, when attempting to ping the EAST coast system of 192.168.100.20 I get the (correct) response "Reply from 192.168.100.3: Destination host unreachable".

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?