my apologies.

The latency was due to a faulty internal connection on my side, which coincided to the exact minute of testing the vpn.

such is the life on IT

Cheers

<= bump =>

Hopefully it's something obvious.

My second attempt was with pfSense 2.3.2 (2 Nics, 1 assigned WAN, 1 assigned 'LAN')

I have openvpn listening on the LAN adapter.  I have created a nat rule to allow vpn connections to the lan (WAN,UDP,,,WAN ADDRESS,1194,lan adapter ip, 1194)… however who shows wan adapater.

I have setup other servers running OpenVPN (off an Ubuntu box) and the server logs are as I would expect (client IP shows).

====================================================================================================

Well if anyone stumbles upon this, here is what I did to fix this:

*Automatic nat to manual nat
*Removed WAN nat entries for my tunnel network (left lan... still need to validate traffic is going through my lan interface)
*On Azure, create an inbound rule on NSG allowing my tunnel
*On Azure, create a route table, tunnel next hop = pfsense (associate to the subnet)

There is no save default button at the bottom.  Thanks though.

No you can use the same certs if you want..

up

OK, so with all my remote lans being on different subnets can I run a single server and a client at each end?

The block access to the lan from the remote using rules.

Would that work?

You're looking for a VPN-bridge:
http://sclabs.blogspot.co.at/2012/05/openvpn-bridge-with-pfsense-201.html

That's not well supported and it's not recommended:
https://doc.pfsense.org/index.php/OpenVPN_Remote_Access_Server#OpenVPN_Client_Bridging

Some guys here who tried that got no luck with it. It's better to do routing with a different tunnel subnet.

Thank you, problem solved  :)

As long as each client has a different certificate it looks like that should work.

If you gave the same certificate to everyone then it would only work for one at at time.

Would have to be a false positive. It is a self-extracting executable that isn't signed, which some paranoid systems may flag.

I doubt it's that sophisticated, but it could also be flagging the out-of-date OpenSSL in the out-of-date OpenVPN binary you'd have there. The export package for 2.2.x is not being maintained, use pfSense 2.3.x.

For anyone wondering what to copy-paste into this field, its the key mentioned in this section of the pfbook

Click Save.
Click pencil to edit the new server instance
Find the TLS Authentication box
Select all of the text inside
Copy the text to the clipboard
Save this to a file or paste it into a text editor such as Notepad temporarily

The book never mentions when to use this key, but this is the one to put on the client TLS Authentication and not those that we exported from the certificates management.

cheers

The AES-NI checkbox in the GUI enables AES-NI for AES 128/192/256 CBC via cryptodev. That means that for each block of data to encrypt, the openssl library will issue an ioctl to send that block to the kernel, suffering a context switch penalty. Since the computation being performed is exactly the same as what openssl would do without cryptodev (and in that case, without the context switch) it is necessarily slower; there is no advantage at all in enabling AES-NI via cryptodev. You do not see a penalty for GCM modes because those are not implemented in cryptodev and so openssl continues to use its internal routines.

So why does the AES-NI kernel module exist at all? If you are using ipsec, which does all of its encryption in the kernel, then you need the AES-NI kernel module to let the ipsec module to use AES-NI–and in that case it's a performance gain because everything is happening in-kernel. Ideally, pfsense would enable a configuration in which you can load aesni.ko for ipsec without loading cryptodev, so you can get the benefits without the drawbacks.

So when would you ever want cryptodev? The /dev/crypto interface is only worth using with external crypto processors, like the old via padlock or the hifn cards (though you're generally much better off just throwing out such hardware and buying something new if you care at all about crypto performance; the crypto accelerator on the old alix boards, for example, was about as fast as a new raspberry pi or an APU1 without hardware crypto, and an order of magnitude slower than an APU2). In theory it might also have a benefit for quick assist, but I think that's implemented in openssl in a way that avoids using /dev/crypto. There's been speculation over the years that cryptodev might help improve cpu utilization, but I haven't seen results on modern hardware where any speculative gain outweighs the performance penalty of the context switching overhead.

Partial work around or fix depend on your use case:

If you have another physical NIC, assign it as an interface and make it active then bridge this new interface to your OpenVPN interface, then physically connect it to a switch port in your network that has been correctly set with with the PVID of the VLAN your trying to connect to.

Remembering to add a FW rule for this interface to allow traffic.

You can test correct set-up by temporary setting your new interface to DHCP (it should be assigned an IP from your range in your VLAN)

Now when using  your OpenVPN client you are bridged in and can access the subnet and GW, and in our case upstream IPSEC connections.

Where it falls short is the new interface is treated as a WAN, when enabling "Redirect Gateway" packet exiting are not being NAT'ed when they exit the GW I looked at outbound NAT but it appears to be not affecting it.