22.05 - DCO and OpenVPN issue
-
@swixo Tried a bunch of these changes and made things worse.
Intel Hardware accel had no effect. But the Key Dir and Auth Only/Auth+Encry setting made a lot of difference. Had to export new profiles after every change to make sure clients were in sync.
Most of the time - I couldn't connect at all - or data never flowed, until turning DCO off - then it usually worked fine after that.
-
@jimp Just to chime in:
we were rolling out 2 new boxes 6100/4100 to a customer and I set up OpenVPN RAS pretty default with new DCO setting.
Exactly same problem: .2 client can connect and route/transfer data, all other client IPs don't get ANY data at all sent through the connection. Switching off DCO immediatly works again. No spiffy or special stuff configured, just plain dead simple RAS setup with a single LAN network that gets pushed to the clients.
Clients are 2x windows boxes with win10, newest OVPN Client 2.5.9/x64 and have no problems whatsoever. Routes are just fine, traffic simply refuses to flow through the server if you're not client #.2 :)
System is on 22.05 stable
Cheers
\jens -
Hmm, were those supplied with 22.05 or upgraded from 22.01?
Does that include traffic between IPs in the tunnel subnet directly?
-
@stephenw10 Those were freshly installed with 22.01 and clean upgraded to 22.05 - at least there were no errors or other hiccups in the logs or anywhere to see.
Besides that it's a simple straightforward RAS style setup:
- SSL/TLS + User Auth
- DCO
- tun L3
- UDP/1194
- TLS Key with TLS Auth (not auth+enc), default direction
- VPN CA, VPN Cert, VPN CRL created
- ECDH only
- prime256v1
- SHA256
- no HW crypt (but AES-NI enabled kernel module)
- cert depth 1 (C+S)
- Strict User-CN Matching
- Enforce Key usage
- IP4 tunnel network 192.168.45.0/26 (to leave space to add another VPNs server later with .45.64/26, .45.128/26, etc.)
- IP4 local network 192.168.40.0/24 (LAN)
- compression: refuse any non stub (most secure)
- dynamic IP selected
- subnet
- keepalive 5 30
- DNS default domain set up to the locally used domain
- DNS server set up to the local MS AD server
- Gateway v4 only
- Verb 3
nothing else set. The RAS clients aren't supposed to talk with each other so no, inter-client comm isn't a thing here :)
Cheers
\jens -
I mean can clients other than .2 ping the server tunnel IP?
-
J jimp moved this topic from Plus 22.05 Development Snapshots (Retired) on
-
I've been unable to replicate this so far. Did you test disabling AES-NI?
-
@stephenw10 said in 22.05 - DCO and OpenVPN issue:
I mean can clients other than .2 ping the server tunnel IP?
Ah that's what you meant! I just switched DCO back on and tested for you:
- VPN net: 192.168.45.0/24
- LAN net: 192.168.40.0/24
When DCO is on:
-
Client 1 connected as .45.2:
- ping to .45.1 (VPN GW) -> works
- ping to 40.1 (FW IP in LAN) -> works
- ping to 40.x (any other IP then Firewall) -> works
- can connect to e.g. Server on 192.168.40.10
-
Client 2 connected as .45.3:
- ping to .45.1 (VPN GW) -> works
- ping to 40.1 (FW IP in LAN) -> works
- ping to 40.x (any other IP then Firewall) -> DOESN'T work
- no connect to any other device on the LAN is working
As there are IPsec tunnels currently in use I couldn't disable crypto but it is set to QAT - not AES-NI - as it's a 6100 :)
Cheers
-
Ah, OK I was testing to the LAN IP. Retesting....
-
Ok, replicated it. Let me see if I can narrow it down....
-
@stephenw10 Whew! Glad this was tracked down.
-
OK, this looks like an internal routing issue. As a workaround applying outbound NAT to traffic leaving the LAN appears to allow it to route replies as expected. If you want to test DCO that is.
Steve
-
@stephenw10 Would that be subject to a patch via "System Patches" or is the routing issue deeper than the patch system can go and requires a new build/version of some files? Just asking if that'd be hotfix'able.
-
It's probably not something that can be fixed with a run-time patch unfortunately. It looks to be in OpenVPN so something in the binary.
Steve
-
@stephenw10 said in 22.05 - DCO and OpenVPN issue:
It's probably not something that can be fixed with a run-time patch unfortunately. It looks to be in OpenVPN so something in the binary.
Steve
Thanks for clarifying - thus we know to currently not roll it out enabled per default :)
