Yeah you shouldn't be using public space internally, unless its your space.. That space is the French telecom "orange" If your devices are connected to the same wifi network and same AP.. pfsense has nothing to do with them talking to each other. And nothing to do with their discovery of each other through some L2 protocol. Discovery of chromecast https://developers.google.com/cast/docs/discovery

@batrams good to hear ;) You might want to sign up https://www.netgate.com/resources/newsletters if your log into your pfsense every now and then ;) setup the little RSS widget, so then you should see stuff about new versions, etc. [image: 1638719395510-rssfeed.jpg] Or just hang out around here - there is normally quite a bit of whoha about new releases as they come out.

Thanks. I'll do that with one of the devices that allows the public address.

I posted in the wrong forum. Looks like the issue was resolved in the development forum. $ sed -i '' -e 's/%%MIRROR_TYPE%%/srv/; s/%%SIGNATURE_TYPE%%/fingerprints/' /usr/local/share/pfSense/pkg/repos/pfSense-repo-devel.conf

Unless you have specific concerns about space or drive writes etc just accepting the defaults is fine. In general pfSense should never use SWAP and of you see it swapping it's usually because something is misconfigured. I still have some test systems that run from CF and on those I always disable SWAP because of the limited write cycles there. Steve

@johnpoz just whittling that down now. We don't think we've made any changes, but another service that streams has just started misbehaving on domained machines too. It effects all browsers so we are investigating the build... And as I type I am thinking the only other thing is ESET Antivirus updates as this all started happening at the same time. Servers are unaffected, byod too.

@artifice said in Random disconnects: I have been having some issues with the following error That is not an error. That shows dpinger starting and the values it's using. That typically indicates the WAN disconnected and reconnected but could be something else. We need to see a more complete set of logs surrounding the incident really. Steve

If it fails to mount root because of filesystem damage you can run a manual check: https://docs.netgate.com/pfsense/en/latest/troubleshooting/filesystem-check.html#manual-filesystem-check Steve

Ah, yes the UPS can simply not supply power again until it has charged to some specified level. Assuming it can be set for that.

You could be hitting the route-to/reply-to bug that was fixed in 2.5.2: https://docs.netgate.com/pfsense/en/latest/releases/2-5-2.html#rules-nat https://redmine.pfsense.org/issues/11805 Though I agree the nrpe service should not behave like that. That's probably an upstream bug though. Steve

These are worthy topics for discussion but we are derailing @cxcmax's thread I suggest moving to a new thread in off-topic to discuss VLANs in general. Thanks. Steve

@ikram syslogd - the system logger, received a signal '15', which means it received from 'above' a controlled process shut down. So it exited. If syslogd was one of the first processes to receive this signal, the shut down of all other process - and possible, the reason, are not logged so not known. Btw : if there was a lock up, there are no logs neither. The solution is : use the console (better) or SSH (best) access. Get connected. Start looking at at the command line around 23h50 and be patient. Remember : the GUI is only fine for when things go well ;) @ikram said in Reboot Pfsense automatically: the service cron is not enable In that case your pfSense would not function at all. The cron service is always enabled. I advise you to install the pfSense Cron package. You can see what's in it, what happens and when. [image: 1638442646138-68dbb7e6-a3e2-44b7-b31f-538e3f08b3ae-image.png]

@stephenw10 Legend, thank you so much :)

@stephenw10 Thanks Steve for your help its much appreciated. jkaay

@jc1976 said in website security problems: the walls are all brick and the signal is still strong all the way to my storage unit in the basement) Just because your see a strong single through walls, with some overpowered xmit power doesn't mean your little xmit in your device will be able to reach back through the walls ;) This is common misconception with wifi.. And even if some wifi device can see the signal and even if the AP has great reception sensitivity.. Devices connecting at the "edge" of coverage is not good for all the other devices on the wifi.. For best wifi all around - it is almost always better to have multiple AP so that clients that are connected to any specific AP have both good xmit and recv signal in both directions. Also spreading your clients across multiple AP also helps for overall performance of all devices involved. While there have been great strides with stuff like mu-mimo and beamforming and ofdma. 1 AP sort of setups are not going to be best sort of wifi, especially as the amount of wifi devices explode in number.. Quite often all over the house.. I have like 30 some wifi devices connected to my wifi at any given time.. Splitting these connections across multiple AP is better for all clients overall performance. If you feel running dhcp on this device of yours is best for you - then great, just make sure its not handing out info your not aware of, like pointing to itself as dns as well as maybe your pfsense.. Doesn't really matter where something like dns or dhcp runs in your network - as long as it works.. But a true AP would normally not have any way to be a dhcpd.

