Blame
| 9efbdc | Samuli Seppänen | 2025-02-11 11:53:56 | 1 | # Problems with TLS |
| 2 | ||||
| 3 | > 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, |
|||
| 4 | > 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 |
|||
| 5 | > 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? |
|||
| 6 | ||||
| 7 | 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). |
|||
| 8 | ||||
| 9 | There are several ways to fix this problem, listed in the order of preference: |
|||
| 10 | ||||
| 11 | 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. |
|||
| 12 | ||||
| 13 | 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. |
|||
| 14 | ||||
| 15 | Use static keys which allow OpenVPN to run in an essentially stateless manner. |
|||
| 16 | ||||
| 17 | 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. |