Hello community,
we have a real annoying problem in the following scneario for a while now, and i cant figure it out.
Following setup:
IPFIRE-A is connected via OpenVPN N2N connections to a few other IPFire´s out in the field over the country. Some of them are connected via UMTS, some with VDSL.
Two of those connected IPFire´s via VDSL and a static IP (the Central IPFIRE has a static IP as well) are now loosing the connection from time to time, mostly for a short time. To be precise it seems to that the VPN tunnel gets lost for a minute, sometimes 3 to 5 minutes. I have ran some pinging test through the tunnel which confirmed me that the tunnel is down from time to time for a minute. Also we have some SPS equipment which complains about the connection loss.
The log says this (verb3 at the moment, i can not bring the thing down for maintenance that easy… but i will increase the log level next week):
Here is my server.conf from the server side of course ;):
#OpenVPN Server conf
daemon openvpnserver
writepid /var/run/openvpn.pid #DAN prepare OpenVPN for listening on blue and orange
;local mysite.MYDOMAIN.de
dev tun
proto udp
port 1194
script-security 3
ifconfig-pool-persist /var/ipfire/ovpn/ovpn-leases.db 3600
client-config-dir /var/ipfire/ovpn/ccd
tls-server
ca /var/ipfire/ovpn/ca/cacert.pem
cert /var/ipfire/ovpn/certs/servercert.pem
key /var/ipfire/ovpn/certs/serverkey.pem
dh /var/ipfire/ovpn/ca/dh1024.pem
server 10.54.50.0 255.255.255.0
tun-mtu 1500
status-version 1
status /var/run/ovpnserver.log 30
ncp-disable
cipher AES-256-CBC
comp-lzo
max-clients 100
tls-verify /usr/lib/openvpn/verify
crl-verify /var/ipfire/ovpn/crls/cacrl.pem
user nobody
group nobody
persist-key
persist-tun
verb 3
TLS Error: local/remote TLS keys are out of sync: [AF_INET]XX.XX.XX.46:1200 [7 ]
if this message comes up and both sides of the connection
reconnect and the connection comes up again, OpenVPN is
operating normally. If this message appears regular it can also be possible the the time on both sides differ.
This message should not appear by the usage of TCP instead of UDP.
A beneath one, the configuration which you´d posted is the sevrer.conf from OpenVPN server. The N2N configs are findable under /var/ipfire/ovpn/n2nconf/{connenction_name}
Hi,
Thanks for your reply!
As i said most of the time it comes up again, but it takes up to a minute.
The time is absolute in sync …
Once i read somewhere that it is better to use UDP over TCP when creating N2N tunnels with OpenVPN. Do you think im wrong here and that we should switch over to TCP?
If so, can i do it step by step, from tunnel to tunnel?
Here comes the log file:
# IPFire n2n Open VPN Server Config by ummeegge und m.a.d
# User Security
user nobody
group nobody
persist-tun
persist-key
script-security 2
# IP/DNS for remote Server Gateway
remote pw-MYSITE.MYDOMAIN.de
float
# IP adresses of the VPN Subnet
ifconfig 192.168.190.1 192.168.190.2
# Client Gateway Network
route 192.168.124.0 255.255.255.0
up "/etc/init.d/static-routes start"
# tun Device
dev tun
#Logfile for statistics
status-version 1
status /var/run/openvpn/PWMYSITE-n2n 10
# Port and Protokol
port 1200
proto udp
# Paketsize
tun-mtu 1500
fragment 1300
mssfix
# Auth. Server
tls-server
ca /var/ipfire/ovpn/ca/cacert.pem
cert /var/ipfire/ovpn/certs/servercert.pem
key /var/ipfire/ovpn/certs/serverkey.pem
dh /var/ipfire/ovpn/ca/dh1024.pem
# Cipher
cipher AES-256-CBC
# HMAC algorithm
auth SHA512
# Debug Level
verb 3
# Tunnel check
keepalive 10 60
# Start as daemon
daemon PWMYSITEn2n
writepid /var/run/PWMYSITEn2n.pid
# Activate Management Interface and Port
management localhost 1200
OK, in what time periods comes the out of sync up ?
yes you are right TCP over TCP can causes problems but in fact i have faced no real issues by the usage of ‘–proto tcp’ via RWs (which i regular use), it may depends on the traffic inside the tunnel.
You wrote from two tunnels which does have that ‘problem’, why don´t you try it one by one with some testing periods without migrating the whole infrastructure ? (IMPORTANT → you need to make those modifications on both sides !!!)
May only an ortho but this is the configuration file .
As a beneath one, you ask above about ‘–ping’ and ‘–ping-restart’, this should be done by the ‘–keealive’ directive.
OK, in what time periods comes the out of sync up ?
Well thats totally different. Mostly once a day but the times are completely random, at least for me.
Ok i see.
If i can switch one tunnel after the other its nor a big problem. We are talking about 10 IPFire´s out in the field which are connecting to the main IPFire. It would cost me a lot of work if i had to change every N2N connection just to try out TCP.
…
.