@stephenw10: Ah, I missed you Doktor. Forum wasn't the same without you.  ;D Ditto, ol' Doktornotor cracks me up.  ;D

@cmb: @bradenmcg: I would love to see something analogous to Cisco's "VTI" and Juniper's "ST" interfaces for VPN; most major firewall vendors have something similar to this, even "weird" stuff like Palo Alto support this (and PA doesn't do IPsec+GRE so I have no other way to replicate it against pfSense). I would like to see that. It'd require a good deal of work, as there are missing pieces in underlying bits. Not on the near future road map at least. That's what I've been reading, apparently neither BSD or Linux have the correct tunnel interface existing on the OS, making this more complicated.  That said, Ubiquiti has VTI in their gear, so it can't be too bad to do… I believe they are some form of *nix underneath, wonder if the source for this is open? I may have to grab an EdgeRouter and stick it behind my pfSense box just for VPN purposes.  (I'm not likely to ever ditch pfSense at the edge, unless someone else starts supporting UPnP/NAT-PMP, since I have game systems.)

What type of hardware is this? If you're more comfortable communicating in French (I see your IP is in France at least, making assumption from there), you might try the French board. https://forum.pfsense.org/index.php?board=7.0

I got some Trim help here if you decide to do a fresh install: https://forum.pfsense.org/index.php?topic=66622.0

Hello, It looks like the suggested fix by cmb works.  ;) Thanks again. Best regards, Ivo

Yes,  pfSense-2.2-RELEASE-4g-i386-nanobsd .img and 2.1.5-RELEASE-pfSense-4g-i386-nanobsd.img

Thanks for making squidguard-squid3-1.4_7-amd64.pbi available, with sum  ;) Just upgraded pfSense again, after some testing everything seems to work as planned. Thanks, qinohe

@WONDER: After one or hours automatically service started. Probably freshman first run…

+1 for this

Same here on a Alix2d13 afer update to 2.2 Also VDSL with VLAN 7 Disable IPSEC stops the crashes. Any new information here?

I didn't understand this magic. If I add 192.168.2.1 as VIP and delete the same VIP then I can ping my pfsense IP 192.168.1.11 from VLAN 2 i.e 192.168.2.x same way for all VLANs. But if I restart pfsense it is not pinging, again I have to add VIP and delete the same VIP. Any idea?

Check out the bug report in https://redmine.pfsense.org/issues/3669 Note that there are 2 parts to the restarting fix: First part relates to IPv4 script /etc/rc.newwanip - this fix is rolled into 2.1.4 and later. Second part relates to IPv6 script /etc/rc.newwanipv6 - appears to be awaiting review (despite ticket being marked Resolved). Also impacts 2.2 release In the meantime it is easy to manually apply the fix and stop the restarts.

https://doc.pfsense.org/index.php/Dig_command_on_pfSense_2.2_and_later has existed for a while, just sayin'. :-)

Wow, bad cable or bad adapter? Were you using 115,200bps for both? Good catch I would have rules that out.  ;) Odd that 2.2RC worked and 2.2-rel didn't.  :-\ Steve

When you reinstalled from scratch did it work? Yes worked for me on 32-bit architecture. I have backup not the latest one but at least several months old make my life easier. Still looking for SquidGuard & HAVP package to work! I hope that you will get the solution soon. Good luck

One thread is enough. See https://forum.pfsense.org/index.php?topic=87728.0 (The "Intel Atom" is absolutely useless info when debugging undetected NICs.)

Hey thanks for all the help. The client has decided to ship us the firewall/vpn appliance that will be used in the production environment. So we will be halting work on this VM solution until it becomes necessary again. I'm pretty sure your suggestion to set up another vm in the cluster to manage it would work but I might still be stuck with the same problem of not being able to navigate out of my cluster. I also think it would be helpful for me to work with a standard windows server or ubuntu distro to troubleshoot my vm networking issues. Once I fix that I bet I could troubleshoot the PF Sense thing better. anyways, thanks for the help. IF I come back to this and find a solution, I'll post it here. Cheers!

There have been problems that somehow the PID file for an OpenVPN instance can get updated with a new PID but the new process dies because the old process is still there, or some similar timing interaction. In that case the dashboard code is trying to query the OpenVPN status of a PID that does not exist - so it shows down. But actually the OpenVPN instance is happily running with some other PID and users are happy. As you report, if you kill all the processes then start them 1-by-1 it all goes green. That is because the PIDs in the PID files now match the PIDs of the running processes. Actually you will probably find that from a user point of view all OpenVPN instances were working fine. If someone can pin down the sequence of events that causes this, then it can be fixed some day :)