Generally, we don't want appliances to be directly exposed to the internet for security reasons.  pfSense is great, but it's better to add another layer of protection in case there's some vulnerability discovered some day that lets hackers get into your exposed pfSense.  I do remote access all the time, but I use the built-in OpenVPN to connect to pfSense over the internet, then log into the pfSense web GUI through that.  Slightly more effort but much safer.

@mircolino: I have a pfSense 2.4.3 generation 1 Hyper-V VM running on Windows 2016. Wanted to try to migrate to generation 2 VM. What is the best way to do it? Hyper-V doesn't support USB memory sticks. So I tried copying /config/config.xml from the gen1 VM to a USB hard-drive and added that to the gen2 VM along with the installation DVD/ISO. The installation however fails to find the config.xml file and proceeds to ask me to reinitialize pfSense from scratch. Any other way I can do this? Not super familiar with freebsd. From the installation shell could I mount the HD and copy the config.xml somewhere where it would be found? I wanted to do the same thing, but eventually just went with stephenw10's solution.  During the installation, I just went with the default options.  As soon as I could log into the GUI, I went to Diagnostics > Backup & Restore, and uploaded the config file there.  I believe the end result is the same.

This file /var/log/dmesg.boot Or enter SSH : option 8, and type dmesg I hope you have the time to do so before it reboots.

stephenw10, Thank you very very much indeed. Your assistance solved my problem. Thank you so much.

Do you see anything logged in the OpenVPN log when clients try to connect? The 'TLS handshake timeout' just means that the server didn't respond at all so it either didn't receive the traffic from the client, refused the connection or tried to reply but couldn't. The logs should show which. Not receiving the traffic from the client because something in the route is blocking it would be my guess. Steve

Hi - it's a mystery why the box was offering to upgrade to 2.4.4 … Anyway, I found another post where the person had a very similar experience and followed the instructions here: https://forum.pfsense.org/index.php?topic=138921.0.  It took half a dozen reboots to get to the splash screen, by which time the last good configuration had been overwritten so I had to install the complete 2.4.3 and then restore from an old backup .xml that I had saved to disk. Thank you for all the replies

https://doc.pfsense.org/index.php/Boot_Troubleshooting

Thanks, I re setup everything and yes, I can get multiple DHCP now.

Hello Access the console and use option 11 and retry access in the GUI

As for my nightshift. I have talked with the support. There is no good way finding what happened at update. The suggestion was always have a serial console log running when you do the upgrade. Then you have a chance on catchen what was wrong. In my situation there where only haproxy and securitata installed. I ended up grabbing the last konfig (since I but carp in mainanance) from the old installation while booting from a usb stick with 2.4.3 on it. I then did a reinstall and restored the config. Everything is now working.

Now Google.com appears to be working.

You don't need to use DHCP. You can statically assign an IP to the pfSense WAN. It will meed to be an IP in whatever subnet is on the WAN side vswitch and have a gateway set to whatever device is the gateway for that subnet. Is the Ubuntu machine a client VM on the internal network? That should be receiving it's IP from pfSense via DHCP then by default. Otherwise everything on the internal subnet can be statically assigned also if needed. 255.255.255.0 is the subnet mask, the same as /24 or 10.0.10.xx for example. If the WAN adapter is NAT'd to the external subnet then it could be anything but it will be defined in the VM host setup somewhere. You provavly want to have that bridged to the external subnet instead to avoid (at least) to layers of NAT. Steve

@Gertjan: global search on the forum. If not, consider system broken, backup config and goto latest version, import config and done (5 minutes work ?). Thanks for the trigger 'global' - I didn't realise that my search wasn't checking the whole forum. Maybe that's why my results came up short. This post helped me fix the problem: https://forum.pfsense.org/index.php?topic=145605.0 Not sure which command it was, but things got progressively better until I could complete the update. If this hadn't worked, not so (5 minutes) trivial, as this is a remote (3000 miles) installation…

You don't mention anything about how you've set it up, but if it's virtualised and you haven't turned off hardware offload, then that's probably the problem.

U are not going to find any answers or assistance by posting such a generic open ended question. This is not much better than "it doesn't work."  Narrow down the problem.  Like looking in a library or Google, the more specific you are, the better, otherwise Google will return with unusable billions hits.

One of the fundamental considerations of a firewall is that there is an inside and outside[1], so regardless of what you name the outside interface, you still need it to face a different direction than the LAN interface.  I'd leave the name alone and just attach that interface to a VLAN named "simulated_WAN".  It will make it much easier to use the documentation and get forum advice if the interface name is still WAN. You may find it more useful to put the pfSense WAN interface on your existing LAN, and create a simulated_LAN subnet with a VM client for the pfSense LAN interface.  This way the pfSense WAN interface can reach the Internet, via your existing gateway, and you can test things like DNS caching, pfSense packages and pfSense updates. [1] To fend off the pendants (like me), there are also DMZ(s) and multiple WANs and LANs that complicate the concept.  … and bridging. ... and one-armed ... and the Spanish Inquisition!

Just happened today with my v2.1 firewall. The firewall would not route in this state. As I was under pressure from clients, I ended up disabling all IPV6 conectivity (Unchecking Allow IPV6) as a drastic solution. Seems to work fine now. I'll wait a bit before raising the table limit from 200k to 400k and re-enabling the IPV6. Accessing the firewall via SSH revealed /etc/bogonsv6 having 97k lines (entries). All other tables combined barely exceeds 5k entries.

Ok so what do you see on the packet captures from each interface? Do you see anything in the firewall logs? What firewall rules do you have in place? I suggest adding allow all rules on both interfaces until you get it working. Steve