Hmm, odd. That should be identical to re-assigning it as WAN.

@heper I see. Interesting. I'll see if I can find the poll. I mean if folks are willing to pay a premium for Unifi gear, you'd think they'd be willing to buy cheaper (but just as good) gear and pay more for pfSense. I know I would. Interesting.

@johnpoz Hello and thanks Yes I only had TCP port 443 outbound from my work VLAN and after adding UDP all is better. I'll VPN into work and update that wiki page

@gertjan noted with. Thanks!

The client only needs to generate a key pair if you want to authenticate using the key. The server always needs a key pair. All SSH servers do. SSH depends on public/private key cryptography. https://tools.ietf.org/html/rfc4251 Steve

It's ugly (triple NAT!) but you can port-forward in Google WIFI: https://support.google.com/wifi/answer/6274503?hl=en-GB This will work if you have all three port forwards setup correctly. The fact you were seeing blocked traffic in pfSense shows at least one port forward is wrong. See my comments above. Steve

Hey chumunga my pull request is 215, I fixed a lot of problems that were broken in the original script. This one liner will install 6.0.36... fetch -o - https://git.io/JIIj5 | sh -s

There are a few ways to approach this problem; my favorite is to create an alias called RFC_1918 and put all the non routable IP subnets in it (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16); you might also want to also add some of the illegal/special use (RFC 6890) subnets that shouldn't appear on the Internet. Then, in each vlan ruleset, a single before-last rule that says block from this-net to RFC_1918. Any explicit access can be granted prior to this rule, and the last rule is the allow this-net to any rule to get out to the Internet. Unless you are using non-private IPs internally, this will work fine, and will catch any future expansion. Similarly, you could create an alias called internal_vlans and put all your internal vlans in it, and using the same rule structure, you will prevent vlans from talking to each other unless explicitly allowed. This doesn't scale quite as well, as you need to add any new vlans to the internal_vlans alias, but it does allow you to use other subnets than the standard non-routable ones.

@stephenw10 OH sweet, yes I'm gonna try this tomorrow morning (Thursday) Wasn't able to find some documentation Hope I can just replace the old password with this "updater client key" Keep you posted! BrNP

True! It was enough to put the same domain that I had already indicated in General Setup. Many thanks to all of you.

Oh, ignore that! It's in there because the connection rate from that client is over the limit which is usually an indication of some malware. https://docs.netgate.com/pfsense/en/latest/monitoring/status/firewall-tables.html#default-tables Is that host really legitimately opening those connections? Steve

Yes, no limiters or AltQ

@stephenw10 , DHCP lease is 8 days and this device has a reservation in place, DNS, I have two and they are not reporting anything. The internet is stable, bounces maybe once a week on a bad week. @jimp I have tried two boxes so far, neither show any issues CPU/Memory wise, one is a Formuler TV and one a Minix Android PC, both work fine on the internet side of my Netgate.

In the HTTPS options at the bottom of the page. If the option isn't enabled, enable it, then switch the cert, then save again to make sure it's changed.

You can't remove a cert that is still in use. Change whatever is using it to the new cert first. Steve

You will only see IP lists in logs against passed by pfBlocker aliases. You can attempt to resolve them using reverse DNS but it will probably be of limited use. Steve

@johnpoz Yeah, just look at where the software in them is coming from. I've seen exactly what @Jknott is describing.

I would also check everything here: https://docs.netgate.com/pfsense/en/latest/troubleshooting/website-access-issues.html Your description could be an MTU issue. Steve