search

OpenVPN / openvpn

OpenVPN is an open source VPN daemon
http://openvpn.net
Other
10.75k stars 2.99k forks source link

No actual DNS lookup but cached wrong remote IP address #502

Closed jameskimmel closed 7 months ago

jameskimmel commented 7 months ago

Describe the bug OpenVPN connect does not resolve myhost.hopto.org to its correct A and AAAA record. Instead it has some cache that point to a wrong IP. TCP/UDP: Preserving recently used remote address: 185..... That IP seems to be a Turkish IP I never had any connection to. On the same client, nslookup in terminal for myhost.hopto.org does not resolve the wrong IP but gives the correct A and AAAA record.

Background info: We switched from pfsense to OPNsense, so clients had a working VPN config before. I deleted the old config and inserted the new one. Configs are under program files, because users don't have admin right.

To Reproduce

Expected behavior Do an actual A or AAAA record lookup.

Version information (please complete the following information):

Additional context By manually inserting an IP instead of a FQDN, I found a funny workaround that solves the problem.

flichtenheld commented 7 months ago

A few questions:

jameskimmel commented 7 months ago

Since you applied the work-around to reset the cache, I assume you can not reproduce the problem anymore?

I probably could. There are 5 other users I will have to do this and it happened twice already. Should I try to log something?

You have no idea where that IP address came from?

No idea. The strange thing is, my ISP and my IP always starts with 85.

Could you post a log of a wrong connection attempt, not just the one line?

I did not see any warnings despite the chached password warning. But will do that when I try another client.

Could you post a copy of your config (with the secrets removed, obviously)?

Sure

dev tun
persist-tun
persist-key
client
resolv-retry infinite
remote x.hoptop.org 11940 udp
lport 0
verify-x509-name "C=CH, ST=x, L=x, O=x, emailAddress=info@x, CN=openvpn-server-new" subject
remote-cert-tls server
auth-user-pass
<ca>
-----BEGIN CERTIFICATE-----
x
-----END CERTIFICATE-----

</ca>
<cert>
-----BEGIN CERTIFICATE-----
y
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
z
-----END PRIVATE KEY-----
</key>

Any reason you haven't updated to 2.6.x? Not that I claim that it would behave differently, more curious. 2.5.9 is a year old at this point.

Sorry, that was a typo. It is 2.6.9.

The client is a default export from OPNsense OpenVPN new Instance.

jameskimmel commented 7 months ago

Ok, I just reproduced it with another user.

First log is the old config file. That is obviously broken, even the port is different. Old port was 1196, new port is 11940. But it resolves to the right IP. Here are the logs for that:

