Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

No adapter domain suffix with DCO driver on Windows (in ovpnagent mode) #304

Open
savely-krasovsky opened this issue Apr 3, 2024 · 1 comment · May be fixed by #305
Open

No adapter domain suffix with DCO driver on Windows (in ovpnagent mode) #304

savely-krasovsky opened this issue Apr 3, 2024 · 1 comment · May be fixed by #305

Comments

@savely-krasovsky
Copy link

savely-krasovsky commented Apr 3, 2024 •
edited

I came from this issue: OpenVPN/openvpn#306, but it seems like OpenVPN3 should support it. However after debugging it a bit I saw this, log from DCO agent:

Set adapter domain suffix: 'COMPANY'

Log from Wintun:

Set adapter domain suffix: 'COMPANY' {15E232D8-514C-4947-A0F6-F8C27904B8F4}

As you can see, Wintun properly logs not only suffix, but also interface GUID.

But it should be logged if everything would be okay:

virtual std::string to_string() const override
{
     return "Set adapter domain suffix: '" + search_domain + "' " + tap_guid;
}

Because tap_guid variable is empty for some reason, the code which manipulates the registry:

virtual void execute(std::ostream &os) override
    {
        os << to_string() << std::endl;

        LONG status;
        Win::RegKey key;
        const std::string reg_key_name = "SYSTEM\\CurrentControlSet\\services\\Tcpip\\Parameters\\Interfaces\\" + tap_guid;
        status = ::RegOpenKeyExA(HKEY_LOCAL_MACHINE,
                                 reg_key_name.c_str(),
                                 0,
                                 KEY_READ | KEY_WRITE,
                                 key.ref());
        // code ...

Writes in a complitely wrong place, in the SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces root, and I clearly see it:
изображение

It's definitely a bug, currently trying to debug the reason behind this behavior.
@savely-krasovsky savely-krasovsky linked a pull request Apr 3, 2024 that will close this issue
Open
@savely-krasovsky
Copy link
Author

savely-krasovsky commented Apr 3, 2024 •
edited

I've prepared the fix, currently adapter_guid just doesn't passed between /tun-open and /tun-setup requests to ovpnagent.

lstipakov pushed a commit to lstipakov/openvpn3 that referenced this issue Apr 5, 2024
@lstipakov
ovpnagent: fix ADAPTER_DOMAIN_SUFFIX option when using DCO
ff54f5d 
Setting ADAPTER_DOMAIN_SUFFIX for non-DHCP adapters requires
registry modification. For that, we need adapter GUID.

This passes adapter GUID from agent to client via /tun-open call
and then from client to agent via /tun-setup call, when adapter
domain suffix is set.

Github: OpenVPN#304

Signed-off-by: Lev Stipakov <[email protected]>
Signed-off-by: Krasovskiy Saveliy Igorevich <[email protected]>
flichtenheld pushed a commit to flichtenheld/openvpn3 that referenced this issue Apr 25, 2024
@dsommers
ovpnagent: fix ADAPTER_DOMAIN_SUFFIX option when using DCO
dbc6a14 
Setting ADAPTER_DOMAIN_SUFFIX for non-DHCP adapters requires
registry modification. For that, we need adapter GUID.

This passes adapter GUID from agent to client via /tun-open call
and then from client to agent via /tun-setup call, when adapter
domain suffix is set.

Github: OpenVPN#304

Signed-off-by: Lev Stipakov <[email protected]>
Signed-off-by: Krasovskiy Saveliy Igorevich <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix: set adapter domain suffix correctly with DCO savely-krasovsky/openvpn3
1 participant
@savely-krasovsky