Hello?  Anyone home? Here's some screen shots: [image: 2016-09-09_9-20-22.jpg] [image: 2016-09-09_9-20-22.jpg_thumb] [image: 2016-09-09_9-21-05.jpg] [image: 2016-09-09_9-21-05.jpg_thumb]

When you are making your configuration changes on the router\gateway, are you connecting your computer directly to the router\gateway to make those changes?

Should this be posted in a different spot given the lack of even a 'your nuts'  (kidding of course).

@jimp: The Chrome regex parser has a bug in that it does not allow escaped characters inside a list, even though it is a valid – but not required -- regex expression. Not required unless a character class includes a character that needs to be escaped that is.  Such as, oh say a backslash.

@vamdolly: Hi witch cpu would be right for the job a duo core or quad core for pfsense using vpn, snort and antivirus if im not mistaken vpn is better with more but im not to sure. You're right, OpenVPN it's not scalable so is better to have a multi-core CPU.

They generally perform worse for two reasons, they offload all of the work to the CPU, and they have crap driver support. No matter how good your hardware is, no driver support will kill it. And depending on several thing, 2ms is really really bad. I get a 0.2ms ping average, and a min ping of 0.008ms. Even my 8 year old Dells with an Integrated Intel NIC that Intel claims costs about $0.01 to add to the chipset, averaged about 0.3ms. But lets not get sidetracked with hardware knocking before the issue gets narrowed down a bit. One thing you may want to do while trying to make the firewall shuffle packets around is to look at the System Activity and see if CPU usage is abnormally high an what is using it. When doing this kind of test, best to do a load test through the firewall and not to it, it makes a difference since firewall stuff is done in the kernel while iperf is done in userland.

Okay, so the random shutdowns were not because of… 0x0ahd1: Address or Write Phase Parity Error Detected in TARG. Yesterday in the evening we had a power supply failure. We replaced the power supply and the system has yet to go down since. However we still get the "0x0ahd1: Address or Write Phase Parity Error Detected in TARG." errors in the logs. Are we looking at a HDD failure in the works?

@jimp: To make it stay across upgrades, use a <menu>tag inside the packages section of your config.xml. Install a package and then look at its <menu>tag and follow the same general syntax. </menu> </menu> agreed! This is the best way to add a menu link that stays across upgrades and updates!

Hi, Thanks, I changed the hosts files to point locally to our proxy server (e.g. wiki.domain.com points to the local ip of the proxy) and this is working great now, the COMODO certificates are returned and the application works. Thanks for the help. Kind Regards, Gary

Install the sudo package and use it. Then you can grant access to users or groups from the GUI.

Do not use an obsolete 2.0.x version, use a current version (2.3.2). The patch is no longer necessary and packages for 2.0.x have been removed, which is why you can't find it. If you post on the OpenVPN board here asking for help with what you're trying to accomplish using 2.3.2, you're more likely to get accurate and relevant help.

thanks I'm an idiot for not looking there first…

@jimp: Difficult to say without more detail, but on smaller hardware, just watching the dashboard on its own will cause a spike in CPU usage because it takes a fair amount of CPU time to process all of the data required to draw the dashboard. In other words, the act of measuring can change the results. Even on my i5 quad-core, viewing the web front-end bumps the CPU from 300mhz to 800mhz-1600mhz due to increased CPU load.

I wonder if a nic can manage certain amount of users because I have about 50-60 users on my network.

Noted I can't seem to understand clearly what your saying in the second sentence of your paragraph though. Can you put it in more of a layman's term.

I can't find the checkbox you mention, but I don't think that is the issue. Very, very little of our traffic goes down the tunnel (tunnel A), plus I'm seeing the following: Tunnel A - terminates on the pfSense box. External IP is on WAN1. Tunnel B - terminates on a device on the LAN. External IP is on WAN2. This is the one we're having trouble with. Both Tunnel A and B terminate their other end on the same remote device. The setup traffic for tunnel B isn't being routed down tunnel A. Instead, it seems to be using the routing table for the tunnel A setup packets (IKE/ISAKMP - port 500) to route the setup packets for tunnel B (they should go down a different interface). I'm actually seeing packets with WAN2's address being sent out on WAN1.