@stephenw10 @JKnott Ok, so its still going down. These lines in the log look like the start of the problem: 192.168.1.1 3/22/2020 19:21 local7 err dhcpd icmp_echorequest 192.168.1.218: Host is down 192.168.1.1 3/22/2020 19:21 local7 debug dhcpd reuse_lease: lease age 346 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.1.204 full log here: https://pastebin.com/zs2JhtCS

So only the mobile clients are failing? Do they connect direct or over VPN? How do they fail? No connections at all? Nothing logged at either end? Steve

Those pkgs are still there, even the 32bit versions. You should still be able to reach 2.3.5p2 from earlier versions. https://files00.netgate.com/pfSense_v2_3_5_amd64-core/All/ You should absolutely upgrade to 2.4.X though. 2.3.X is obsolete. Steve

Hmm, not seeing any easy details to compare there. The 825747 though is very common, I wouldn't expect to see any issues with. I would try swapping them to see if it changes anything. Steve

@stephenw10 said in Help setting up Pfsense in Virtual Box, I am getting no internet connection to my internal network.: @NollipfSense This is a common misunderstanding. The block private networks rule only prevents incoming connections to the WAN. You may well want it unchecked in this situation to access the webgui from the WAN side but it will not prevent access to the internet from LAN. Steve Ah, cool...I was trying to remember how I had it two years ago when I first used pfSense and VirtualBox.

No significant difference really. There are some things that are still single threaded, like PPPoE. So fewer but faster cores can be help in some configurations. Steve

For anyone reading can you confirm the fix? It looks almost certainly like it was because you didn't have the gateway on the WAN itself and therefore would have no outbound NAT. Switching to DHCP would also have added that gateway correctly. Steve

If in your trace you had bounced around to other networks - then that would be a concern... But you look to just stay in the Turk Telekom network...

@stephenw10 alright. I did switch the monitoring and monitoring actions(that was empty, but I'm not taking any chances) let's see if that will help. Thanks Steve! I really appriciate your time and effort!

Or NET-SNMP with an external script which returns the gateway status. Or a similar agent like Zabbix or NRPE which could be scripted in similar ways.

Theoretically you should be able to import a config from any previous pfSense version. The upgrade scripts are cumulative so it should be updated to a current version complete with all the required chnages when you do. It's a relatively easy test. You can roll back to your current config from the console if it fails for some reason. If it fails yo boot to the console re-installing entirely is quite fast if you have the install media to hand. Particularly if you put the current config onto it so it boots up ready to go first time: https://docs.netgate.com/pfsense/en/latest/backup/automatically-restore-during-install.html If you WAN is wireless you should make sure you have tuned the monitoring to match that. It will almost certainly have higher layency and packet loss rates than other WAN types. You might just disable the WAN monitoring action for that gateway to be sure it's not triggering unnecessarily. Steve

Thank you! Solved it by enabling NAT reflection on the port forward rule. /Tomas

Yes, using shellcmd is easiest here and it then stores the command in the config file. However to run at rc.d script use /usr/local/etc/rc.d/. https://docs.netgate.com/pfsense/en/latest/development/executing-commands-at-boot-time.html Steve

Use faster hardware? Try blocking using DNS via pfBlocker-NG instead maybe: https://docs.netgate.com/pfsense/en/latest/packages/pfblocker.html Steve

Yup split DNS is a better solution here. https://docs.netgate.com/pfsense/en/latest/nat/accessing-port-forwards-from-local-networks.html Steve

Big fan of WinSCP here, for file moving and editing from a client. Just enable SSH on FW.

Nice, good catch!

Ran some tests on this a few different ways this morning. It appears to work fine when pfSense is set to use PAP or MD5-CHAP to the server, but fails when using MSCHAPv1 or MSCHAPv2. I've tried a few different ways to encode the values (UTF-8, UTF-16) and in varying places around the auth request but no luck so far. It works using any method I've tried with radtest at the CLI, so it appears to be an issue either in the PHP RADIUS code (PEAR modules for Auth_RADIUS or the CHAP specific module(s)) or how it's called when pfSense forms auth requests with these types of passwords. I created https://redmine.pfsense.org/issues/10352 to track it down eventually but at least at the moment I'm not seeing anything that looks like it would be a quick fix.