Hi, No need to go to http//whatever.on.the.internet.tld Like Mercedes knows all about Mercedes cars, Netgate/pfSense knows all about pfSense : https://docs.netgate.com/pfsense/en/latest/nat/port-forward-troubleshooting.html I would open my tool box, that is : clicking on " Diagnostics > Packet Capture" and set up for a capture on port 1194 and UDP (?) and start it. Then, try to connect using your remote App. Stop the capture. Look at the result : something came actually into on your WAN (?) NIC on this 1194 port ? If not : the problem is up stream : traffic didn't make it to pfSense. Read the entire check list on the trouble shooting page : execute every step, and if you do not understand : ask. "before using Pfsense I open NAT-DMZ on the router from WAN to local IP. " pfSEnse is not any different from any other router on planet Earth. You have to create a NAT rule, using incoming port, outgoing (destination) port, a 'LAN' (DMZ) IP address and that's it. But if 1) applies, and nothing comes in ... well yeah .... 1 explains 2. "I have a program that does not work in the domain environmen" : I don't understand. That's a typical user that describes an error. Your are the network admin ? Start detailing what actually happens. We, from here, know nothing about your network / needs / setup. Give details and we figure it out.

Hmm, well I imagine it's possible but I'd have to be a lot more familiar with that modem/router. Certainly pfSense has no problem doing that. Steve

What are you trying to authenticate against it exactly? Users logging into pfSense? VPN usesrs? I'm unfamiliar with RCDevs WebADM but after quickly searching I can't see anything Radius related only LDAP. You have a link to any documentation? EDIT: This? https://www.rcdevs.com/docs/howtos/pfsense/pfsense/ Steve

Well I guess if you're testing that others don't have to.

The more recent replies on there seem relevant still. I would probably use a shellcmd to start smartd. That way it is included in the config. Steve

@rottonpeech And the wan rule there in your picture, I don't think it is needed, although I am not sure. Once your vpn client is working, it is easy like described in my first post.

Sorry, can't check anything regarding that any more. Company went bankrupt and was bought by another one. Moved over to their building.

@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