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

The most common way people add a LAN gateway by mistake is if they add a new internal interface in the webgui or they set a new IP address on the existing LAN from the console menu. In both those situations you are presented with an option to add a gateway. There is text guidance explaining that only 'WAN' type interfaces should have a gateway but it's easy to think you are entering the gateway clients should use and add the LAN IP as a gateway. That's incorrect but we see a lot of people do that. Only WAN interfaces should have a gateway defined on them directly. That is adding a gateway for the firewall itself not a gateway for clients to use. pfSense uses the presence of a gateway on an interface to identify it as a WAN and will add automatic outbound NAT rules to it. Steve

I've managed to get the OpenVPN connected now. It appears the issue was at the OpenWRT/OpenVPN end (due to my inexperience with it). I didn't use the bare config file but rather the "wizard" (if you can call it that, its more of a text entry box). This is the correct config needed on the OpenVPN end: option dev 'tun' option keepalive '10 60' option verb '3' option persist_tun '0' option persist_key '0' option port '1194' option auth 'SHA256' option cipher 'AES-128-CBC' option enabled '1' option secret '/etc/openvpn/dcvpn.key' list route '10.94.43.0 255.255.255.0' option ncp_disable '1' list remote '12.64.66.45' option comp_lzo 'yes' option ping_timer_rem '1' option proto 'udp' option ifconfig '10.94.32.2 10.94.32.1' And pfSense: verb 1 dev-type tun dev-node /dev/tun2 writepid /var/run/openvpn_server2.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp4 cipher AES-128-CBC auth SHA256 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 12.64.66.45 ifconfig 10.94.32.1 10.94.32.2 lport 1194 management /var/etc/openvpn/server2.sock unix route 10.94.48.0 255.255.255.0 secret /var/etc/openvpn/server2.secret compress lzo

How do you have pfSense configured here? Is it just routing between those subnets? Is there any NAT happening? What is the default gateway clients in the 192.168.1.X subnet? 192.168.1.1? Does that have a static route to 10.10.1.X via the pfSense WAN IP? It sounds like you have some asymmetric routing happening. You may see blocked traffic in the pfSense firewall log if so. Steve