@aminbaik said in pfsense openvpn client port forwarding](/post/1040351): its my i resolved it by add the server subnet to tunnel address.

@aikikun My guess is that you might have installed OpenVPN as "user" , it seems that it needs to be installed with local admin privilleges. See below: https://github.com/OpenVPN/openvpn-gui/issues/281 As Local-Admin, uninstall openvpn. Login as your user and re-install openvpn. At the UAC enter the Local-Admin password. This should create the group and add your user to it. It does not point to pfSense , as being the source of the error. /Bingo

UPDATE: IT WORKS! I did a clean install of v2.6 and selectively imported sections from the prior config.; specifically the OpenVPN, System, FW aliases (NOT rules), DHCP and DNS forwarder services. I did add an 'allow any-any' rule to the OpenVPN interface, but the WAN and LAN interfaces were left at default (basically empty). I did add DHCP options 066 and 160 to specify a provisioning server rather than manually entering it on the phone. A factory reset of the phone did the expected; downloaded a config. and registered with the PBX at the remote site. It can make and receive calls normally. I can't honestly say what the root cause was so it will just have to remain a mystery.

@johnsheridan Thanks for the info and testing. That makes sense. I’ll have a look at those files and patch. This will be probably fixed in one of the next releases then.

@viragomann Thank you very much for your suggestions. I prefer to use the proposed structure as I do not have many users, low amounts of traffic and I do not need to administrate multiple pfSense servers. Regarding the CA, I use self-signed certificates. The routing issue with overlapping local subnets is something I am now aware of. I will 10.x.x.x networks for the LANs of the routers. In this case, it is unlikely that a connecting user is in an identical subnet. I found this explanation regarding OpenVPN routing: https://community.openvpn.net/openvpn/wiki/RoutedLans This seems to be exactly what I would like to do. I will try it tomorrow. Thanks!

@viragomann Thanks a lot! For the IPSec tunnel i configured the opvenvpn tunnel network address and not the local network of the site (192.168.44.1). Thanks a lot!

@viragomann Thank you! I kept searching for the setting to keep dead routes up. I had no idea it was in the miscellaneous settings area. With that change, I am having all traffic route properly only on the VPN interface now. When the VPN link goes down, internet stops as desired for clients connected to this pfsense gateway. I did have to tweak DNS Resolver settings for Outgoing Network Interfaces to only use the VPN interface for DNS queries. By default external DNS lookups were going through the WAN port even though there were no traffic rules set for the LAN to WAN. With your hints I am up and finally running this VM on a newer version of pfSense. Thank you again! Have a great day.

Still following the thread I mentioned above, I saw that the eval previously was right before RESULT=. I have tried to comment the if statement block and move eval, so this way # eval serial="\$tls_serial_${check_depth}" # if [ -n "$serial" ]; then eval serial="\$tls_serial_${check_depth}" RESULT=$(/usr/local/bin/php-cgi -q /etc/inc/openvpn.tls-verify.php "servercn=$2&depth=$3&certdepth=$4&certsubject=$5&serial=$serial&co nfig=$config") if [ "${RESULT}" = "FAILED" ]; then exit 1 fi # fi and I don't get anymore the error on the certificate! I don't know if I need to open an issue about this. However, now I get the error about the user authentication SENT CONTROL [spike]: 'AUTH_FAILED' (status=1) like I was getting when I set "Certificate Depth = Do Not Check". I looks like I'm not the only one having this issue.

Heyho, after a lot of digging in my states I found the solution. Just a update: The VPN Transfernetwork is 192.168.2.0/24 and the virtual NIC on the server got 192.168.10.2/24. After letting a ping happen I saw the state: 192.168.2.1 -> 192.168.0.1 and then it clicked! In this cases it sees teh connection from the transfer net, not the virtual IP. Buildung the correct Floating rules made everything happen like I want it. But thanks again for the hint with RFC1918! I was soo deep in the subnetting, that I overlooked that :(

@viragomann Hello, I finally found the error. The NAT of the local interface on the VPN interface was missing!

@frog Just rename the ovpn file you have at the clients There is no "central" way of doing this

Still an issue in 22.01 (pfSense+). The same workaround applies i.e. turning off "Extended Query" in LDAP authentication. Still not ideal since it doesn't allow fine grain control over which AD users are allowed to use OpenVPN service. Has anybody come up with a better workaround? Would it make sense to use Client Specific Overrides option for access restriction?

@viragomann ypu are absolutely correct. I'm an idiot. I accidentally configured pfsense to only use 127.0.0.1 as DNS resolver and not as first with fallback to the ISP DNS

@stephenw10 Orz

Dear @viragomann I checked the two connection while "Duplicate Connection" checked. But I can not connect still with the second user unfortunately. Regards, Mucip:)