@aysman The state table gives you information about active connections. Go to Diagnostics > States to view them. You can select a specific interface where the PCs are connected to and enter a filter expression, e.g. ":3389" for the default RDP port. If you also want to see the history add a pass rule to the respective for destination port 3389 or whatever and enable the logging. Then you can look for connections in Status > System Logs > Firewall.

@sylvain said in Unknow Problem ... maybe Hardware Failure: panic: NMI indicates hardware failure A Non-maskable interrupt (NMI) is always a very heavy problem that is in almost all cases a hardware-problem. A reinstall of pfsense ... i doubt that that will be helpful. Maybe boot the machine with Memtest and see if there are any errors. (If it is possible) My 2 cents, fireodo

Running a speedtest at each end if not using the same route as traffic between the sites so you may simply not be passing whichever hop is throttling you. If you can't see the speed with iperf though you will never see it in FTPS. Steve

So after a chat with my ISP they offered me a free public IP, all my rules work again!! Thank you all for the help i'd never come across CGNat before. The more you know.

@stephenw10 Thank you

@sabsan that is SSDP normally - yeah your going to see in logs.. But as that looks spammy as get out.. (looks like only 2 seconds).. I would look to that device to turn that spammy noise off. But if not setup a rule to not log that..

@dhenzler found my mistake, and corrected it. pfSense not at fault.

To add it here: Customer has updated to a newer RC-snapshot as the earlier got him a few report emails of the box for getting packet loss sometimes (not that often) and he wanted to check if that would be fixed, too. On the latest RC snapshot thus far no problems to report. No crash dump, no freeze, no panic. Also the packet loss seems gone too :) So happy on both fronts for now - makes me happy to report that. Great job everyone involved. Shoutout to TAC support for their help and staying on the topic, too! Cheers \jens

@burlinwa said in Business Scenario for 6 port setup suggestions: Thinking about Phones, badge/security/access @burlinwa said in Business Scenario for 6 port setup suggestions: and 5 workstations) Glad to have gotten the conversation started. First, I thought it was some top secret corporate mission with the retina biometric security entry access...now I know it's a five person driven team.

If you don't have and traffic shaping in play I would check the link is correctly at 1G in each connection in the route. Though if something is linked at 100M that would affect both directions. An asymmetric route somewhere might allow that. Steve

It should definitely be possible to make this work with a double NAT type setup. Just make sure the subnets used don't conflict. The '192 range' contains a large number of /24 subnets. Make sure the pfSense LAN is using something different to the 5268AC LAN. Steve

OK so two seemingly independent problems. The schedules rule appears to be on the WAN carrying SIP traffic port forwarded traffic to the PBX. That does not carry RTP traffic so calls would not immediately drop. Nor does it carry outbound SIP traffic so I would expect to still be able to place calls but not receive them outside of the schedule. Is that what you see? Steve

@rcoleman-netgate De rire

@stephenw10 Yep, that's another possible issue : Installing a package (always the latest version) on a pfSense system that is not on the latest (2.6.0 if you use the free edition) version can work out fine. More often it breaks stuff. That's why : If you decide NOT keep pfSense on the latest vesrion then you also decide not to upgrade / install packages any more. Not respecting this rule is like playing with a six barrel gun and a bullet. ( we all saw the movie Deerhunter ones in our lives, right ? ) Read / click on the image : [image: 1655717628991-0c26b335-292e-4d62-bafd-2840b0cfa267-image.png] Note : with some 'small' packages, like "Notes", you might get away with it. When you see this : [image: 1655717764197-6b4a7c6a-5366-4380-afa8-da3e98de2a03-image.png] and you see that huge stuff like php74 gets pulled in - and knowing that pfSense uses also php7x for it's WebGUI, I would consider that as a huge red flag.

@luckman212 Thanks for response. I think the messages are standard response sequence of DHCP lack of response on the WAN interface. Of course I do not have much of a baseline but turns out the ISP has had a LOT of issues over the last week in our area. I assumed it was me.... I think it is / was them. I will post as I get better baseline.

@stephenw10 Thanks!

Potentially it could have been a failing disk causing that shutdown panic, yes. Certainly there is a problem with it if it disappeared from the BIOS entirely. Steve

Yep, I'd check your NAT statements. You'll also want to isolate whether you actually can't get to the internet or have a DNS issue. Can the clients resolve google.com? Can the clients' ping 8.8.8.8? Can you ping 8.8.8.8 from PFsense when sourced from the OPT9 interface? Are you using the Forward or the resolver? If using the forwarder, is it listening on the OPT9 interface? If using the resolver, two questions... is it listening on the OPT9 interface and if you're using ACL's... was 192.168.243.0/24 added to the allow list?