Good to note for future reference about UDP. In either case, I ended up updating pFsense to latest build and OpenVPN started to connect as normal. I guess I have seen odder things after a move…

That worked perfectly.  Thanks so much!

Although not using pfSense for this test but I can confirm that a second client coming from same public IP is unable to connect. On client side the log shows: Tue Dec 20 17:20:27 2016 MANAGEMENT: >STATE:1482250827,WAIT,,,,,, Tue Dec 20 17:22:32 2016 Restart pause, 5 second(s) On server side no connection attempts show up in log. Clients have their own ceritificates/commonname, no duplicate-cn.

Are you on a current snapshot? There was a bug fixed several days ago that was preventing a CA from being imported without a key. It's fixed now, but you have to update to get the fix.

thanks for this. it looked like it was all working - but, when disabled the VPN, it also took down my normal lan, not just the host i want to stop being able to access the net if the vpn is down. it's like it was marking all packets but it was only set for the one rule (the top one in the first post - below the default). I also tried the alternative method at the bottom and added back the block rule.. any ideas?

The server can't tell that. It's up to the client. And if you need to see that on the client, there isn't a way to query it. You'll have to increase its log verboseness level so it logs the options it uses.

The status, as shown, is the status output directly given from OpenVPN. We do not correlate that with internal info in any way. We could try, but it wouldn't necessarily be a proper match. It's safer to just show what OpenVPN gives in these cases.

The config is correct. I noticed that other logs are not writed since some days ago. For example work: General Firewall IPSec Not work: Gateways DNS Resolver Open VPN NTP

Hi altiris, I had the same problem. The key-direction 1 in the .ovpn file should be before the <tls-auth>section and not after. I think it is a bug in the auto-generated file. key-direction 1 <tls-auth># 2048 bit OpenVPN static key –---BEGIN OpenVPN Static key V1----- ...</tls-auth></tls-auth>

I have tried aes128 and was pushing 70 mbit at max. That's more than half my speed. Pity! Thanks for your help though.

If your goal is to have the traffic from your home go to your VPS then out to the internet, then yes you have it backwards.

That is a use case for policy routing. See the many, many threads about only sending traffic from certain hosts to, for instance, PIA. You will just need to alter the rules to match certain destinations instead.

Never mind… sorted it now, changed the Gateway on the LAN interface to that of the Watchguard. Tested to make sure that clients on the SBS2011 network couldn't use the pfSense as a gateway to circumnavigate the Watchguard - it still picks up their originating IP and asks for authentication.

It works! Thanks guys :D I needed to NAT the VPN which seems obvious now. I did NAT before, but I probably had some other setting set wrong at that time.

Thank you very much…it worked