@johnpoz My haprox cert is a wildcard cert *test.ca and in pfsense i created a Host Override as unraid.test.ca which points to the unraid server ip. By doing this, unraid.test.ca is only available via LAN as it is not registered on my domain dns. Also for my acme i have it set to auto renew that cert before it expires. Great suggestions, appreciate the tips :)

I got this working.. I created the opnvpn interface and then that showed up in the outgoing network interface under dns resolver which is had set as (ALL) and now everything works.

@stephenw10 said in all services fail to start all packages gone: Looks like this is the gw_leds script which it appears you're also running: https://forum.netgate.com/topic/165680/sg-3100-21-05-1-kern-ipc-maxpipekva-exceeded-see-tuning-7 Steve Thanks. I’ll follow that post.

I assume you mean you're not doing any internal routing but are still routing between WAN and LAN? Otherwise you would have to be bridging WAN and LAN. Either way in that setup both WAN and LAN are carrying the same traffic so it really doesn't matter which way you assign the NICs. Steve

When you put FQDNs in an alias like that they are resolved by filterdns when the ruleset is built. Anything that the firewall can resolve should work correctly there. Steve

@stephenw10 said in Bricked after Update 2.4.5-p1 to 2.5.2-RELEASE: Everything except checksum off loading should be disabled by default so I would look at LRO if you changed that. Steve I will leave the APU in place. The former device was cobbled together from spare parts anyway (but it worked for years...). Thank you for all the input.

Do you have consecutive sections of zeros replaced with two colons ?

The situation is largely unchanged. The pro services team can convert an existing config from another firewall but it's a manual process for them. There is no tool for doing it. Steve

Mmm, 2.4.2p1 is really old. With the release of 21.05.1 though there should be much reason not to be on that now. If you absolutely need Snort (and can't use Suricata) for some reason you might want to stay on 2.4.5p1. Steve

@stephenw10 thanks yea I worked out my problem. Because I has a rule at the bottom of floating that blocked anything I didn't specifically allow out, I then was allowing WAN to HTTP/HTTPS for Squid and it was quick matching. I had to rejig that block all rule to avoid HTTP/HTTPS so that it allows that traffic by default (No quick rule allow needed for WAN) and then I catch any bad traffic with the explicit deny rules. Seems to work now.

@stephenw10 Yes, ZFS after reinstalled 2.5.2. Bug seems to be known and would be fixed someday... as you said, its just cosmetic :-)

Yeah gmail is a bit special - can you get it to work without 2fa? Maybe?? Don't know, don't care - have had 2fa on since like 2014, and I was late to the party ;) But just tested this with one of play domains, no 2fa - just your typical smtp server over 587 works just fine.. So clearly pfsense is parsing special characters in the password. And his issue is most likely do to the special requirements of gmail.

If there's nothing in the logs then I'd run a packet capture to see if those ping are making it to pfSense at all and if it's responding. No response to 5 pings it something significant though. An IP conflict maybe? Something ARPing with the same address could do that. Steve

It seems that I fixed the issue: Static IP should be : 10.66.66.2/24， but not： 10.66.66.2/32

