@enesas To narrow it down check out if the pushed DNS server is used and if you can resolve host names on the client. Try a public name like google.com with nslookup or alike.

its hard to help you, there can be many things witch are wrong. without having a look into your router, its not possible for me to help you (maybe others)

I've had some success with using FRR on DCO, but I haven't tried it long term. The way the DCO interfaces are made they use kernel routing instead of OpenVPN internal routing. So the reason that overrides don't work with DCO also allows FRR to function, which depending on your use case, may be a great benefit instead of a drawback.

Thank you so much! That solution worked :)

@alfaro hey, i checked my iOS client settings and indeed, I couldn’t see the option anymore. So I checked the iOS OpenVPN version history here: iOS OpenVPN release notes and saw that they removed that option in the latest 3.3.0 release from July 19. Second line: Removed the “force AES-CBC cipher” legacy compatibility option. I am still connecting without any issues though.

@gertjan Which OpenVPN video are you referring to? I had this roadwarrior vpn access working in 2.5.2 fine with no issues. It is only after I upgraded to 2.6.0 that it would not connect.

@gertjan Thank you for teaching me, i will look into throughput more

@bob-dig this is the version distributed by the most current version of pfSense software.

@laserguidedcake A site to site should have a /30 tunnel, otherwise the server doesn"t know, where to Route the packets for the client side LAN. You can use a wider tunnel though if you want to connect multiple clients, but in this case you need to configure client specific overrides on the server to enable iroute in OpenVPN. Egress from the branch should also work without NAT nö.

@jj5588 Basically you can access any client by its virtual IP. However, you have to allow the access on the clients firewall. But for your purposes you can savely circumvent this with a masquerading rule on pfSense.

@damianhl Ok, forget about the first question, that was like a bug with openVPN client, after restart it, does not happen again. It seems it happen after you connected to a different WAN I still have the doubt about how to check from the pfsense, which interface clients are using to connect. I cannot find any log related. In the dashboard appears the source public IP, not the destination IP. Is there a way? Thanks in advance. Regards, Damián

@viragomann It's working! I had tried the static route on the VPN to the client side IP but it wasn't working, so I tried the server side. I ended up deleting the static route I made and going with your recommendation of letting OVPN do that. The pfsense client was already set to the /30 network. For anyone else in a similar scenario, read this: OpenVPN: Including multiple machines on the client side when using a routed VPN (dev tun). And I missed an "i" on the "iroute 192.168.0.0 255.255.255.0" in the client file in the CCD folder on the server. #Facepalm. Big thank you to @viragomann and @rcoleman-netgate !

@viragomann that does make sense I’ll try that in the morning thank you

@bob-dig Thank you so so much :)

Use topology subnet. One can set static tunnel IP in Client Specific Overrides. Common Name of the client cert must match username. Fill in the user static tunnel IP in IPv4 Tunnel Network, f.e.: 172.16.0.2/24 gives username1 a static tunnel IP .2 172.16.0.3/24 gives that username1 a static tunnel IP .3 172.16.0.1 is for the server and cannot be used. .0 .254 .255 cannot be used either.