search

openwrt / packages

Community maintained packages for OpenWrt. Documentation for submitting pull requests is in CONTRIBUTING.md
GNU General Public License v2.0
4.05k stars 3.51k forks source link

openconnect: Fail to connect if IPv6 is not available but domain name has IPv6 #20951

Closed Soberia closed 1 year ago

Soberia commented 1 year ago

Maintainer: @nmav Environment: MediaTek MT7621 ver:1 eco:3, Xiaomi Mi Router 3G, OpenWrt 22.03.2 r19803-9a599fee93

I have a personal ocserv server on a remote server which is configured to assign a private IPv4 range and public IPv6 with /112 CIDR to the clients. The ocserv is reachable with a domain that is pointed to a static IPv4 and IPv6. My ISP doesn't offer me an IPv6 subnet, so I have only IPv4 on my OpenWRT router. However, the OpenConnect client on OpenWRT can't connect to the server. This is the log:

image

However, if I remove the AAAA DNS record for the IPv6, the OpenConnect client works as expected with no problem:

image

There is no issue with both Windows and Linux clients.

nmav commented 1 year ago

I am not sure this is an issue to openwrt packaging of openconnect. It seems like a networking issue in this setup that openconnect doesn't handle well. I suggest you open a ticket on https://gitlab.com/openconnect/openconnect about it. As a quick fix you will need to append --disable-ipv6 on the openconnect command line.

dwmw2 commented 1 year ago

Looks like an issue with the OpenWrt scripting around openconnect, not openconnect itself.

dwmw2 commented 1 year ago

Sorry, wasn't paying attention there and didn't realise I was directly contradicting what @nmav had said; for some reason I thought this original ticket was against ocserv (which definitely makes no sense). I'll try again with actual evidence and explanations...

In the first log (which would be a lot nicer if it were actual text instead of a picture), we see those user.notice openconnect: adding host dependency for 2a01:…b7:10:2 at openconnect messages. Those don't come from openconnect itself; those are the OpenWrt scripting. It detects when it has a route to the VPN server, and only then does it actually spawn openconnect. It looks like in the failing case, it never does detect that it has a route. And thus we never even see the log line that says executing openconnect...

It looks like the OpenWrt route triggering may have bugs when there are multiple targets; it might be related to the fact that one of them is IPv6 and the other is Legacy IP, but it's also possible that it'd fail if both were the same protocol, if it can route to one but not both?

Soberia commented 1 year ago

Sorry for the logs. I thought it would be more readable to put it as a picture to just highlight the OpenConnect logs. I think this is the line that triggers the issue.