22.05 - DCO and OpenVPN issue

JeGr

@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

stephenw10

I mean can clients other than .2 ping the server tunnel IP?

stephenw10

I've been unable to replicate this so far. Did you test disabling AES-NI?

JeGr

@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

stephenw10

Ah, OK I was testing to the LAN IP. Retesting....

stephenw10

Ok, replicated it. Let me see if I can narrow it down....

swixo

@stephenw10 Whew! Glad this was tracked down.

stephenw10

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

JeGr

@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.

stephenw10

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

JeGr

@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 :)