@jgq85 said in Occasional ping timeout when pinging local network and weird issue.: Could ping failing be at all related to a DHCP/DNS server configuration? To dns - possible if your trying to ping via fqdn and dns failed and you would not be able to resolve what fqdn your trying to ping. But from what you posted that seems unlikely with all of the ips failing with the same amount of losses. Seems more like you had something that the machine that was pinging had a intermittent connection problem. or you switch blipped? Something on your network caused everything your pinger was pinging to not respond. So either its connection or the really the whole network was problematic. If it was dhcp related - its possible a client lost its lease, and had no ip, etc. But all the ips at the same time? It could of been your pinger machine? But once a lease has been gotten, its good for the time of the lease, etc. And only when it runs out would it have to renew.. Very unlikely to be related to dns or dhcp to be honest. Did all the 5 failures for every device happen at the same time.. They all have 5 ping losses. For being local these ping times are fairly high, 34ms - locally? That has to be wifi, and bad wifi at that.. How do you have 7ms average to google and 17,18, 34 to local IPs?? Here is ping times to my wireless harmony hub.. Which is on a different vlan that my pc ping it is on.. So its routed through pfsense, and still average of 1ms.. Ping statistics for 192.168.7.96: Packets: Sent = 26, Received = 26, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 1ms, Maximum = 6ms, Average = 1ms Control-C Really anything locally should be like 1 or 2 ms.. Sure wireless could give you some higher than that... But average of 34 ms to something locally - there is some off there..With min being 33?? Local wired should be sub 1ms to be honest.. What your using for ping might not support showing that? There are some tools that can report sub 1ms hrping, fping for example.. Here is what typical wired pings should be locally - you can see most are sub 1ms From 192.168.9.253: bytes=60 seq=0019 TTL=64 ID=0a7c time=0.410ms From 192.168.9.253: bytes=60 seq=001a TTL=64 ID=00a9 time=0.550ms From 192.168.9.253: bytes=60 seq=001b TTL=64 ID=9aa3 time=0.517ms From 192.168.9.253: bytes=60 seq=001c TTL=64 ID=3783 time=0.518ms From 192.168.9.253: bytes=60 seq=001d TTL=64 ID=c3d4 time=0.460ms From 192.168.9.253: bytes=60 seq=001e TTL=64 ID=9a27 time=0.530ms From 192.168.9.253: bytes=60 seq=001f TTL=64 ID=02b0 time=0.883ms [Aborting...] Packets: sent=31, rcvd=31, error=0, lost=0 (0.0% loss) in 15.010389 sec RTTs in ms: min/avg/max/dev: 0.342 / 0.667 / 4.004 / 0.659 Bandwidth in kbytes/sec: sent=0.123, rcvd=0.123 Seems really really odd that all your local are so high, but to 8.8.8.8 ts average of 7?

@fredordetre Wow. That is incredible. It's also proof that sometimes the root cause is out of our control and you just need to get someone to actually listen to what you are trying to tell them. Glad it got figured out.

@stephenw10 Not remembering how I had OpenDNS set up. I am only running pfBlockerNG. I have both IP and DNS-BL set up. Also no RAM Disks set up. Was in a hurry to get back online for my job. So after a few hours I gave up trying to figure it out and just fell back. Probably just chalk it up as an unknown. You have answered my questions. Maybe another time I will try OpenDNS. But afterwards I will reboot to make sure it holds.

It can't access a certificate revocation list so it can't check if the server certs have been revoked. That's not a problem for the connection though. I doubt Nord publish a CRL, though I've never looked into it. Steve

@stephenw10 Some home routers provided by ISPs have a 'DMZ' option that can be used to connect a downstream pfSense firewall WAN interface. You can continue to use the home router's LAN for the connections in the home that you don't want protected by pfSense. E.g. guests that just want to use your home router's WiFi without you monitoring their traffic. Your real LAN, sits behind pfSense and is only connected to the pfSense LAN interface. It is not directly connected to the home router. The pfSense WAN interface is connected to the home router by Ethernet cable and the home router's DHCP should be configured to serve a static/reserved IP address to the pfSense WAN interface so it has the same 192.168.1.x IP address every time. When the reserved IP address has been configured as a DMZ in your home router, all incoming traffic to the home router will be presented to the DMZ IP address. I have seen this implemented differently on different devices. Some will bridge the DMZ port so that pfSense will show an external IP on the WAN interface. Some will just NAT the traffic so pfSense sees the 192.168.1.x address on the WAN interface.

Yeah, I would try that if you can. You might also try booting FreeBSD 12.2 (or 13) and see if it does the same. Or a 2.6 snapshot.