@mmarco If you set up a site2site OpenVPN select "peer to peer" server mode and use a /30 tunnel subnet. So there is no need for a CSO.

I changed the option "Certificate Depth" from "One (Client+Server)" to "Do not check" and now I do not experience the issue anymore. My question stays the same though: Why is this happening on the SG-2100 and not on a virtual pfSense?

@issuehaver Thanks for the feedback. Glad that you get it working at last.

@apara From the url above , it seems that your vendor needs to sign with SHA instead of MD5 Getting new updated certificates would be the correct solution. But with some vendors ... "Good luck w that" /Bingo

Can anyone offer any help debugging this please - I am not making any progress.

@viragomann @viragomann Thank you so much for your reply. I have managed to do some magic by following this forum discussion: www.truenas.com/community/threads/truenas-12-openvpn-service-testing.85461/page-2

@hardikpfsense said in pfsense openvpn tunnelling issue: Now from documentation we read that to do what we want to do we tried to set IPV4 to : 192.168.1.0/24 and foced Redirect IPv4 Gateway using checkbox in tunnel settings. Where did you read this? It is sufficient to add the subnets where your internal services resides to the "Local networks" in the OpenVPN server settings. "Redirect gateway" forces the whole clients upstream traffic over the VPN. Is that what you really wan? Can the clients access your services with that option?

@viragomann said in OpenVPN client computer names: So you will have to request the responsible admin to do this. Can't think of any you can do on the OpenVPN server, since the clients use equal user accounts on the terminal server. Maybe you got me wrong. Both our employees and subcontractors have their own individual OpenVPN accounts. However, they have one user account for the customer's system (another company). We connect to this client's network (another company) through the IPsec tunnel. When our employee tries to log into this system and the subcontractor is already logged in, a message appears that this user is already logged in to the computer (and the computer name appears here). If I could link an OpenVPN account with an unknown computer name of the subcontractor, I would know who to turn to, e.g. to log out. Currently, subcontractors get static IP addresses from OpenVPN. So I am able to bind the user - ip account, but I am not able to bind the ip address - computer name.

@viragomann Makes sense - I put that into the Local Networks box and now it's all set. I kept the CSO setup because it makes for easier export of the installers or config files with the certificates embedded for the specific 'user' or cert - but since this was my use case - it's working perfectly now. Thank you for all your help today - I learned a lot.

@viragomann Thanks this was very helpful. I looked again at the certs and found that the Peer Certificate Authority for the one in Question was actually a server cert instead. Changed it back to the Intermediate CA it should have been and the list is populating.

That is more of a question for OpenVPN than pfSense. If OpenVPN supported it, pfSense could use it. IIRC it had something to do with the HMAC being a part of the shared key in that mode, and AEAD ciphers like AES-GCM and CHACHA20-POLY1305 want to do hashing themselves. I could be misremembering that, though. I'm not sure what will change here but something is going to have to change in OpenVPN since 3.0 hardcodes the ciphers and only uses AES-GCM and CHACHA20-POLY1305. Maybe they find a way to make it work, or maybe they drop shared key mode.

Update : Look like it's the latency which impact the TCP VPN. Wel, I cannot do to much things about it, so I will keep 2 VPN and when UDP is blocked, I will use the TCP.

@bob-dig Thank for your reply. Currently my OpenVPN settings is here [image: 1626603245006-45e6a85a-52bd-4dd6-a4f1-bd1e35d3a009-image.png] In the above photo, 192.168.160.0/24 IPv4 Local network which OpenVPN Client can access. With this setting, I can connect to Nextcloud using nextcloud.mydomain now

@jimp I spent about 5 hours today trying to figure this one out. It's a shame the default setting is incorrect - no tutorial has mentioned this. Thanks.

I've set : [image: 1626346094888-1b1768a4-d299-443e-9504-4bca4411a3ad-image.png] So, no surprise, I see in the logs the same thing : 2021-07-15 12:44:55.799700+02:00 openvpn 48505 GertjanHome/92.184.123.121:55566 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key I also saw the same thing on the client side - in the logs of my Phone..

Found. There was old certificates generated using easy-rsa before pfsense installation. And it was added to crl. New certificate was created with same serial and became revoked. I created new one and all works. There is a bug in pfsense - it should check crl and show "revoked" for certs with revoked serial.