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)

You were right man. I did get an answer.
The book is very well done though, thanks. In my case, basic set-up is not bad and no major curves. Just slow and careful for someone not specifically in the network field. Beyond basic... I think will take a long time. Good little lab start.
And worth moving to a SG-5100 I think.

Closing this off - for some reason, rebooting the test device worked. (Basically I came back to test and it worked).

So I can only assume it was either intermittent, or maybe some issue with the DHCP client?

Hi Steve, I think we did recently update so that could definitely have been it. Thanks though for all your help!!

@philipputrus said in FTP server behind pfSense...:

The server use Active mode I checkd that by connecting to it from the CMD

For active mode you need to have the client FTP proxy installed and configured. It will not allow the server to open data channels without it.

Steve

No I haven't but I'm thinking of it as updating our infrastructure.

When you run tcpdump on the interface in pfSense you see eveything the driver is sending but that might not necessarily make it onto the wire.
By using a switch in between, mirroring the port and capturing on there you see what traffic is actually going back and forth.

Steve

Ah in Tautulli interface - thanks.. Yeah that does make it easy to find ;)

that scope would all be great if you made them vlans and actually isolated them.. But if they are all on the same L2 kind of just meaning less.. And means you have to for sure hand out reservations for every mac address.

You are only opening one port so you're exposing only the service listening on that port. The RasPi could have everything open but nothing is going to reach it except what you're forwarding.

Steve

I set on accept for Promiscuous mode, mac address changes and forget tramits on WAN vswitch,
Since my network goes Virtuel WAn switch-pfsense-virtuel LAN switch.
Also very important to note that is a reboot of whole esxi is necessary for it to acctually implement the changes made.

I didnt discover this at beginning.... so alot of my testing was flawed cause changed wasent acutally being made...

Thanks for all help.