@Enso_ I was talking about the firewall on the destination machine. To investigate the issue, sniff the traffic with packet capture on pfSense on the LAN interface and see if you get both, request and response packets.

@viragomann Here is the mikrotik config: [image: 1726580334812-2ca5f715-8cd8-400a-8c3e-c29d9f1f833d-image.png] [image: 1726580361664-a9ba1797-f786-47d3-bba6-639dffdbc4c8-image.png] [image: 1726580393098-586386f7-6801-4f64-a484-159b42b242c0-image.png] I am just not sure regarding the IP's

Hey, In here I've decribed my work on this topic :) https://forum.netgate.com/topic/189447/openvpn-ssl-tls-user-auth-over-ldap/3

@alanbaker Retaining the serial doesn't make sense here. But anyway, it would not have any affect to the clients. As well the private key is only used by the server for encryption and doesn't affect the clients. After reissuing ensure that the new certificate is assigned properly to the server.

@viragomann Thanks for the pointer. I've installed it now.

@jhg Is there in interface assigned to the concerned OpenVPN instance by any chance? If so you have to remove it before.

@viragomann Thanks. Changing the server settings to Decompress + Disable Compression does remove the compression mismatch messages. But my strange connectivity issue still persists even with this change, which tells me that the compression mismatch was probably a redherring to my connectivity/routing issue. Thanks for your help on the compression part!

Replying to my own topic - I've missed something like I've thought : I was re-using an old List of revoked certificates. IT appears that the CRL ( Certificate Revocation List ) has an expiry date. Which is in no way visible in the GUI to be honest. When I've created a new list and applied it to the VPN, everything works as expected. The thing is that this becomes clear only when you go to create another CRL, to be honest GPT4 Solved it for me. [image: 1726137708188-7e545c7e-0e44-40ee-af81-4ca4cf9d714a-image.png] Please close the topic.

Problem has been solved by using a secondary pfSense instance on a VPS, thanks

@Jung-Fernmelder said in How to distribute IPv6 adresses to OpenVPN clients with changing prefixes via SLAAC: How to add the network by name? As I said, this would have to go to someone who's more familiar with OpenVPN. However, the global address is only necessary if you are going through the VPN & pfSense to the Internet. If you're accessing only your local network ULA is fine. I wish ISPs wouldn't do things like this that break IPv6.

Did you manage to connect to Purepvn?

@DominikHoffmann From the documentation.... [image: 1725912010895-8043c07a-b660-4ac6-85d0-8a6e11dda674-image.png]

@viragomann wow it worked, thank you! I had these entries, but they contained old configs!

@PierreFrench Shared key is deprecated, as mentioned, and I didn't use it for years. So I don't know if and how client specific overrides and the client side LAN routing work with it. I think, it should if xou state the correct client name and the respective remote networks.

@johnpoz hi ! thanks ! it is due to bad gateaway config in my exi server (i set 2.100 instead of 2.1, i don't know why...) Thank a lot !

@AwesomeRob Thank you for that :) I just tested with pfSense+ 24.03 and it still uses 2.6.8_1 However if you then select the "development snapshot" branch under system update and ssh into pfSense and run pkg install openvpn then it does update to 2.6.11 Not the cleanest option, but is a way to get it upgraded. After doing that upgrade then can always change the system update back to stable. Not sure if this may complicate when pfsense 24.08 is released (roadmap goal is August 2024) - however this may be our best option for now. For anyone wondering, here is output from my pfsense+ 24.03 after manually doing above described steps (including changing system upgrade option back to stable version) and then running openvpn --version OpenVPN 2.6.11 amd64-portbld-freebsd15.0 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] [DCO] library versions: OpenSSL 3.0.13 24 Oct 2023, LZO 2.10 DCO version: FreeBSD 15.0-CURRENT #0 plus-RELENG_24_03-n256311-e71f834dd81: Fri Apr 19 00:28:14 UTC 2024 root@freebsd:/var/jenkins/workspace/pfSense-Plus-snapshots-24_03-main/obj/amd64/Y4MAEJ2R/var/jenkins/workspace/pfSense-Plus-snapshots-24_03-main/sources/FreeBS Originally developed by James Yonan Copyright (C) 2002-2024 OpenVPN Inc <sales@openvpn.net> Compile time defines: enable_async_push=yes enable_comp_stub=no enable_crypto_ofb_cfb=yes enable_dco=yes enable_dco_arg=yes enable_debug=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=needless enable_fragment=yes enable_iproute2=no enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_management=yes enable_pam_dlopen=no enable_pedantic=no enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_shared=yes enable_shared_with_static_runtimes=no enable_silent_rules=no enable_small=no enable_static=yes enable_strict=yes enable_strict_options=no enable_systemd=no enable_unit_tests=no enable_werror=no enable_win32_dll=yes enable_wolfssl_options_h=yes enable_x509_alt_username=yes with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_openssl_engine=auto with_sysroot=no

@viragomann Sorry there was some confusion on my end. The abbreviation CSO was not clear to me, but after some further searching it became clear and I added the route to the remote networks tab for the subnets on the client side. Thanks for your help, it works now!