Viewing usage by logical interface is generally more used but I can certainly see a use case for this. You could open a feature request: https://redmine.pfsense.org/ Steve

My own fix/solution, locate section and replace if commented sections match. /etc/rc.update_bogons.sh # Set default values if not overriden v4url=${v4url:-"https://files.pfsense.org/lists/fullbogons-ipv4.txt"} v6url=${v6url:-"https://files.pfsense.org/lists/fullbogons-ipv6.txt"} v4urlcksum=${v4urlcksum:-"${v4url}.md5"} v6urlcksum=${v6urlcksum:-"${v6url}.md5"} # process_url /tmp/bogons "${v4url}" # process_url /tmp/bogonsv6 "${v6url}" rm /tmp/bogons rm /tmp/fullbogons-ipv4.txt.md5 rm /tmp/bogonsv6 rm /tmp/fullbogons-ipv6.txt.md5 curl --max-time 120 -k https://files.pfsense.org/lists/fullbogons-ipv4.txt -o /tmp/bogons curl --max-time 120 -k https://files.pfsense.org/lists/fullbogons-ipv4.txt.md5 -o /tmp/fullbogons-ipv4.txt.md5 curl --max-time 120 -k https://files.pfsense.org/lists/fullbogons-ipv6.txt -o /tmp/bogonsv6 curl --max-time 120 -k https://files.pfsense.org/lists/fullbogons-ipv6.txt.md5 -o /tmp/fullbogons-ipv6.txt.md5 if [ "$proc_error" != "" ]; then # Relaunch and sleep sh /etc/rc.update_bogons.sh & exit fi # BOGON_V4_CKSUM=`/usr/bin/fetch -T 30 -q -o - "${v4urlcksum}" | awk '{ print $4 }'` # ON_DISK_V4_CKSUM=`md5 /tmp/bogons | awk '{ print $4 }'` # BOGON_V6_CKSUM=`/usr/bin/fetch -T 30 -q -o - "${v6urlcksum}" | awk '{ print $4 }'` # ON_DISK_V6_CKSUM=`md5 /tmp/bogonsv6 | awk '{ print $4 }'` BOGON_V4_CKSUM=`cat /tmp/fullbogons-ipv4.txt.md5 | awk '{ print $4 }'` ON_DISK_V4_CKSUM=`md5 /tmp/bogons | awk '{ print $4 }'` BOGON_V6_CKSUM=`cat /tmp/fullbogons-ipv6.txt.md5 | awk '{ print $4 }'` ON_DISK_V6_CKSUM=`md5 /tmp/bogonsv6 | awk '{ print $4 }'` if [ "$BOGON_V4_CKSUM" = "$ON_DISK_V4_CKSUM" ] || [ "$BOGON_V6_CKSUM" = "$ON_DISK_V6_CKSUM" ]; then

@nollipfsense maybe? Maybe he just needs to set a reservation in his dhcp ;) Its not unheard of practice from a security point of view on firewalled segments that will have different rules to be different. So your not actually creating pinholes for specific IPs on a vlan. Either the whole vlan has access, or nothing does. And if something needs access to some other vlan or specific ips and services on a different - put devices that need this access in a different vlan where you can create rules for the whole vlan vs specific IPs on the vlan. But it does seems like a leap in concerns for smaller network, maybe in a datacenter or larger enterprise with very strict security policies. dhcp reservation would ensure his specific device(s) would be the only thing with that IP(s) that are allowed to talk to the server on port X. If really concerned, setting up static arp, and sure also run arpwatch to be alerted if the mac for IP xyz changes. edit: If you were really concerned - and your devices are wired, you could setup port security on the switch ports. This would prevent a device from changing its mac and gaining access to the network via different mac/ip combo that matched your firewall rules.

@kiraciro said in configuration error ACME: @stephenw10 yes great ... i updated and it works I would show a screen shot that you're indeed now running pfSemse 2.5.2 since you came here for help and got it.

@stephenw10 They certainly have a lot more scope for overheating, though personally I've only had one fail on me and it was a dirt cheap model off eBay. I have an Aquantia model running off that i5-8250U appliance at the moment as I decided if I weren't going to replace my router with it, might as well replace the old router I was using as a switch with a Linux box with the ports bridged and ~3.6Gbit uplink over that adapter.