@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?

One thing to be aware of here is that the OpenVPN rules tab applies to all OpenVPN connections. If you have an OpenVPN server running already you probably have an allow all tule there so that connected clients can access resources behind the firewall. But when you get the ExpressVPN connection working that rule will also apply to it and you don't want to allow random connections from ExpressVPN! So make sure that rule it limited to your own subnet as source. Or alternatively assign your server as an interface the same way as the client and then you can apply the rules to those interfaces individually. Steve

It's very easily done. Ask me how I know!

If you are using pfSense on both sides as long as you're using IKEv2 and do not set 'split connections' it will do this by default. You will see one childSA created for all defined subnets on each side and it will carry traffic between any of them. But, yeah, I would probably use route mode IPSec (VTI) also. Logically easier to define. Steve

@stephenw10 Thanks steve appreciate it :)

@johnpoz said in autossh on pfsense: @_sko_ said in autossh on pfsense: tunnel let the MySql server to be configured in a more secure way So you have hackers or botware running on your local network? You stated that this "wan" is not connected to the internet. So who has access to this "network" where this mysql box sits? Your devices, your users? Are you own devices and users considered hostile? I stated wrong. Sorry but my english is a little bit rusty. The local network has a gateway and is connected to the internet but you are right just a too much complicated solution for the problem. I just enabled a rinetd rule for the pfsense firewall in the MySql server et voilà. Thanks!

@stephenw10 nada!