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

The introduction section from the docs sums it up nicely: https://docs.netgate.com/pfsense/en/latest/general/index.html Steve

@geoffdh said in Changing from Asus router to pfsense prevents access to hosts on internal network: so I wanted to try and use the other 5 in the same way as the ports on my previous Asus router Not a good idea at all - if you want switch ports, use a switch.. Also I assume that velop is doing nat.. So doesn't matter really what its wan IP is, its still going to nat. You should use your wifi router as just AP if you want your stuff to all be on the same network.. You sure that is not doing nat - and is just an AP? Nice hand drawing btw! ;) For future reference - in a pinch you want to do some ascii network drawings ;) https://textik.com http://asciiflow.com/ online drawing for network https://creately.com https://online.visual-paradigm.com/drive/#diagramlist:proj=0&new=NetworkDiagram There are many many more options.. But your hand drawing is very nice!

@MakOwner said in Suggestions for linking two pfsense setups: So, I thought since I have sort of got this working well enough thanks to all your help, I'd share what I have done -- so far anyway. Thanks for all the help! I have had to revert to 2.4.4-p3 on both ends. 2.4.5 doesn't seem to play well at this point. Gateway monitoring seem to be the downfall for some reason. I'll wait for another update before trying again. Why does GW monitoring pose a problem ? It's usually just a "Ping of the GW". DHCP servers are active with very limited ranges on each interface. The office interface handles the DHCP interface handles the .30/24 on the link between buildings and provides the addresses for the management interfaces on the two switches. Each DHCP server is configured to serve addresses within a specified range and each /24 has a different range just for conveniance. .10/24 uses .110-.120, .20/24 uses .120-.130, .30/24 uses .130-.140 for example. Not a single DHCP collision or bomb - yet, anyway. All active physical systems use static DHCP assignment outside the assignment range so that it becomes very obvious if anything goes south. Special way to "reckognize" which DHCP server hands out the ip. But if it works for you ..... Once you trust DHCP , you could move to something more "default". I usually let my dhcp start at .129 .. 250 And uses 25..125 for static assignments (1..24) are for infrastructure like routers , switches etc. I added the .30/24 interface of the opposite system as a gateway on each pfsense. I added static routes to .10/24 and .20/24 networks as appropriate. Great ... Do you understand why you have to do that now ? Tell one pfSense how to "reach" a remote lan on the "other". On the .30/24 interface on each pfsense I added an any-to-any firewall rule. That is "fine" , basically making the "Connect net" transparent. You could fine tune that , later if ever needed. The .30/24 rules , are like all other "normal" pfSense interface rules "Enter" rules : See it as: "This permitted traffic" is allowed to "enter" the pfSense-box via "this interface" , everything not permitted is blocked , and will NOT enter the receiving pfSense box. From there I began working on DNS. The DNS resolver in 2.4.4 doesn't quite behave as I expected. What is your issue ? Still Unbound crashes ? Did you try the service watchdog ? After DNS is working like I expect I'll move on to configuring the direct link. ??? Remember when making changes to : Backup pfSense configs often. Don't make 10 changes at the same time. All in all a nice excersise , you certainly got your hands dirty. Well done , especially for not giving up. /Bingo Ps: If you ever want to "do it right" more flexible , you we should enable multi-vlan on ALL your switches. That would give you the flexibility to make ANY switchport in any building , a member of "ANY vlan". Ie. a server in building-1 , would be seen as a member of the building-2 Lan. But that would require that you are reading up on "tagging" on all your switches , including the old "access" switches you use. And start playing a little with vlans & tagging , before starting that up.

@maxxer Check previous discussion about similar issue and how to troubleshoot here: https://forum.netgate.com/topic/145578/ldaps-ad-bind

Yes, unless you are saturating the connection you should not be seeing packet loss. Steve

Just for the record, I've managed my case by placing static routes as I only needed Cloudflare routed to VPN. Why routing Cloudflare? Extensive threats against my clients, abusing CL as a way to evade detection by filtering either Country or VPNs.

Yup. If you know who you need to allow access to you could also use pfBlocker to generate Geo IP aliases, then allow access from only those you need. Or block block access from lists of known bad actors etc. You might also consider running Snort/Suricata to check that traffic. That quite a complex setup though, I would not add that immediately. Steve