A D2250 should work it would just be bandwidth limiting for PPPoE. But something like that will already be old, better to start with something newer anyway.

@SteveITS said in Confusion in understanding one of the "Deny unknown clients" setting: We used to have tenants While that seems like a very valid use case.. Thanks for a great example.. But that kind of puts you a bit above your typical home/smb sort of use don't you think ;)

Mmm, in fact it generally work better with mobile devices in my experience. Any recent version of Android or iOS can detect the redirection and prompt the user before they've even opened a browser.

lol yeah, @dennypage with just that it still works.

So was it passing full speed until recently?

That's what I would expect because the system routing table should be correct. Incoming traffic should always come from that route unless you have some route asymmetry somehow. It's the port forwards (NAT) that allows traffic from a single source IP to arrive via any gateway.

Is the OpenVPN server configured to listen on 'any' interface? If you can put a switch between igb2 and that PC? That would solve this. However if you set OPT1 to track interface for IPv6 it will probably stop this happening. Even if you have no IPv6 on the WAN.

No solution yet as far as I know. Any progress here should be on the bug report.

@macaruchi said in Access from internet router to LAN: No, it doesnt So how would you expect pfsense to forward something that never gets to pfsense? Either you don't have the forward setup correctly in the router in front of pfsense, or the traffic is never even getting to that router for it to forward.. You sure when you went to can you see me that the IP it sent the traffic too was the routers wan IP that you setup the forward to pfsense wan IP?

@stephenw10 That makes sense. Thanks

@stephenw10 yup that is a very good viable option. Or use that opt1 for your normal network, because the "lan" has the anti-lock out rule on it.

@stephenw10 Ok, I changed my hard drive. We’ll see!

There is no specific rule to block it. All unsolicited traffic is blocked inbound by default. Traffic is scrubbed by default which prevents fragments passing but even if you disabled that most rules would not pass fragmented traffic because they cannot match without the header info. See: https://man.freebsd.org/cgi/man.cgi?query=pf.conf#FRAGMENT_HANDLING There's no way to actively pass fragments from the GUI, there is no fragment option on user rules.

@planedrop said in Will pensense join vpp/dpdk: @NollipfSense I am guessing a typo, though that might be a difficult one to do.... LMAO...

It's defiantly Home Assistant. I assume deleting the integration didn't completely get rid of everything. I'll have to do some poking around and see if I can find out how to disable whatever is left.

Commonly it's because there are no iroutes to allow the OpenVPN server to know which subnets exist behind which clients. Those are not required in a shared key setup because it can only ever be point-to-point. https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-tls.html#create-client-specific-overrides Steve

@stephenw10 That's great, thank you. I'll get that done

The error is still misleading. Try removing a package at the command line: pkg-static remove pfSense-pkg-Open-VM-Tools Steve

Hmm, then there should be no problem with them using the primary IP in the 10.10.0X subnet as long as it' not the CARP VIP. Do you not see states at all on the other nodes?