@stephenw10 Hi, I saw that too and checked for "SU" and "Su" and only "Internal_Subnets " exists so I have no idea where that came from either. I clearly must have accidentally clicked on on the Wizard at some point in the last few days and not noticed leading it to get very confused. It all seems good now though. Thanks again for your help G

I'm not sure what you're asking me. I personally use squid + squidguard in explicit mode with no SSL interception.

@hasan_ciit said in network subnet access between multiple tunnel: i have pfsense at azure cloud @hasan_ciit said in network subnet access between multiple tunnel: i have zabbix nms at azure Are both those things true? Without adding any additional P2s anywhere or using some sort of proxy at the pfSense site I don't think this is possible. Even with adding one P2 you could NAT the connection on one leg but that would then only allow opening connections in one direction and I believe Zabbix usually requires both. Steve

For VNC viewer to work in a locked-down LAN, you need to allow access from the client on tcp/5900. http://www.uvnc.com/onlinehelp/11.html

Looks like it's 192.168.88.18. I suggest that AP is not configured correctly. Try turning it off and see if that removes the problem. Steve

It may have come from a different subnet. Either way I did end up tracing it down to a faulty DIMM :) Thanks

Mmm, I mean it looks like an ACPI problem, like bad tables. You might update you BIOS if an update is available. You could try running vmstat -i see if that shows a device with high interrupt rates. You can also try booting in verbose mode and see if that shows any useful ACPI errors. Interrupt the boot at the boot loader and then enter boot -v. See also: https://www.freebsd.org/cgi/man.cgi?query=acpi&apropos=0&sektion=4&manpath=FreeBSD+11.2-RELEASE&arch=default&format=html Steve

Great. Thanks for confirming, might help others. Steve

It is probably time to consider more current hardware. It is definitely time to consider upgrading to more current software.

@stephenw10 said in pfSense has detected a crash report or programming bug.: Yup, copy and paste the error here and we can try to assist you further. Perhaps he can provide a crystal ball to assist us.

Probably no detectable difference.

For the firewall to resolve 192.168.1.100 for example, the PTR has to exist somewhere.. Be it unbound via dhcp registration, static lease registration or host override. Or some other dns that the clients are registering in, etc. Say for example if your AD shop, you should prob be using your dhcp and dns in your AD. Then just create a domain override for IP ranges so that you can go ask for PTR from your AD dns, etc.. There are multiple ways to skin this cat - but somewhere involves a PTR lookup from DNS somewhere your clients IP is listed.

Well that's no problem, just install pfSense with one interface and install Squid on it. Though you might consider running Squid just on FreeBSD instead if you don't need everything else that pfSense brings. If you want to run transparently you need port forwards in Mikrotik to redirect traffic to it. Otherwise you need to configure clients to use it directly. Steve

Any word on CMS?

The question for me is... is your diagram just a quick mockup to give us an idea of what you want to do or is everything already physically connected that way? A high-level, straight forward approach for accomplishing your goals would be: Create VLANs on the PFsense LAN interface Consolidate down to 1 managed switch and connect it to PFsense via a trunked interface Connect everything to the managed switch Configure firewall rules to control access as necessary There's no way to accomplish everything you're looking for as currently shown in your diagram. If you keep the transit network, you can establish connectivity by moving your servers to one of the other switches, but that would mean your VLANs would be terminated on the middle L3 switch and you'd lose inter-vlan firewalling capability. This would be the favorable design from a performance standpoint, but you lose granularity in your access control. If you want to keep the 3 switches and require inter-vlan firewalling, you can still accomplish your goals, but it would require a re-design and managed switches. You'd need to: Create VLANs on the PFsense LAN interface Re-configure the link between PFsense and the middle switch as a trunk Trunk the two outside switches to the middle switch Move your servers to any of the three switches If everything is in close proximity, personally I would consolidate down to one managed switch to keep it simple. Regardless of your design choice, in order to fulfill all of your requirements, all roads lead to managed switches and a re-design.

On pfSense 2.4.4, python 2.7 is available as python2.7. So your try.py could run one of a couple ways: Run the script using the correct binary: python2.7 try.py Edit try.py, change the first line to reflect the correct python binary, which will allow it to run with ./try.py #!/usr/bin/env python2.7 Make a symlink so you can invoke python 2.7 as python ln -s /usr/local/bin/python2.7 /usr/local/bin/python Note that in the future when python versions change, you would need to update whichever method you choose to point to the new binary, such as python3.6.

I imagine you would script it via something else. So maybe a RasPi running something that the phone geolocator can push updates to. That then runs a script to ssh into pfSense and enable/disable a firewall rule. Not something I've ever tried myself. Steve

You should not need any special settings for that. The phone connects out to Verizon on IPSec and routes the calls over that as far as I know. The default allow rules on LAN will pass that. You could check for open UDP port 4500 states when wifi calling is enabled to confirm that. IPSec can be affected badly by an incorrect MTU setting. You might look into that if the issue continues. Steve

If you have a serial console, leave a client open and connected to it, either with a large scrollback buffer or logging all output. Then monitor it during a reboot, see if you get any output. If you only have a video console it's harder to capture errors, but you still might see something. If there are no crash reports and nothing in the logs, then it's harder to diagnose. That said, it's almost certainly hardware if that is the case. If it's crashing under load, which could be from the encryption required to run the VPN, then most likely it's heat or power-related, but it still could be anything (RAM, CPU, etc)