@brianjmc1 Tried the forum search? There are several threads regarding this topic. In the OpenVPN access server settings you have to add 192.168.200.0/24 to the "local networks" to push the route to the clients. And in IPSec you have to add a phase 2 for the OpenVPN tunnel pool and the branch LAN. So in the main office: local network: OpenVPN tunnel network remote: 192.168.200.0/24 And in the branch: local network: 192.168.200.0/24 remote: OpenVPN tunnel network Ensure that the access is allowed on all incoming interfaces.

Guys! I'm seeking you help please

@viragomann appreciate you helping me to troubleshoot anyways!

@rjabellax5 Basically your settings should also work well with pfSense 2.7.2. However, shared key mode will be removed from future OpenVPN versions. So you should consider to move over to SSL/TLS peer-to-peer connections. At this occasion you may also want to update the ciphers to GCM or CHACHA20-POLY1305, depending on your hardware.

@bamypamy said in 2fa with ldap - Active Directory - Freeradius: https://forum.netgate.com/topic/180533/openvpn-freeradius-and-ldap/7 Responder Cotización Yes I saw it, but I also have more than 10 users. It's a shame not to be able to implement this 2FA

@michmoor I checked this option but I also have the problem that it is more than 10 Users. I guess I need to ask for some money. ;-) Thanks for replying.

@jimp Indeed that is a great resource to use for troubleshooting, thanks for sharing it!

@lifeboy Glad you're working now. What I learned on my journey to solve this problem is that there are many different causes that manifest in the same failure signature. The story of my (professional career) life. We were always the lightning rod.

@Rico said in Multiple logins with same user account, concurent connections disabled: You need to check Enforce match (Strict User-CN Matching) in your OpenVPN server settings. -Rico Seems to work, thanks a lot!

@hrx The problem was solvable after quite a bit of research and testing. Most things stemmed from either the older versions of DCO in previous pfSense Plus version, but a few remained and were able to be debugged to being a problem in the implementation of OpenVPN, DCO and pf in FreeBSD itself. The quintessence is that OpenVPN multihome CAN'T work properly with DCO and PF in FreeBSD right now. Switching that to UDP on localhost and working with inbound redirection rules made it work in no time. It's not as elegant as we need to redirect v6 traffic, too , it's resulting in 2 OpenVPN servers instead of just 1 for my case, but at least it's working that way and doesn't have a problem. Cheers

@viragomann Thanks, the problem was the OpenVPN cert had expired, but I could not get to the box to connect. We have a few different firewalls that are supposed to have a tunnel between each of them, but none of them were working. Even had someone onsite at the physical location of the Firewall connect to the Firewall directly via Ethernet and they couldn't connect. Tried to use the Console connection, but couldn't see what port in the Device Manager, tried guessing a few but was still not able to connect via PuTTY. Fortunately today at a different site the tunnel there was working and I was able to connect and refresh the certificate.

@viragomann Disregard -- I was using the wrong option. Enabling the "Use only for resources on this connection" checkbox corrected the behavior. Thanks!

@soul222 try using their wireguard method. it is a lot easier to setup and faster from my own experience.

@bigbmn unfortunately I found this one. There was a bug in the code where it incorrectly defaulted to removing the settings unless the page had specifically been saved. https://forum.netgate.com/topic/181594/restore-missing-freeradius-config/