Re: DNS Round-robin-records vs. "Preserving recently used remote address"

Jochen Bern <[email protected]>
Newsgroups gmane.network.openvpn.user
Organization Binect GmbH
Message-ID <[email protected]>
On 03.04.24 11:31, Ralf Hildebrandt via Openvpn-users wrote:
> We're using DNS Round-robin-records with a TTL of 300s for our openvpn
> endpoint servers.
> 
> Yet, clients seem to reconnect to the same IP, although the DNS entry
> has expired; the log usually shows something like:
> 
> 2024-02-21 11:37:04 TCP/UDP: Preserving recently used remote address: [AF_INET]193.175.73.xxx:1194
> 
> Yes, it makes perfect sense to re-use a known IP, especially in the
> VPN context (DNS settings might just be off while dropping out of the
> VPN etc.), but this does really clash with our intentionally low TTL -
> at least when we're removeing one endpoint from the DNS for maintenance.

I shall assume that your question is "how do I tell the client *not* to 
try sticking to the last IP used?". ;-)

I don't see such an option in the docs (for 2.6, to be precise), but let 
me ask a question for clarification: Does your setup answer requests to 
a now-disabled IP with some explicit denial (ICMP UNREACHABLE, RST, 
whatever), in which case I'd be surprised if the client takes more than 
a second or two to give up on the old server, or are we talking about 
one or more minute-or-so timeout delays?

If the latter, would it be possible to extend your 
going-down-for-maintenance routines so as to tell some firewall to 
generate such denial packets?

On 03.04.24 12:40, Marek Zarychta via Openvpn-users wrote:
> in your case setting "explicit-exit-notify 2" on the servers should solve the problem.

... as long as the VPNs are running in UDP mode, and the server goes 
through an *orderly* shutdown ...

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH

_______________________________________________
Openvpn-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-users
smime.p7s (application/pkcs7-signature, 3.4 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.