2024-02-19 13:33:01 OpenVPN 2.6.7 [git:v2.6.7/53c9033317b3b8fd] Windows [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Nov  8 2023
2024-02-19 13:33:01 Windows version 10.0 (Windows 10 or greater), amd64 executable
2024-02-19 13:33:01 library versions: OpenSSL 3.1.4 24 Oct 2023, LZO 2.10
2024-02-19 13:33:01 DCO version: 1.0.0
2024-02-19 13:33:03 TCP/UDP: Preserving recently used remote address: [AF_INET]85.....:1196
2024-02-19 13:33:03 UDPv4 link local: (not bound)
2024-02-19 13:33:03 UDPv4 link remote: [AF_INET]85.......:1196
2024-02-19 13:33:12 SIGTERM received, sending exit notification to peer
2024-02-19 13:33:13 SIGTERM[soft,exit-with-notification] received, process exiting

Then I updates OpenVPN to the 2.6.9 and replaced the old config with the new config. Destination is still the same, still myhost.hopto.org. But now it resolves to a IP I never heard of. Then log shows me this: 

2024-02-19 13:35:47 Note: --cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
2024-02-19 13:35:47 OpenVPN 2.6.9 [git:v2.6.9/6640a10bf6d84eee] Windows [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Feb 12 2024
2024-02-19 13:35:47 Windows version 10.0 (Windows 10 or greater), amd64 executable
2024-02-19 13:35:47 library versions: OpenSSL 3.2.0 23 Nov 2023, LZO 2.10
2024-02-19 13:35:47 DCO version: 1.0.0
2024-02-19 13:36:14 TCP/UDP: Preserving recently used remote address: [AF_INET]185.174.30.26:11940
2024-02-19 13:36:14 ovpn-dco device [OpenVPN Data Channel Offload] opened
2024-02-19 13:36:14 UDP link local (bound): [AF_INET][undef]:0
2024-02-19 13:36:14 UDP link remote: [AF_INET]185.174.30.26:11940
2024-02-19 13:36:53 SIGTERM[hard,] received, process exiting

So after that, I set remote to 1.1.1.1. That obviously fails and gives me this log:

2024-02-19 13:39:33 Note: --cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
2024-02-19 13:39:33 OpenVPN 2.6.9 [git:v2.6.9/6640a10bf6d84eee] Windows [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Feb 12 2024
2024-02-19 13:39:33 Windows version 10.0 (Windows 10 or greater), amd64 executable
2024-02-19 13:39:33 library versions: OpenSSL 3.2.0 23 Nov 2023, LZO 2.10
2024-02-19 13:39:33 DCO version: 1.0.0
2024-02-19 13:39:35 TCP/UDP: Preserving recently used remote address: [AF_INET]1.1.1.1:11940
2024-02-19 13:39:35 ovpn-dco device [OpenVPN Data Channel Offload] opened
2024-02-19 13:39:35 UDP link local (bound): [AF_INET][undef]:0
2024-02-19 13:39:35 UDP link remote: [AF_INET]1.1.1.1:11940
2024-02-19 13:39:38 SIGTERM[hard,] received, process exiting

After that I reinsert the config file. This is exactly the same file as with the second log. This time it works. 

2024-02-19 13:41:57 Note: --cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
2024-02-19 13:41:57 OpenVPN 2.6.9 [git:v2.6.9/6640a10bf6d84eee] Windows [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Feb 12 2024
2024-02-19 13:41:57 Windows version 10.0 (Windows 10 or greater), amd64 executable
2024-02-19 13:41:57 library versions: OpenSSL 3.2.0 23 Nov 2023, LZO 2.10
2024-02-19 13:41:57 DCO version: 1.0.0
2024-02-19 13:41:59 TCP/UDP: Preserving recently used remote address: [AF_INET]85............:11940
2024-02-19 13:41:59 ovpn-dco device [OpenVPN Data Channel Offload] opened
2024-02-19 13:41:59 UDP link local (bound): [AF_INET][undef]:0
2024-02-19 13:41:59 UDP link remote: [AF_INET]85.1...........:11940
2024-02-19 13:41:59 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2024-02-19 13:41:59 [openvpn-server-new] Peer Connection Initiated with [AF_INET]85......:11940
2024-02-19 13:42:01 IPv4 dns servers set using service
2024-02-19 13:42:01 IPv4 MTU set to 1500 on interface 23 using service
2024-02-19 13:42:01 Initialization Sequence Completed
2024-02-19 13:42:05 IPv4 dns servers deleted using service
2024-02-19 13:42:05 SIGTERM[hard,] received, process exiting
ordex commented 7 months ago

Are you saying that 185.174.30.26 is the wrong IP?

I am asking because from here I also resolve (without using OpenVPN) *.hoptop.org to 185.174.30.26 If that's the case, then this means that the issue is likely unrelated to OpenVPN, but there is some DNS fault.

ordex commented 7 months ago

hm Are you mistyping the hostname? I see you later mentioned myhost.hopto.org which is not the same of the non-working connection.

note: hoptop.org vs hopto.org

jameskimmel commented 7 months ago

I see you later mentioned myhost.hopto.org which is not the same of the non-working connection.

Wait a minute. DingDingDingDing! You won! Holy cra* that is embarrassing! You are absolutely right! I am so, so sorry for wasting your time!

In my client export, I had a typo. When I replaced it with 1.1.1.1 and then replaced it again with myhost.hopto.org it worked. Thank you so much and sorry again for wasting your time!