pfSense uses the dpinger daemon to monitor connection quality. It pings something on the WAN twice a second, by default it uses the gateway IP as that;s what it always has but you can set any IP. It's almost always better to use an external IP as that then actually monitors internet connectivity as opposed to just to the ISP. https://docs.netgate.com/pfsense/en/latest/monitoring/using-an-alternate-monitor-ip-address-for-gateway-monitoring.html What you are describing though starts to sound like a possible modem issue. What is the modem they have there? Steve

@mikeisfly said in Notification when a connection is established: or a packet capture. Check a build-up of of such a packet. You will have your router's MAC (= pfSense), the cameras MAC, the cameras's LAN IP and the IP (WAN IP) of the visitor. Not the payload, as it is all TLS these days (well, the camera should send over TLS, other scrap it). At most, you could see who - from the outside world - visited your device. If it isn't recording, as you can check using the same access time, then you will not know what they saw. Btw : One of world's most famous and most used free programs, fail2ban, can do what you want right out of the box.Comparable programs exists. Btw : my DVR's - see above - logs user access by login code ... everything is already there.

There are only 100 packets there, it's all outbound from 100.92.220.245 and none of it is DHCP. But you should start your own thread. Unless this turns out to be identical it's only going to confuse things here. Steve

Nice. Let us know if you are able to connect, that would definitely need looking at if so. The generated ruleset on the secondary looks good here though. Steve

The best way is to remove the SWAP partition at install time. If re-installing is an option for you.

@johnpoz @jimp that's exactly what I was missing, thank you for pointing that out. Lesson n.1: There are different types of layer 2 switches (managed and unmanaged), some of them support 802.1x protocol and some of them not. Lesson n.2: The 802.1x authentication is done at the layer 2, before the IPs are handled to the devices. When packets reach the layer 3 is too late to do any kind of 802.1x authentication as the devices were already authorized to enter the network. Cheers!

Just because you have something that will relay or forward (that device that has access to both L2s) doesn't mean its going to work with alexa or google home or homekit, etc. etc. Not without some major background work and setup most likely, and understanding the details of how your device you want to say wakeup X actually does that.. My Alexa can turn on my TV, and off.. but I have my harmony remote in the same vlan as alexa, while my tv is in its own vlan. Both of these vlans are different than my other vlans. It would prob work without even... Since the harmony remote isn't in standby and the alexa should be able to talk to it over L3. But trying to find ways to move L2 data into another L2 is not the right approach.. Correct design of your L2s is better option from a security standpoint.. You need X to talk to Y via layer 2 - then put them in the same layer 2, its really that simple!!! Isolate that network from your other stuff.. Do you trust alexa... do you trust your tv, do you trust your iot - well no that is why we isolate them.. But if X needs to talk to Y via layer 2 stuff.. The simple solution is just put them in the same L2 ;)

There are lots of things you could do with running your dhcpd on another box, if that is what they want.. Be it windows, freebsd, linux, etc. etc.. That you can not do with pfsense dhcpd instance.. Multiple scopes without having to have leg in the network for one thing.. Reservations inside the pool range, etc. While the dhcpd setup in pfsense is easy to use and has easy to use gui, etc. Not all the features of running say isc dhcpd on some other os or box.. But turning off dhcpd on pfsense has zero to do with running unbound (resolver)...

Thank you all, i modified configuration via web configurator and it works perfectly. Thank you again. Roberto

Nice catch! Thanks for the follow up.

@AndrewZ I don't know if there is a permanent virtual circuit for voice.

Many years ago we did a hangout on this: https://youtu.be/1wfjv3j57KI?t=1228 Gui looks outdated now but the principals are all the same. Not sure what potato converter was used from Fuze. I would probably switch to tftp server that does log what's happening at least as a test. Steve

Ah, bad cable, bad port maybe?

@ThePieMonster said in Network Setup Suggestions For XG-7100: Are you saying that I can delete the VLAN groups 2,3, & 4 in the following screenshot? Yes, you only need those defined there at all if you want to truck VLAN through the on-board switch. If you're using ix0/1 directly for VLANs the switch plays no part in that. Steve

I thought pfSense was working on the Pi, since Gonozopancho did it, but I guess he didn't make a how-to. ;) OK, so that's out. As for ad hoc network I had even forgotten that the damned thing excisted, from back in the 90's when it was actually in use! ;) I agree that if it had been a cowboy car factory (like so many electric car companies now) it could be a problem, but Mitsu has been around for a long time, so I wouldn't be more scared about them stopping the service then Volvo doing it for my car. And malware is not really a thing with simple stuff like setting the heater, but with a Tesla I agree it could be a problem. I will take the extender out there some time during next week and see if that picks up anything, thanks!

Simply creating the group will not do anything beyond giving you a new tab in Firewall > Rules. Steve

@stephenw10 said in [Solved] Ooma not working: You shouldn't need any of those ports forwards. Exactly - says right on their site, these are "outbound" ports https://support.ooma.com/home/advanced-connections-and-service-ports/ [image: 1581775000360-outbound.jpg]

If you saw that limit between two hosts in the same subnet that traffic goes directly, or at least it should. pfSense never sees it and cannot do anything to affect it. I would have to guess something is misconfigured on the client. Steve

Hard to give any specific advice without knowing exactly how it's setup. But in general... Try to access the webgui from another device then: Check the firewall logs for blocked traffic from the test client. Check the state table in Diag > States for open states from the test client to pfSense on port 80 (asssuming you're using http still). Run a packet capture on the internal interface the test client is connected to. Filter by the test client IP and port 80. Is that traffic even arriving at pfSense. Steve