What you are trying to do is not how vswitches work. You might be able to map each nic to a separate switch and have a virtual nic on the firewall for each one, but that's kind of crazy.

NAT does not affect where the rules go. Rules for traffic originating from your LAN go on the LAN tab. Rules for traffic originating from the remote site over IPsec go on the IPsec tab.

@stephenw10 said in Heavy traffic on OpenVPN client kills primary connection: I could imagine maybe the main WAN gateway could get marked down due to latency and the VPN gateway gets set as default. If that is happening make sure the main WAN is set specifically as the default v4 gateway rather than 'automatic' in System > Routing > Gateways Thanks Steve. I think that was exactly the issue. After making that change a few weeks ago, WAN hasn't gone down!

Thanks works , i did reset "Reset log files under log settings and started to work Thanks again

Yes, you should be able to. I would read through it though. Better to be sure. Steve

It's probably this: https://docs.netgate.com/pfsense/en/latest/firewall/troubleshooting-blocked-log-entries-for-legitimate-connection-packets.html It could be this: https://docs.netgate.com/pfsense/en/latest/firewall/troubleshooting-blocked-log-entries-due-to-asymmetric-routing.html Steve

@marvosa Thanks for the follow-up. Not sure what changed, or if I'm just impatient... Before I posted that last comment I had enabled dhcp for VLAN 300 and everything worked. Then I disabled dhcp and reconnected the external dhcp server and it didn't work. So I posted the comment and went upstairs and ate lunch. Came back downstairs to continue troubleshooting and everything is working using the external dhcp server. Thanks again for your help.

@stephenw10 yep. Spot on I just hadn't replied yet. Reassigned the IP on the bge0 interface and it automatically enabled the interface again. Many thanks for the help from all on this thread. I did work it out myself but knowing others would have got it as well makes a difference. Thanks.

Ok so you can see what those values are in the RRD update script /var/db/rrd/updaterrd.sh, specifically: pfctl_si_out="` /sbin/pfctl -si > /tmp/pfctl_si_out `" pfctl_ss_out="` /sbin/pfctl -ss > /tmp/pfctl_ss_out`" pfrate="` cat /tmp/pfctl_si_out | egrep "inserts|removals" | awk '{ pfrate = $3 + pfrate } {print pfrate}'|tail -1 `" pfstates="` cat /tmp/pfctl_ss_out | egrep -v "<\-.*?<\-|\->.*?\->" | wc -l|sed 's/ //g'`" pfnat="` cat /tmp/pfctl_ss_out | egrep '<\-.*?<\-|\->.*?\->' | wc -l|sed 's/ //g' `" srcip="` cat /tmp/pfctl_ss_out | egrep -v '<\-.*?<\-|\->.*?\->' | grep '\->' | awk '{print $3}' | awk -F: '{print $1}' | sort -u|wc -l|sed 's/ //g' `" dstip="` cat /tmp/pfctl_ss_out | egrep -v '<\-.*?<\-|\->.*?\->' | grep '<\-' | awk '{print $3}' | awk -F: '{print $1}' | sort -u|wc -l|sed 's/ //g' `" So that looks like the number of unique source IPs on outgoing states. If you only have a single WAN and you're NATing out of it that's probably going to be 1. And the number of unique destination IPs on incoming states. A lot higher since that includes all the external IPs on states opened on LAN by clients. Looking at the output there though it looks like there may be room for improvement. It doesn't handle IPv6 addresses and counts blank lines. Steve

The only way I can see this behaviour happening is if you're trying to connect to those hosts using only the host name and not the fqdn. Like: ping preauth. If that's true then yeah it will only resolve hosts in the same domain as the client in general. Steve

Dick? Really? Calling you out on calling yourself a ccie when clearly everyone knows that is not even close to true is not being a dick... That is just calling someone out on their BS! So what was the problem, only tcp for the rule? Wrong source? Maybe you had policy route on the rule? But that wouldn't of stopped ping to pfsense IP? Only ping to other lan.. That is another common mistake.

Because the NAT IP is set to 192.168.1.4, the proxy. The destination IP defined what traffic that port forward will match on coming into the WAN. Unless you have more than one public IP on the WAN it can only be the WAN IP. Steve

@stephenw10 Nothing was hard coded but I confirmed the issue with tcpdump. The areas where this impacted me seemed to be only in NAT functions

What port test are you using? 192.168.1.146 should report success on port 8443. You won't be able to test the forward from pfSense itself. But if you try some external test such as canyouseeme and then check the state table for :25565 you should see the NAT'd state with traffic both ways. Steve

Did you reboot the modem?