|
|
Greetings, EXECUTIVE SUMMARY (SPECULATIVE): An OpenVPN 2.1rc1 server hangs onto its old dynamic IP address in multihome mode, and spews nodev errors. DETAIL: I am running an openvpn server with 4 public dynamic IP addresses, one of which is a PPP connection - the target for one of the VPN connections. The server simultaneously serves VPN at 'static' addresses (NAT DMZ targets). The most significant parts of the server configuration are: multihome keepalive 10 120 It appears that after the IP address changes, if the server continues to receive traffic from a peer at its NEW ip address, then things go wrong. Here are selected log entries (complete logs available on request). Initially, all is well. 41.241.139.92 is the address of the remote server: > Jan 19 08:36:42 pretoria pppd[10126]: local IP address 41.242.239.18 > Jan 20 08:26:07 pretoria openvpn[5634]: nelspruit/41.241.139.92:1194 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA The server reconnects its ppp connection, gets a *new* ip address, and suddenly openvpn can't send packets anymore: > Jan 20 09:23:46 pretoria pppd[2770]: LCP terminated by peer > Jan 20 09:23:54 pretoria pppd[32061]: local IP address 41.241.138.197 > Jan 20 09:23:54 pretoria openvpn[5634]: nelspruit/41.241.139.92:1194 write UDPv4 []: No such device (code=19) > Jan 20 09:24:04 pretoria openvpn[5634]: nelspruit/41.241.139.92:1194 write UDPv4 []: No such device (code=19) > Jan 20 09:24:14 pretoria openvpn[5634]: nelspruit/41.241.139.92:1194 write UDPv4 []: No such device (code=19) Later, the timeout happens somewhere (on the remote, I think), and a new session starts: > Jan 20 09:26:07 pretoria openvpn[5634]: nelspruit/41.241.139.92:1194 TLS: soft reset sec=0 bytes=60346/0 pkts=882/0 > Jan 20 09:26:07 pretoria openvpn[5634]: nelspruit/41.241.139.92:1194 write UDPv4 []: No such device (code=19) Even when the client re-initiates the session, it is considered to be a continuation of the stuck session: > Jan 20 09:26:13 pretoria openvpn[5634]: nelspruit/41.241.139.92:1194 write UDPv4 []: No such device (code=19) > Jan 20 09:26:15 pretoria openvpn[5634]: nelspruit/41.241.139.92:1194 write UDPv4 []: No such device (code=19) For no particular reason, the error message later changes from "No device" to "Invalid argument" -- just over 2 hours laters. (The client reports that the link is down daily for two hours every day...) > Jan 20 11:34:05 pretoria openvpn[5634]: nelspruit/41.241.139.92:1194 write UDPv4 []: No such device (code=19) > Jan 20 11:34:15 pretoria openvpn[5634]: nelspruit/41.241.139.92:1194 write UDPv4 []: Invalid argument (code=22) What I think is happening is that an invalid outgoing address is selected, and this address is associated with the connection. As long as traffic continues to flow (in the form of repeated TLS negotiation), OpenVPN never notices that it is not managing to send data packets. Strangely, selecting the correct outgoing address seems to work until the TLS negotiation is complete. As a work-around, I now restart OpenVPN with the PPP link -- dropping unaffected links in the process. If my diagnosis is correct, a quick hack would be to reset the connection whenever the no-device error occurs during 'write'. Currently, if you add 'float' in a multihome environment, when the server side IP address changes, the server continues to use the previous IP address (similar to the above), and this problem occurs without requiring a change of IP address. A better fix would be to extend 'float' to accommodate changes in the local address which is being addressed. The correct strategy (I reckon) would be to change the target and source address and ports as soon as a "good" packet is received with different addresses. &:-) -- Disclaimer: we reject your disclaimer (with contempt) ______________________ OpenVPN mailing lists https://lists.sourceforge.net/lists/listinfo/openvpn-users |