@mveplus said in Release of aarch64 images for espressobin v7 board: First product equipped with Microchip CryptoAuthentication Device which provides assurance your system is running authentic, unaltered pfSense software Does it mean that Netgate SG-1100 hardware based on Espressobin v7 has additional build in hardware signature chip? Quick skim of the V7 schematics does not reveal any Microchip authentication processor. Would that prevent installing ARM recovery image to a vanilla board? Best regards, Martin My testing says yes, that chip prevents all kinds of things from working. The recovery USB fails with "no valid serial" and "no Thoth module found". Upon getting pfSense to boot on my Espressobin via microSD going a different route, I have also found that it cannot check for updates which I also believe is based on having a working CryptoAuthentication device. Would be great to see a community edition but they sure put in a lot of effort to prevent vanilla Espressobin devices from working. I don't mind buying the devices from Netgate, I just hope they don't EOL as quickly as some of their previous ARM offerings. I would imagine the espressobin will still be for sale long after Netgate stops selling a product based on it. Maybe that's when we'll see a community version. EDIT: Yes, there really is an extra chip inside. My SG-1100 has a cool little board soldered to GPIO.

Check this: https://docs.netgate.com/pfsense/en/latest/routing/unable-to-access-some-websites.html But I would check MTU or bad subnet/mask first. Steve

Thank you everyone. So both the fixed ip set on device and those set on pfsense must not be in the dhcp pool. I will have to change some of my fixed ips. I will definitely install pfblockng.

If you're using firewall rules based on url aliases and the firewall is using different DNS to the clients they may be resolving differently and therefore not applying. If those URLs resolve to many URLs such as, for example, google.com they will likely never be effective as the IPs change frequently. Steve

You can lagg the two SFP ports and connect them to your switch. That will hive you some redundancy but won't improve the speed since they are each 10Gb anyway. Using the SFP ports connected to an external switch does make it easier if you want to bring in a number of VLANs for example. You would have to tag those through the internal switch otherwise. You can use outbound NAT rules and port forwards for individual IPs in the DMZ if you wish. Or 1:1 NAT rules to achieve the same. If the /29 is routed to you via another IP you could just use it on the DMZ interface directly. You do lose an IP as the interface address though if you do that. Steve

So what is the actual problem here? You are unable to browse the web from clients behind the firewall? That blocked TCP:SA traffic looks like a coincidence to me if it's always from the same remote IP. It's something in particular triggering that. Do you have outbound NAT set to automatic still? Check the routing table in Diag > Routes, do you have a default route? How are you getting a WAN IP? DHCP from your ISP? Is it pulling a valid IP and gateway? I would assume it is since you can ping out correctly. Check you can open TCP connections? Go to Diag > Port Test. Try to open port 443 to netgate.com. When you try to open a webpage from a client what actual error do you see? Steve

I think this will help you https://docs.netgate.com/pfsense/en/latest/book/config/what-to-do-when-locked-out-of-the-webgui.html https://forum.netgate.com/topic/13464/change-firewall-rules-with-shell

Yup, connect over VPN is most secure method and hence the recommended one. https://docs.netgate.com/pfsense/en/latest/firewall/remote-firewall-administration.html Steve

@Pippin Thank you for show me the origin of the issue. Pointed on github.

EDIT: Full TCP dump of switching cables to fiber ISP and then renewing/releasing DHCP in the UI: https://gist.github.com/marshallford/f6fd85988b2ceaed882cec37038efcfd EDIT 2: TCP dump of plugging in fiber directly to linux laptop: https://gist.github.com/marshallford/c67afcfb121c13f20df8dc830fc50b13

That is out of the box how it pfsense is - nothing to do for that.. Not sure what part your not understanding about the default deny.. All unsolicited traffic inbound to pfsense wan is just dropped.

Nice!

I didn't see that one, but I'm not terribly crazy about adding even more JavaScript to work around that. Might be worth considering, at least.

You can block without trusting.. You have to use explicit (I believe), ie the client has to point to the proxy.. It will send the connect command for https, so proxy know where trying to go, and can either allow or deny based on that host name... What you can not do is allow say www.domain.com but block www.domain.com/something without doing mitm... Since onlly the host is sent in the connect. There is a hangout that I believe goes over this stuff - let me see if can find it. edit: here you go https://www.netgate.com/resources/videos/squid-squidguard-and-lightsquid-on-pfsense-24.html [image: 1563542241750-peek-amp-splice.png] edit: Also if all your looking to do is block access to sites, be it http or https wouldn't pfblocker be another option?

It seems that the secure shell daemon not have been running for some reason...all is good now.

Ok @jimp thanks for the feedback. I do hope you can add that to the roadmap, I'm sure it would be useful for many. Best regards.

Outlook Web Access. About the rules i have only one rule (from any to any). If i use HAProxy what settings do i have to make?

@jimp said in ext. LDAPS auth flapping after CA import -> only working after restart: Because of the, let's say "suboptimal", way that PHP requires setting up the LDAP environment for certs I really laughed hard at "suboptimal" That's why we love PHP ;) If you really want to be sure it works, then you could always use a CA for LDAP that can be validated against the global root CA list, like one from Let's Encrypt. Ah nice idea! Even if not possible ATM as that would mean re-organizing the internal AD and dependencies but a good thought for an update later along the road. I'd love to fix it, but the new method still isn't working in PHP: https://redmine.pfsense.org/issues/9417 Will have an eye on that one :) Thanks for the hint about restarting, after restarting PHP-FPM, WebGUI and the OpenVPN servers that used the LDAPS connection all is working again!

UPD: the same issue as described at the beginning of my post is happening when connecting switch to pfSense and RouterA and RouterB to that switch thus hanging two routers on one pfSense port. Seems to be not an issue with virtual switch on pfSense as in this scenario using only one port. Once separated Port5 and Port6 on pfSense to different private subnets and attaching RouterA and RouterB independently to pfSense box (+NAT with public VIPs) issue is gone. It appeared when both routers are connected to the same bridge or external switch they can't work reliably together. But I would still appreciate if someone can point me to the right direction how to investigate that further and perhaps with some Layer-2 debugging.