That's what the device reported as its hostname. Normally the DHCP daemon wouldn't allow invalid text in there, but that's up to the ISC DHCP daemon, not us. We just list what's in the lease file.

@hechtd, disable RFC1918 Network. Go to Interfaces > LAN > Reserved Networks > unchecked Block private networks and loopback addresses (RFC1918 Network).

@Derelict I had my hostname already set correctly to pfsense. But I hadn't changed my domain name. After changing my domain name, it worked. Thanks.

Ok, well it doesn't appear to be actually pulling an IPv6 address or at least a gateway it can reach. Do you have IPv6 connectivity? The VPN gateway will show pending until the client connects, that's expected. Steve

@AKEGEC : your second rule : include TCP. Your first rule : WAN is blocking everything, even for these devices : @AKEGEC said in DNS leak: but for some odd reason Pfsense responds differently with different hardware so the default block all rule will do it's job. If for some "odd reasons" devices could penetrate the firewall I recommend changing the firewall and/or the person that admin's it.

Ok, that's pretty generic. No way to pin down stuff in netisr_dispatch really. The thing to check is if other crashes have the same or very similar backtraces and panic strings. However, and JimP said, ESXi 6.0 does't support FreeBSD 11 and hence pfSense 2.4. You really need to get that upgraded before doing anything else. Steve

@Derelict said in Pfsense won't boot after power failure: Boot to single user (S at the logo menu), press RETURN for a shell when prompted and run /sbin/fsck -y / Keep running it until fsck stops complaining (maybe three more times). Then /sbin/reboot/ Thank you for your input. I did EXACTLY has stated, except the last part. I had to type reboot instead of /sbin/reboot/ in order to reboot. After it booted back up, everything was working perfectly!

Right now im not running HA pair , i restore my firewalls and only one is up in standalone. I use Nat Outound in automatic mode Yes still have loss connectivity despite the fact that the configuration is at the minimum. Loss appear after hours. I see my gateway in ARP Table. still looking for solution... Thank you for helping me

Bump.. No comments about Jimp’s suggested solution Is unavailable when you use the the more modern and secure IKEv2 EAP based solution?

ok thank you, will delete rule

Yeah HAproxy would be the way to do it, and you can do ssl offloading so all the certs are managed in HAproxy, and sure use acme to do the certs, etc.

In the end, the choppy video calls were also caused by EMI over a 40 meter long shielded CAT6 cable for the WAN connection. It went right behind a mini fridge, so I guess that worsened the EMI. I had to set up a fiber link between two switches and send the WAN connection over a separate VLAN on the fiber trunk.

I can't imagine that being a specific issue. Basic config. If you are able to disable the service as a test though I would do that. Otherwise I would be comparing other crashes with that to see if they are all the same. Steve

In terms of the packet loss - probably not. Unless one of those links has gone bad and you only see packet loss in connections that happen to use it. A 4 way lagg (LACP I assume?) is probably a waste there, I would go down to 2 way. That would allow you to unplug one link at a time to see if either is bad. You should also be able to see errors on the interfaces that make up the lagg. One will be a lot higher if it's a bad port/cable. Steve

@Ziomalski said in pfSense sends packet as 0.0.0.0: I noticed the P2 negotiates 0.0.0.0/0 for local/remote. That is normal for VTI and not related to this isssue.

Ok the first thing I would do there is switch to VirtIO NICs in KVM unless you are doing so9me sort of hardware pass-through. That will mean re-assigning the interfaces in pfSense when it boots back up as they will appear as vtnetX. I would also try setting the CPU type as host which I have seen improve things there. You almost certainly don't need anywhere near 32GB RAM. Steve