In have an odd issue I'm trying to track down. I have an openVPN server sitting behind a firewall with the proper port forwarded.
I can connect to the VPN from my own network (same network as the VPN host), and on a fresh reboot of the machine, I can connect to the VPN from an outside IP (My phone over 4G). However, if I wait a day and try to connect again, it fails.
I've checked the logs and it appears the traffic is being routed through the firewall to the VPN server....its just been mangled somehow resulting in TLS errors.
Failed attempt from the external IP
Fri Sep 29 06:23:32 2017 174.192.7.70:10268 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #1 / time = (1506680610) Fri Sep 29 06:23:30 2017 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Fri Sep 29 06:23:32 2017 174.192.7.70:10268 TLS Error: incoming packet authentication failed from [AF_INET]174.192.7.70:10268
Fri Sep 29 06:23:34 2017 174.192.7.70:10268 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #1 / time = (1506680610) Fri Sep 29 06:23:30 2017 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Fri Sep 29 06:23:34 2017 174.192.7.70:10268 TLS Error: incoming packet authentication failed from [AF_INET]174.192.7.70:10268
Fri Sep 29 06:23:36 2017 174.192.7.70:10268 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #1 / time = (1506680610) Fri Sep 29 06:23:30 2017 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Fri Sep 29 06:23:36 2017 174.192.7.70:10268 TLS Error: incoming packet authentication failed from [AF_INET]174.192.7.70:10268
Fri Sep 29 06:23:38 2017 174.192.7.70:10268 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #1 / time = (1506680610) Fri Sep 29 06:23:30 2017 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Fri Sep 29 06:23:38 2017 174.192.7.70:10268 TLS Error: incoming packet authentication failed from [AF_INET]174.192.7.70:10268
Fri Sep 29 06:24:30 2017 174.192.7.70:10268 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Sep 29 06:24:30 2017 174.192.7.70:10268 TLS Error: TLS handshake failed
Successful connection from within the local network
Sat Sep 30 20:41:57 2017 192.168.1.1:40814 [phone] Peer Connection Initiated with [AF_INET]192.168.1.1:40814
Sat Sep 30 20:41:57 2017 phone/192.168.1.1:40814 MULTI_sva: pool returned IPv4=10.8.0.2, IPv6=(Not enabled)
Sat Sep 30 20:41:57 2017 phone/192.168.1.1:40814 send_push_reply(): safe_cap=940
I'm running 2.3.10 on armbian on an orange pi zero. The startup log is:
Thu Sep 28 21:26:20 2017 OpenVPN 2.3.10 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jun 22 2017
Thu Sep 28 21:26:20 2017 library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08
Thu Sep 28 21:26:20 2017 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Thu Sep 28 21:26:20 2017 Control Channel Authentication: using '/etc/openvpn/easy-rsa/pki/ta.key' as a OpenVPN static key file
Thu Sep 28 21:26:20 2017 TUN/TAP device tun0 opened
Thu Sep 28 21:26:20 2017 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu Sep 28 21:26:20 2017 /sbin/ip link set dev tun0 up mtu 1500
Thu Sep 28 21:26:20 2017 /sbin/ip addr add dev tun0 10.8.0.1/24 broadcast 10.8.0.255
Thu Sep 28 21:26:20 2017 GID set to nogroup
Thu Sep 28 21:26:20 2017 UID set to nobody
Thu Sep 28 21:26:20 2017 UDPv4 link local (bound): [undef]
Thu Sep 28 21:26:20 2017 UDPv4 link remote: [undef]
Thu Sep 28 21:26:20 2017 Initialization Sequence Completed
my conf file:
dev tun
proto udp
port 1941
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/server.crt
key /etc/openvpn/easy-rsa/pki/private/server.key
dh /etc/openvpn/easy-rsa/pki/dh2048.pem
topology subnet
server 10.8.0.0 255.255.255.0
# server and remote endpoints
ifconfig 10.8.0.1 10.8.0.2
# Add route to Client routing table for the OpenVPN Server
push "route 10.8.0.1 255.255.255.255"
# Add route to Client routing table for the OPenVPN Subnet
push "route 10.8.0.0 255.255.255.0"
# your local subnet
push "route 192.168.1.0 255.255.255.0"
# Set your primary domain name server address for clients
push "dhcp-option DNS 192.168.1.2"
push "dhcp-option DNS 8.8.8.8"
# Override the Client default gateway by using 0.0.0.0/1 and
# 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
# overriding but not wiping out the original default gateway.
push "redirect-gateway def1"
client-to-client
duplicate-cn
keepalive 10 120
tls-version-min 1.2
tls-auth /etc/openvpn/easy-rsa/pki/ta.key 0
cipher AES-256-CBC
auth SHA256
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
#crl-verify /etc/openvpn/crl.pem
status /var/log/openvpn-status.log 20
status-version 3
log /var/log/openvpn.log
verb 1
mssfix 1300
The config section of my openVPN client file:
client
dev tun
proto udp
remote <public ip address> 1194
resolv-retry infinite
nobind
persist-key
persist-tun
key-direction 1
remote-cert-tls server
tls-version-min 1.2
verify-x509-name server name
cipher AES-256-CBC
auth SHA256
comp-lzo
verb 1
Has anyone seen this before? I've seen the reported bug with 3G/4G, but it's unclear to me why rebooting the machine (not just restarting the service) would temporarily fix it.
