|
|
Thank you for your time in responding to this.
James Yonan wrote:
On Saturday 31 July 2004 01:43, Erik Anderson wrote:
I've been using OpenVPN to connect several machines, but I have been rathar
concerned about stability, especially as it is necessary to maintain a
stable connection between the VPN hub and a satellite machine on the other
side of the country. The machine here is on a frac-T1 link, the satellite
is on a DSL connection.
I have recently (this afternoon) upgraded the satellite from 1.6, it is now
running 2.0b8 against a 2.0b5 server (will upgrade soon), but now that it
is connecting on the newer protocol (and I'm receiving hourly status
reports) I'm seeing an awful lot of connection instabilities. Here's one
excerpt from the logs. Note that the configuration files are nearly
identical on both sides.
I think part of me is wondering (1) is this normal and to be expected, and
(2) if not, what are good ways to look at improving things. I have not had
any significant problems with the actual connections themselves, So I don't
believe this to be an MTU problem (at least not obviously). I had
previously noticed that significant use of the VPN (remote desktop) would
cause 10-min outages, but I believe that this was a rathar old router
(which was replaced last week because of these strange outages)
--
Security Events
=-=-=-=-=-=-=-=
Jul 30 22:15:52 knight openvpn[2844]: cpm-t30/1.2.3.4:5009 Authenticate/Decrypt packet error: packet HMAC authentication failed
These messages (above) usually mean one of three things:
(1) You are using different static or --tls-auth keys on both sides of the
connection.
(2) Packets are getting corrupted somewhere.
(3) OpenVPN is receiving packets sent by another program, not OpenVPN.
Unfortunately of these three options I would think that #2 is the most likely. The "ca" argument is definately identical on all sides of the connection, and these messages appear to be sporatic anyhow (The connection is working at least 70% of the time as it is, I would expect zero connectability if the keys were different)
Jul 30 22:15:53 knight openvpn[2844]: cpmt40/1.2.3.4:15009 Authenticate/Decrypt packet error: packet HMAC authentication failed
Jul 30 22:16:08 knight openvpn[2844]: cpmt40/1.2.3.4:15009 Authenticate/Decrypt packet error: packet HMAC authentication failed
Jul 30 22:16:08 knight openvpn[2844]: cpm-t30/1.2.3.4:5009 Authenticate/Decrypt packet error: packet HMAC authentication failed
Jul 30 22:16:22 knight openvpn[2844]: cpmt40/1.2.3.4:15009 Authenticate/Decrypt packet error: packet HMAC authentication failed
Jul 30 22:16:22 knight openvpn[2844]: cpm-t30/1.2.3.4:5009 Authenticate/Decrypt packet error: packet HMAC authentication failed
Jul 30 22:27:49 knight openvpn[2844]: cpmt40/1.2.3.4:5009 Authenticate/Decrypt packet error: packet HMAC authentication failed
Jul 30 22:27:55 knight openvpn[2844]: cpm-t30/1.2.3.4:15009 Authenticate/Decrypt packet error: packet HMAC authentication failed
Jul 30 22:28:05 knight openvpn[2844]: cpmt40/1.2.3.4:5009 Authenticate/Decrypt packet error: packet HMAC authentication failed
Jul 30 22:28:10 knight openvpn[2844]: cpm-t30/1.2.3.4:15009 Authenticate/Decrypt packet error: packet HMAC authentication failed
Jul 30 22:39:55 knight openvpn[2844]: cpm-t30/1.2.3.4:5009 Authenticate/Decrypt packet error: packet HMAC authentication failed
Jul 30 22:39:56 knight openvpn[2844]: cpmt40/1.2.3.4:15009 Authenticate/Decrypt packet error: packet HMAC authentication failed
Jul 30 22:40:11 knight openvpn[2844]: cpm-t30/1.2.3.4:5009 Authenticate/Decrypt packet error: packet HMAC authentication failed
Jul 30 22:40:12 knight openvpn[2844]: cpmt40/1.2.3.4:15009 Authenticate/Decrypt packet error: packet HMAC authentication failed
Jul 30 22:40:26 knight openvpn[2844]: cpm-t30/1.2.3.4:5009 Authenticate/Decrypt packet error: packet HMAC authentication failed
...
Jul 30 22:28:24 knight openvpn[2844]: cpmt40/1.2.3.4:15009 MULTI: multi_close_instance called
Jul 30 22:28:24 knight openvpn[2844]: MULTI: no dynamic or static remote --ifconfig address is available for cpmt40/1.2.3.4:15009
This may be the problem (above). Unless you're using DHCP or not interested
in tunneling the IP protocol, make sure that the OpenVPN server has enough
information so that it can push a virtual address (or ifconfig address) to
the client. Normally, that means using either --ifconfig-pool, DHCP, or
fixed IPs assigned to specific client certificates using --ifconfig-push.
James
I am currently using an external DHCP server (on the same machine),
mostly so that I can provide DHCP-driven DNS. I'm assuming that this
means that I can ignore this warning, at least until I start moving
people to TUN-based VPN's.
At the moment, it sounds like all I can do right now is try to diagnose
connection-based failures such as what Jon was mentioning previously.
The person running the network over there is using a wireless LAN
system, which it sounds like may be contributing to these faults.
|