OpenVPN bricht immer wieder ab

thorwin

thorwin

Well-Known Member
Moin,

ich hänge hier in meinem Homenetz (d.h. hinter einem NAT-Gateway = Fritz!Box 7360SL) mit einer OpenBSD-Box (6.0; amd64) an einem OpenVPN-Tunnel zu portunity. Leider bricht der Tunnel immer wieder zusammen. D.h., er bricht nicht wirklich zusammen, es geht nur kein Traffic mehr durch.ich sehe in /var/log/messages haufnweise Meldungen wie diese hier:
Code: 
Oct  8 08:00:03 sauron unbound: [44049:0] notice: remote address is 217.144.128.33 port 53
Oct  8 08:00:03 sauron unbound: [44049:0] notice: sendto failed: No buffer space available
Restarten des Tunnels hilft, dann geht es wieder eine Weile.

Übergangsweise behelfe ich mir derzeit mit einem stündlichen Restart des Tunnels, aber auf Dauer ist das keine Lösung. Im Internet finden sich viele Beschreibungen des Problems, aber keine wirkliche Lösung. Kennt jemand hier Abhilfe? Ich müsste das ansonsten auf L2TP/IPsec umstellen, scheue aber den Aufwand...
 
Nachtrag: Gestern Abend Kabel gewechselt, lief bis heute ca. 11:00, seitdem wieder der selbe Mist :-( Und ich bin schon wieder nicht zu Hause diese Woche...
 
Ich kann leider quasi nicht nachvollziehen, unter welchen Umstaenden das genau zusammenbricht, ich muss mal einen laengeren trace mitlaufen lassen. Die MTU ist mit
Code: 
tun-mtu 1440
fragment 1400
mssfix
in der Config passend gesetzt, oder?

Ob TCP geht, muss ich mal mit dem Provider klaeren bzw. einfach mal testen, mache ich heute Abend mal.
 
Hi,
Kannst du mal bitte die OpenVPN Konfiguration zeigen und auch Angaben zur Hardware? Schau dir die folgenden Werte mal genau an und erhöhe sie mal zum testen:
net.inet.udp.recvspace
net.inet.udp.sendspace
Zum Vergrößern anklicken....
Gruss
 
Hmm, das
No buffer space available
klemmt eher im kernel (mbuf), welche NIC steckt denn "drunter"?

Monitor doch mal 'netstat -m' ueber die Zeit.
 
foxit schrieb:
Hi,
Kannst du mal bitte die OpenVPN Konfiguration zeigen und auch Angaben zur Hardware?
Zum Vergrößern anklicken....
Das ganze läuft auf einer apu2c4 unter OpenBSD 6.0, die NICs sind also Intel i210AT.

OpenVPN wird ganz normal via /etc/hostname.tun0 gestartet:
Code: 
up
!/usr/local/sbin/openvpn --daemon --config /etc/openvpn/portunity.conf

Hier noch die OpenVPN-config:
Code: 
client
dev tun
proto udp
tun-mtu 1440
fragment 1400
mssfix

remote <remote-endpoint> 1194

auth-retry interact
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/portunity/ca.crt
tls-auth /etc/openvpn/portunity/ta.key 1
ns-cert-type server

keepalive 10 60

# Debug Level
verb 3
tun-ipv6

auth-user-pass /etc/openvpn/portunity.login

redirect-gateway def1

user _openvpn
group _openvpn

script-security 2
up "/etc/openvpn/portunity/ifup.sh"

Das *up* script macht nix anderes, als eine IPv6-Route zu setzen:
Code: 
#!/bin/sh
/sbin/route add -inet6 default fe80::%tun0

FWIW hier noch die relevanten Teile des pf.conf:
Code: 
set reassemble yes
set block-policy return
set loginterface egress
set skip on lo
if_int="em0"
if_vpn="tun0"
icmp_types = "{ 0, 8, 3, 4, 11, 30 }"
match in all scrub (no-df random-id)
block in quick log from urpf-failed label uRPF
block all
pass in on $if_int inet proto udp from <vpn endpoint> port 1194
pass in on $if_vpn inet proto icmp from any to ($if_vpn) icmp-type $icmp_types
pass in on $if_vpn inet6 proto icmp6 from any to ($if_vpn)
pass out quick

Momentan habe ich wieder den "restart hourly" workaround am Laufen, aber das ist ja irgendwie kein Dauerzustand...

Nachtrag: Ach so: TCP geht nicht, da kriege ich keine Verbindung.

Nachtrag2: Vor der APU sitzt dann die Fritz!Box am VDSL.
 
thorwin schrieb:
Nachtrag: Ach so: TCP geht nicht, da kriege ich keine Verbindung.
Zum Vergrößern anklicken....
Ich gehe zwar davon aus, dass dir das klar ist, aber manchmal ist der Teufel eine fehlerhafte NAT-Konfiguration... Wenn du auf TCP umstellst (was ich persönlich nicht dauerhaft nutzen wollte), musst du natürlich am Router auch auf dem Port 1194 TCP durchlassen und sowohl an der Server als auch an der Clientconfig ebenfalls auf TCP umstellen. Deine aktuelle pf lässt nur udp durch.

Auffallend finde ich ebenfalls, dass dir sowohl "cert" als auch "key" in deiner Config fehlen. Trägt zwar auch nicht zur Sache bei, ich würde aber noch "comp-lzo" aktivieren.

Warum setzt du folgendes? Läuft es ohne?
tun-mtu 1440
fragment 1400
mssfix
Zum Vergrößern anklicken....
 
Moin Columbo0815,

Columbo0815 schrieb:
Ich gehe zwar davon aus, dass dir das klar ist, aber manchmal ist der Teufel eine fehlerhafte NAT-Konfiguration... Wenn du auf TCP umstellst (was ich persönlich nicht dauerhaft nutzen wollte), musst du natürlich am Router auch auf dem Port 1194 TCP durchlassen und sowohl an der Server als auch an der Clientconfig ebenfalls auf TCP umstellen. Deine aktuelle pf lässt nur udp durch.
Zum Vergrößern anklicken....
An der NAT-Konfiguration selbst kann ich derzeit nicht viel ändern, das macht die Fritz!BOX. Ich habe zwar schon ein VDSL-Modem hier liegen um Fritz!BOX abzulösen, aber das ist noch ne ganz andere Baustelle (ich sage nur IPTV, QoS und Multicast :ugly: ) Und Port 1194/tcp ist beim Provider einfach nicht erreichbar, das finale "pass out quick" lässt mich das durchaus auch mit obiger pf.conf testen.

Columbo0815 schrieb:
Auffallend finde ich ebenfalls, dass dir sowohl "cert" als auch "key" in deiner Config fehlen. Trägt zwar auch nicht zur Sache bei, ich würde aber noch "comp-lzo" aktivieren.
Zum Vergrößern anklicken....
Hmm, die Konfig hat der Provider so zur Verfügung gestellt und sie läuft (zumindest grundsätzlich). So wie ich es verstehe, sorgt "tls-auth" trotzdem dafür, dass ich der Verbindung vertrauen kann. Sollte aber alles für mein Problem egal sein. comp-lzo werde ich einfach mal einbauen.

Columbo0815 schrieb:
Warum setzt du folgendes? Läuft es ohne?
Zum Vergrößern anklicken....
Wie gesagt, die Konfig hat der Provider so vorgegeben, ich nehme es zum Testen mal raus.

Habe mittlerweile auch noch "max-mss 1440" in die "scrub"-Zeile bei pf.conf reingenommen, hätte eigentlich da sein sollen, habe ich wohl vergessen. Dürfte hier aber auch auch keinen Unterschied machen.
 
thorwin schrieb:
An der NAT-Konfiguration selbst kann ich derzeit nicht viel ändern, das macht die Fritz!BOX. Ich habe zwar schon ein VDSL-Modem hier liegen um Fritz!BOX abzulösen, aber das ist noch ne ganz andere Baustelle (ich sage nur IPTV, QoS und Multicast :ugly: ) Und Port 1194/tcp ist beim Provider einfach nicht erreichbar, das finale "pass out quick" lässt mich das durchaus auch mit obiger pf.conf testen.
Zum Vergrößern anklicken....
Ok, mir war nicht klar, dass du den OpenVPN-Server nicht selbst betreibst. Dann bringt es natürlich nichts, wenn du testweise tcp nutzt. Aber wie gesagt.. Ich würde hier ohnehin udp vorziehen.

Hmm, die Konfig hat der Provider so zur Verfügung gestellt und sie läuft (zumindest grundsätzlich). So wie ich es verstehe, sorgt "tls-auth" trotzdem dafür, dass ich der Verbindung vertrauen kann. Sollte aber alles für mein Problem egal sein. comp-lzo werde ich einfach mal einbauen.
Zum Vergrößern anklicken....
comp-lzo bringt nur etwas, wenn es auch auf dem Server konfiguriert ist.
 
Oh Mann, manchmal kannes so einfach sein...

Es scheint daran gelegen zu haben, dass auf dem Rechner ein lokaler unbound als Caching Resolver läuft, der, wenn der Tunnel zusammenbricht, schlicht die Adresse des Peers nicht mehr auflösen kann :grumble:

Seit ich den Peer einfach in die /etc/hosts eingetragen habe, läuft es stabil...

Dank euch für die Tipps, aber es war wohl ein klassicher Fall von PEBKAC
 
Code: 
<connection>
remote <remote-endpoint-HOSTNAME> 1194 udp
</connection>

<connection>
remote <remote-endpoint-IPADDRESS> 1194 udp
</connection>

mit diesem Konstrukt wird openvpn die möglichen Server von oben nach unten durchprobieren, bis ein Aufbau möglich ist.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben