@SteveITS Thank you for answering all my questions. I just found a managed smart switch that I'll try to create a few VLANs here. This forum always helps even if I'm too confused to properly put out my doubts. So thank you.

Probably the latter. It will not kill the connection to fail back. I assume you mean for an OpenVPN client running in pfSense? Though for external clients connecting to a gateway group the same would apply. In both cases the system prioritises maintaining the connection over failing back. Though in 24.03 this can be overidden: https://docs.netgate.com/pfsense/en/latest/config/advanced-misc.html#state-killing-on-gateway-recovery

The backtrace and end of the message buffer before the panic are most helpful there. Can you upload the full crash report(s) here? https://nc.netgate.com/nextcloud/s/n2e9iLQTRSYXY4X

@keyser Took the advice and re-installed pfblocker without keeping settings. So far so good. I have no idea what was wrong with the configuration prior. I'll keep monitoring but so far it looks good. Strange one indeed.

What's different about the subnet/interface that can reach it? When you try to reach it from the working subnet check the states that are created. Compare that with states created when trying from a failing subnet. Check the firewall logs. Connection refused instantly implies something is responding that it's blocked. The default pfSense block rule doesn't do that. So it may be incorrectly routed or denied at the target device. Your block 1918 destinations would block this connection since NAT happens before firewall rules. The NAT reflection rules should translate the destination from the CARP/IPAlias VIP to the internal server IP and that would be blocked. Are you trying to connect using an FQDN? Does that resolve to the public VIP? Steve

It might have a DMZ pass-through option that simply forwards traffic to pfSense. But that may not be useful if you want to use the public IPs separately.

Hmm, odd. Hard to imagine that it doesn't like running cooler!

@meowmere said in Pfsense 2.6.0 CE - No internet access: could it be from the ISP router configurations that I have to change? You tell us (the details) and we'll tell you ^^

@scilek I've edited my post, I was posting the wrong link. CE link is now there.

@wendel_gt did you enable clam av it updates at night try to disable it you might not have the memory for it

@VioletDragon Same thing. On pfSense, or elsewhere, that all good. remember : processes communicate with 127.0.0.1 = local, to some locally running process, or for example to 192.168.1.10, some device on pfSense LAN, with the same process on that device.

@SteveITS Yes indeed, i found something of this and i edited the .vmx file like i found online. ethernet3.allowGuestConnectionControl = "FALSE" ethernet3.virtualDev = "vmxnet3" ethernet3.networkName = "Wireguard" ethernet3.addressType = "vpx" ethernet3.generatedAddress = "00:50:56:af:20:15" ethernet3.uptCompatibility = "TRUE" ethernet3.present = "TRUE" nvram = "Nieuwefirewall.nvram" vc.uuid = "50 2f 1b 11 f4 3d 4f cb-d2 42 74 21 30 1d 6b 79" ethernet0.pciSlotNumber = "160" ethernet1.pciSlotNumber = "192" ethernet2.pciSlotNumber = "224" ethernet3.pciSlotNumber = "256" scsi0:0.redo = "" virtualHW.productCompatibility = "hosted" floppy0.present = "FALSE" I added the new one here and added the ethernet 3 now everything boots and i get the new adapter and WAN, but.. ofcours there is a but.. 1: If i now go on my lan to the https;//192.168.6.1 site i get nothing, is not loading 2: i NEED to set the ethernet0.pciSlotNumber = "160" on the VMX0 or it does not work BUT i also see that scsi0.pciSlotNumber = "160" is also on 160, if this a problem?

@stephenw10 I guess this cements the death of PFSense CE for me now. I guess it's off to OPNSense for whatever I build next. To bad as I would have gladly paid for basic support - but they got rid of that program too years ago.

@viragomann yes yes, everything is in SSL/TLS and works perfectly in ogni server with the configuration /24 and cmq also activated in CSO

@kirenpillay said in UPNP not detected across 2 private LAN interfaces: more specific terms "upnp" is pretty generic (common) indeed - half the planet seems to have a play box thus huge network problems. But "avahi" is very, enormously unique. Throw this one in any search engines out there and you'll know what it is, does, why it exists. True, what is does is rocket science for the most common mortals, but you're not one them, these days are over. You've installed pfSense ^^

@diehard_02 Normally, I don't use IP block lists, as I don't need a tool that forbids me to go somewhere, if I don't want to go there in the first place. But ok - let's install pfB_PRI1_v4 : [image: 1721975609053-ee4fdc0a-9804-4b9c-abf9-62c0f0d171b6-image.png] and activate it so it block outbound connections : [image: 1721975570797-80c4f7c2-b068-4e3d-b0bb-a86e8f85d987-image.png] After a Force reload : [image: 1721975656310-c95b3e02-c7e7-4a0d-a9ba-5c0a53d8cb64-image.png] all is set up : I've now a floating rule that blocks all IPv4 addresses/networks that are in the list : [image: 1721975701767-f1edc018-bb9d-48bf-a73a-1d7f49945496-image.png] Let's look at the list : https://rules.emergingthreats.net/fwrules/emerging-Block-IPs.txt [image: 1721975755342-0f44c70c-ca51-43e2-ac92-88649fce2947-image.png] and take the very first IP (IP? not the network !) as an example : I take a browser, and go to : [image: 1721975797605-2e5e5021-d9de-41fb-9a5e-d17238d825ac-image.png] and sure enough, after some time : [image: 1721975814536-44562a39-7245-4e82-ace1-76fc5d735744-image.png] The pfBlockerng alert tells me the same thing : [image: 1721976002371-d45d24e7-30ac-41c5-b65b-702bf3f97a87-image.png] and under IP Block stats I see the same thing : my PC, 192.168.1.6, was blocked when it tried to access 1.10.16.1 : [image: 1721975924106-53c6353f-7329-4e81-a73b-a7011738b82b-image.png] Ok, I add this IP to the white list of this feed : Click on the black round +symbol : [image: 1721976285576-f1d49b39-94b8-4b63-b71a-1c40fb03b205-image.png] You are probably asked if a whitelist should be created, and if you want to add a comment, etc. Now I wind up on this page : [image: 1721976384144-afcd7a72-afcf-4291-ad17-1021dc603c44-image.png] and at the bottom I can see that "10.16.10.1" was added. Save this page. When force reloading, I can see that I have the original feed, and the whitelist : [image: 1721976802618-5a12009a-df70-4163-8d6c-3388f47584db-image.png] Sure enough, 10.16.10.1 wasn't a web server, so my browser, still can't connect to it, but this IP isn't blocked anymore. When I visit it again, the IP block counter doesn't rise = the IP wasn't blocked by pfSense. edit : Just to be sure, as this is not a click contest, but we're still managing a firewall the old classic way : [image: 1721979684913-bbb8e55d-8c3e-42e9-b44a-a1534e39b2bb-image.png] Check that the new Whitelist or permit rule is above the block rule. My white list rule hs taken 'hits' : [image: 1721979754393-ca77e322-0a9c-4ab9-b99e-4438cdec4368-image.png] which means that the rule (with just one IP in it) matched outgoing traffic : that was me trying to contact 10.16.10.1 with my browser.

@bigtfromaz you could maybe limit the outbound nat for only the device you would be coming from lan with. Like your pc... But yeah that works.. If you just add the route as persistent it should survive reboots, upgrades, etc. you shouldn't need a batch to kick off on startup. I would normally allow ping as a way to validate connectivity..

@Stassz You didn't answer @Gertjan 's question...what version of pfSense are you running???

I figured it out - I should not put my authoritative server under the domain override section because unbound put it in a forward zone and expects a dns resolver. Instead, I switched to a stub zone under custom configuration, which requires an authoritative dns server and unbound will perform recursive lookup itself.