@Gertjan It was a real issue and it's this is the Snort rules that generated it spotted it, I think that because it is a home network the bad guys assumed they could get away with it and pfSense plus stopped it cold and gave me the logs to report them. I have it on the WAN side the rules below. # === VPN SECURITY (OpenVPN UDP 1194) === # NOTE: Port corrected from 1192 to 1194 to match actual firewall # VPN connection from non-Approved source alert udp !approved source any -> MY IP1194 (msg:"CRITICAL: VPN Connection from Non-Approved Source"; classtype:policy-violation; priority:1; sid:1000010; rev:2;) # VPN brute force from MetroPCS alert udp approved source any -> MY IP1194 (msg:"OpenVPN Brute Force from MetroPCS"; threshold:type both, track by_src, count 10, seconds 60; classtype:attempted-admin; sid:1000011; rev:2;) # VPN connection flood (DoS) alert udp !Approved source any -> My IP 1194 (msg:"OpenVPN Connection Flood"; threshold:type threshold, track by_src, count 50, seconds 10; classtype:attempted-dos; sid:1000012; rev:2;) # OpenVPN malformed packet alert udp any any -> My IP 1194 (msg:"Malformed OpenVPN Packet"; dsize:<14; classtype:protocol-command-decode; sid:1000013; rev:2;) I reported it to IC3 and someone actually called me said it was really good stuff that I had, that it is a big problem in our area the last 8 or so months I think he said. This firewall caught something and it contributed to local cyber security. After he called, I have not seen as many of them anymore also. I also reported it to Digital Ocean and they responded to my report and thanked me for it. I have never had someone call me about a report before. The data was the combination of how many attempts and what was occurring they must have seen it before, maybe if you guys see vpn attempts from them we should start to report at least the VPNs that is like breaking and entering its no longer scans at that point. I feel like we see so much noise that when we start to see something that is real it get questioned, I was even thinking it was nothing, but they kept doing it.

Did you have a specific question? If you're unsure I would first try installing CE on whatever hardware you have to test it. Steve

If you have set that I would expect no issue since the server would reject any unauthenticated requests.

@nogbadthebad said in Using RADIUS server but on which device?: Out of interest how many access-points do you have ? I have a total of 5 Cisco 1700 Series access points connected to the controller

@teward said in pfSense: Certificate Export only using Legacy SHA1 or MD5 exports/signatures: @jimp I assume then that this will hit pfSense Plus, so for $FULLTIME_JOB I'll need to get us a pfSense+ license for commercial / corporate use. Because I don't know when CE will (if ever) receive the patch. The code is in the upcoming Plus 23.01 release. The code is also in CE 2.7.0 snapshots. You can apply the patches to CE 2.6.0 or Plus 22.05 and get it on existing systems if you prefer. When the OpenVPN client export changes are ready they will also be available on 2.6.0 and likely 22.05 in addition to 23.01 and 23.05/2.7.0

@stepinsky you would need to edit the subject (ie your first post) then you can edit that and add a tag of solved, etc.

And logins to other more remote sites will be encrypted with https or similar.

If I understood your question correctly. Ports can be opened or closed to allow or deny data transfer between devices. If you do not close them, an unauthorized user can access the data. Here you can see the details link text

@stepinsky said in OpenSSL vulnerabiltiy: pfSense affected?: I cannot judge the relavance of the vulnerability for pfSense users. That is the big question for sure.. The analysis is still underway at nist https://nvd.nist.gov/vuln/detail/CVE-2021-3712 This vulnerability is currently awaiting analysis. The key really being "If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit." Would that be something that could be done with how and when pfsense uses openssl? And it seems there is a patch for freebsd https://www.freebsd.org/security/advisories/FreeBSD-SA-21:16.openssl.asc So when netgate/pfsense feels its prudent sure they will make it available. edit: Well this openssl thing was in one of the many newsletters I get ;) In one today.. Doesn't seem like it is too much of a concern to be honest. Here is the article if interested https://nakedsecurity.sophos.com/2021/08/27/big-bad-decryption-bug-in-openssl-but-no-cause-for-alarm/

@kiokoman said in How to prevent users from LAN to know the external local WAN IP ?: in the 90's i remember there was this conspiracy theory that antivirus computers create viruses in order to sell antivirus software... say no more ... now that your isp know your fear it will ddos you to take your money ... big fish eat small fish ! Because amateur may be You newer come under real DDoS. P.S. Another perfect example of new attacks vectors, that You may newer know https://www.washingtonpost.com/news/innovations/wp/2017/07/21/how-a-fish-tank-helped-hack-a-casino/

The CVE was way way way more hyped than it should be. 100% a routing issue and not a "fault" at VPNs. https://github.com/stryngs/hysteria << For the answers

@eddiemcdiarmid said in Firewall Advice: Hmm interesting. I don’t have any rules but the managed of the network I’ve named ‘external network’ can see my router. Is there a rule I can add to block them being able to access my network? Seeing your network and accessing your network are two very different things. You say both in your reply post above. The default block/deny rules on every pfsense install for the WAN interface, like @johnpoz talks about above, keeps people/hosts from accessing your network. You don't need to do it, but if you're really paranoid about that external network, you could set a specific block rule in your WAN interface to block/deny it's IP addresses. Again, you really don't need to do it, however. This is an example of the default settings and wording from an old version of pfsense, but I think the current versions still look like this on the WAN interface: [image: pfsense-firewall-wan.png] Jeff

@thehermit Hardware encryption will probably be a requirement for v 2.5