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

@stephenw10: If all three were getting IPs, gateways, subnets etc from the same DHCP server then they should have at least had the same settings. If the dd-wrt device was still in router mode with NAT all three clients would appear identically to pfSense. There's no way it could distinguish them and block only one. It looks like whatever was blocking that was in the dd-wrt device or in the client itself. It would be better to setup the dd-wrt router as an access point only. It may have a mode for that where the the WAN port is added to the LAN as a bridge. If not just disable DHCP and connect the link to pfSense to one of the LAN/switch ports. https://doc.pfsense.org/index.php/Use_an_existing_wireless_router_with_pfSense Steve That did it! Silly me, I had the cable plugged in the "internet" port on the router. When I switched it, dd-wrt automatically let pf take over dhcp, so now everything works. If only I could find out why I cannot install 3.4 now.  :o

@shoggy: I was able to resolve this by recreating the firewall rule to pass traffic for the openvpn, beats me why it didnt work before. When you use the OPENVPN Wizard, it ends up setting an automatically generated  firewall rule on your WAN interface that lets VPN traffic in. See image. It's a simple rule that lets UDP (I choosed UDP) traffic in on port 1194 (because that's my VPN port) on my WAN. @shoggy: I am not able to connect to the VPN and traffic flows both ways. I appreciate the effort Gertjan You said it was resolved. You are not able to connect, … and traffic flows both ways, which means you are connected. I don't understand. edit : what are your firewall rules on the Firewall => Rules => OpenVPN tab ? edit again : I 'checked' https://www.sparklabs.com/support/kb/article/setting-up-an-openvpn-server-with-pfsense-and-viscosity/ It will work, but why including "8.8.8.8" as a DNS still puzzles me. You saw this part : 19. Now accept the default firewall rules by checking both the Firewall Rule and OpenVPN rule boxes and clicking Next. These rules will allow your client to connect to the OpenVPN server and allow VPN traffic between the client and server. and Firewall Firewall settings are generated automatically by the wizard. However, depending on your firewall setup and version, you may have to check the setting the wizard has created. First, navigate to Firewall -> Rules and select WAN. You should see a firewall rule permitting IPv4 traffic incoming through the WAN via the OpenVPN port. This will allow clients to connect to the VPN via the external WAN interface. If you are having issues routing traffic through the VPN, navigate to Firewall -> Nat, select Outbound and ensure the Mode is set to "Automatic outbound NAT rule generation. (IPsec passthrough included)". [image: openvpndefault.PNG] [image: openvpndefault.PNG_thumb]

What does the browser says when it doesn't work?  Amazingly return/un-returned message has meaning… SITE UNREACHABLE = routing issue/missing gateway. SITE NOT FOUND = no DNS resolution. SITS FOR A WHILE BEFORE RETURNING ERROR = TTL timeout, packet dropped by somebody in transit. Sometimes congestion. Odd.

Hi thanks, was not the problem. I had added the openvpn using the wizard and the bugged rule made it so all traffic was going to the pfsense ip. Still need to do the openvpn but that's for an other question :)

Hmm, never tried it but I'm wondering of one of the usb device quirks could work directly here. https://www.freebsd.org/cgi/man.cgi?query=usb_quirk&sektion=4&n=1 It looks like you're using the standard Huawei mode switch message currently so one of those might. If that does work you can just add it in loader.conf.local. Steve