Most every time I've had a system shut itself down mysteriously it was due to a BIOS overheat event. Might be something that only happens under load, and happens very fast.

yup, for sure, thanks again for your help!

I doubt it. This post is four years old, and that user has not logged in since November 2017.

@OpenWifi said in Which software to use for bot detection over Lan: I believe this means clients on the lan would not be able to send mail!! Again, you admin a firewall. There is no such thing as "Wondering" and "Believing". Things happens because you let them happen. And things that you do not want, you stop. You are the boss. A boss doesn't "trust" or "believe". Maybe this is new to you : Mail clients like Outlook Express, Outlook (Office) or Thunderbird should not use port 25 to send mail. They are set up to use (as stated) above : port 587 or port 465. These two port permit some one to send mails, if they can authenticity themselves first == have an account at that mail server. Like : you can not send mail using mail.gmail.com on port 25 : gmail does not allow this. gmail is not an open relay. You should use 587, no, better : port 465. For historical reasons, ISP's allow that you use their mail servers so you can send your (not your unkown visitors !!) send mail to some one. This is an exception. Do understand that the ISP knows who you are : you are using their "land line" to connect to their services.

@stephenw10 is correct. It seems the DNSBL feature of pfBlockerNG is intercepting the attempted domain-to-IP lookup made by your phone and instead of sending your phone the real IP of the domain it is redirecting your phone to the internal web page hosted by the DNSBL code. That's what the 10.10.10.1 address is. This is the problem that can result from using tools that use IP blacklists as the basis for their block decisions. Many of these lists are not always 100% accurate, and they sometimes tend to broad-brush when marking IP subnets as malicious. What I mean by that is they can unintentionally blacklist an IP address that is actually OK but just happens to be located within a larger block the blacklist is marking as bad. Of course it is also possible that DNSBL is flagging the IP block because it serves up ads.

I've spent some time looking over the code for DDNS, and I see at least three files that would need to be changed in order to add support for PUT to the "Custom" DNS provider. src/usr/local/www/services_dyndns_edit.php src/etc/inc/dyndns.class src/etc/inc/services.inc I'm thinking of adding a new flag 'curl_use_http_put' similar to the existing 'curl_ssl_verifypeer' flag so that the "Custom" provider UI will display a new checkbox to capture the option in "src/usr/local/www/services_dyndns_edit.php". The flag 'curl_use_http_put' would need to be passed to "src/etc/inc/dyndns.class" where the logic to act on the flag would evaluated. One thing I don't yet understand is how the configuration is persisted. Would someone provide an overview of how the DDNS service is initialized and settings persisted?

Yes you can see URLs in https (and http) traffic using Splice mode which is also explained in that hangout. https://youtu.be/xm_wEezrWf4?t=935 Steve

Thanks a bunch, that was exactly what i was missing. Now that you mention it, i feel stupid for having overlooked it. I should have checked the routing table first i guess, then it should have been obvious. Again, thank you very much.

@lost89577 said in Snort: MD5 Hash - Rules Updates - Insecure?: i know this is a long dead topic, but to validate the concern raised. A man in the middle attack was used against my firewall to supply blank sort rules which validated as latest version in snort. The attacker stopped some time after i side loaded the real rule set. i believe it was my ISP proxy that was compromised and no i don't believe i was the real target but all of the ISP users. If you have to get to the web through your ISP's proxy, then your security is hosed from the get-go. The Snort rules URL is an SSL-secured site, so without the proxy you can be reasonably certain you are getting to the correct site based on the SSL session setup the CURL code stem uses within the Snort GUI. With the proxy, and you trusting the proxy's certificate, then you are wide open to your ISP and then to anything or anyone that compromises your ISP. If your ISP won't let you bypass their proxy, then I would be trying to find me another ISP!

Thanks for confirming @stephenw10 . I will transition the server from the LAN to VLAN and leave the LAN unconnected.

Sorry, muscle memory doesn't allow me to type Negate. I'd still be interested to know if you have that rule present. I would assume with a now valid queue. Steve

Glad it's working! Just a note for down the road, eventually you will want to remediate your double NAT situation. In other words, have the ISP configure their modem in bridge mode, so PFsense gets a public IP.

Ok was definitely not the device upgrade, that didn’t happen till the 29th..

@stephenw10 Thank you very much for help and advice! Problem solved.

Unless you have disabled it pfSense will be NATing traffic for 192.168.1.1 to it's WAN IP, 10.65.1.2. Since we know the other side can ping that IP we know it has a route back, hence traffic from the pfSense LAN gets a response. But we don't know the remote side has a route to 10.65.10.X or 10.65.15.X. Nor do we know the MPLS infrastructure knows about those subnets. It looks like a missing route somewhere to me. Once you have that route in place you probably want to disable outbound NAT for 192.168.1.1 so devices at the remote site can see the correct source IP. That makes troubleshooting far easier for one thing. Steve

Install it and have a play it’s not hard to do. Also check out the pfSense videos, @BBcan177 goes over setting up pfblockerng. https://www.netgate.com/resources/videos/pfblockerng-on-pfsense.html

Yes, you will need to use the IGMP proxy to make this work and it will need to be at both ends since there are three subnet involved here. The only other thing you could do use an OpenVPN TAP connection but that would likely require significant network change and introduce other issues. Do you have to use that 'app'? It seems not well suited to your situation. Steve

Mmm, in fact it may not be required as it's a PPP link. I was thrown by your mentioning of DHCP. With a point to point link the traffic should reach the gateway even outside it's subnet. You may just need to set a different monitoring IP. The gateway might not respond to ping. Edit the PPP gateway in System > Routing > Gateways tab. Set, for example, 8.8.8.8 as the 'Monitor IP'. Steve

You should upgrade to 2.4.4p2 when you can. Try swapping the WAN and LAN NICs so that WAN is using the on-board real NIC. See if the failure moves to LAN. Ultimately there are no recommended USB NICs. If you're lucky you might find one that runs reliably. If you do find the LAN now fails after swapping them consider using VLANs and a managed switch instead. Steve