Thanks! It looks like "Request only an ipv6 prefix" solved the problem.

I see that OpenVPN performance issues have been discussed a lot here (and elsewhere on the internet). From what I've read: OpenVPN is still single threaded, so single core CPU performance only.  Netgate home/business equipment is not up to the task for gigabit speeds.  One workaround is to create multiple VPN tunnels and somehow combine them, but this apparently comes with its own problems. OpenVPN is partway userland and partway kernel.  This is why context switching is a thing.  One question about this – as I watched top, I could see the OpenVPN process jumping back and forth between CPU0 to CPU1.  Is this required for userland<->kernel switching?  Wouldn't there be a performance boost setting the affinity to a single core? IPSec seems to be recommended as an alternative… has anyone done this with pfsense?

Thanks Stephenw10. I checked the packages and indeed all of those were not installed, except for AutoConfigBackup.

https://forum.pfsense.org/index.php?topic=146036.0

U listed lots of stuff except the most important piece of information, what is the CPU LOAD? For no compromise, full gigabit, an i3-class CPU is typically recommended

What is your WAN interface? How is it connected? Does it have a private IP that is conflicting with the internal subnets perhaps? Can we see some screenshots of you rules? The routing table from Diag > Routes might also be revealing here. Steve

Are you sure it's not just blocking some of the connections that it can detect and not blocking the connections it can't detect?

VKAD, u are making yourself crazy doing something unusual, do u REALLY need 4096 hosts?

Works for me.

When you run that command from single user mode you need to run it at least three times. More times doesn't hurt. The issue there is that it reports the filesystem as clean even when there are still problems so it needs to be forced to run multiple passes. If it still doesn't boot after than the quickest thing to do is re-install. The recovery install procedure should get your existing config if you don't have a backup. Steve

Please help me.

I can solve this problem from your question.This can be used normally.

For redundancy, one normally uses a protocol. Google for 802.3ad And in pfSense, this might be what you are looking for: https://doc.pfsense.org/index.php/LAGG_Interfaces You can find that in interfaces>assignments>LAGGs (last tab)

@johnpoz: just policy route and put rule allowing the access you want to access a vlan above the rule that sends traffic out the vpn. I found this https://philsheets.me/blog/multi-vlan-vpn-endpoint-pfsense-network/ and added 2 new NAT rules in outbound, see attached screenshot and highlighted rules I added and now it works. :D I gotta be honest I don't understand what you are suggesting. But since it's working now, and I already have multiple auto-created rules in Outbound i guess this will qualify as a fair solution? :P  

Thanks for answer. With this option "ignore unknown clients" the problem still exists. For my case my network will be open for anybody whit IP = 192.168.0.2 - 99. and 201-255 So is there any other option to "list out" connected devices? Ref my Android fing app.

Where did you get the idea that pfblockerng needs to use forwarder mode? https://forum.pfsense.org/index.php?topic=128721.msg709743#msg709743 Straight from bbcan177 You can use either the DNS Resolver Forwarding mode or the DNS Resolver mode.

That is correct VLANs are at Layer 2. The SVIs (Switched Virtual Interfaces (logical L3 interfaces)) are in place to facilitate the intervlan routing. This all works correctly. The connection from the switch to the pfsense isn't configured as a transit VLAN - it is a routed link created using a routed port (no switchport) on the 3750. What I'm saying is: The SVIs, default route on the switch and routes on the pfsense are all set up correctly as I can ping/browse from a host on any of the VLANS to a host on the internet which indicates that the mechanics are in place. What I cannot do is ping from the switch itself to the pfsense and beyond when the source interface of the pings is the egress port on the switch (the egress port being the routed/172.34.2 interface). Everything else works. Hope this is a little clearer.