Commit 9efbdc
2025-02-11 11:53:56 Samuli Seppänen: -/-| /dev/null .. FAQ/329-problems-with-tls.md | |
| @@ 0,0 1,17 @@ | |
| + | # Problems with TLS |
| + | |
| + | > I'm using TLS mode with no --remote option on the server. When I start the server then the client it works ok. I can restart the client with no problem, |
| + | > but if I restart the server and the client is connected I get the following problem: "TLS Error: Unknown data channel key ID or IP address received from |
| + | > 111.222.333.444:10203". In this case I need to restart the client again to make it work. Do you know what the problem is? |
| + | |
| + | This problem occurs because when you restart the server, there is nothing to trigger a new TLS key exchange. The server can't trigger it because it doesn't have a --remote option giving it the address of its peer, so it wants to sit and wait for a client to connect. The client doesn't trigger it because it doesn't know the server was restarted (remember that UDP is connectionless). |
| + | |
| + | There are several ways to fix this problem, listed in the order of preference: |
| + | |
| + | Add a --remote option to the server which points to the client, making the connection peer-to-peer rather than client/server. When one peer restarts, it will force a new key exchange with the other peer. |
| + | |
| + | Use the --ping and --ping-restart options to force a key negotiation any time that packets are not getting through the tunnel. Restarts always trigger a new key exchange. |
| + | |
| + | Use static keys which allow OpenVPN to run in an essentially stateless manner. |
| + | |
| + | Use TCP rather than UDP as your tunnel transport (available currently in the 1.5.x and higher with the --proto option). TCP is a connection-oriented protocol, and as such, either side of the connection knows immediately when the other side has disconnected. |