IPCop Update auf 1.4.21 macht OpenVPN unbenutzbar

[fsch]

Nach dem Update auf IPCop 1.4.21 kann man trotz erfolgreichen Verbindungsaufbaus keine Daten via OpenVPN mehr austauschen:

• Kein Ping:

ping 10.16.1.1
PING 10.16.1.1 (10.16.1.1) 56(84) bytes of data.

From 172.16.18.1 icmp_seq=1 Destination Port Unreachable
From 172.16.18.1 icmp_seq=2 Destination Port Unreachable

• Keine Mounts:

mount error 111 = Connection refused
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)

Reproduziert am AEG Reutlingen und in der VM-Schulungsumgebung.

[fsch]

Weitere Erkenntnisse:

• Manueller Reinstall von zerina-0.9.5 behebt das Problem nicht im Update-Modus
• Wenn man zerina-0.9.5 erst installiert, dann deinstalliert rebootet, neu installiert und dann von Hand konfiguriert gehts wieder - Wie kann ich dabei meine Zertifikate behalten?
• Ein direktes Update auf zerina-0.9.7a14 behebt das Problem (nach Anpassung des install Skripts)

[fsch]

Das Problem tritt erst nach dem empfohlenen Reboot auf, aber auch wenn man den alten Kernel bootet.

[fsch]

Ein direktes Update auf zerina-0.9.7a14 behebt das Problem (nach Anpassung des install Skripts):

• Getestet: Neues Zertifikat herunterladen in SK
• Freischalten des Zertifikats im COP
• linuxmuster --deactivate/--activate/--show/--create/--purge

Fazit: Sieht nicht schlecht aus, evtl. ist es am einfachsten auf zerina 0.9.7a14 upzudaten - am AEG hab ich das der Not gehorchend jetzt einfach mal gemacht.

[tschmitt]

Konnte das heute auch nachvollziehen. Seltsam nur, dass Zerina im IPCop-Forum als zu 1.4.21 kompatibel gemeldet wird. ->  http://www.ipcop-forum.de/forum/viewtopic.php?f=28&t=21806
Abgesehen von dem log.dat-Bug (wird vom IPCop-Update überschrieben). Aber dafür gibts einen Workaround.

Komme vor Freitag nicht dazu mir das genauer anzuschauen.

Sehr ungern würde ich auf die Alpha-Version von Zerina ausweichen.

[tschmitt]

Paket liegt jetzt in unstable.

[tschmitt]

Fehler gefunden: geänderte Reihenfolge der Regeln in rc.firewall.local.

Das BOT-Update schiebt seine Regeln wieder an den Anfang. Das ist schlecht für OpenVPN. Dessen Regeln müssen zuerst angelegt werden.
Unter "start" muss /etc/rc.d/rc.firewall.local so aussehen, damit OpenVPN wieder funktioniert:

case "$1" in
  start)
	## add your 'start' rules here
	#Added for zerina start - BEGIN
	/usr/local/bin/openvpnctrl --create-chains-and-rules
	#Added for zerina start - END
	#linuxmuster: Added for automatically root certificate creation start - BEGIN
	[ -f /var/ipcop/ovpn/ca/dh1024.pem ] || /var/linuxmuster/create-ovpn-certs
	#linuxmuster: Added for automatically root certificate creation start - END
	#linuxmuster: Added for transp. advproxy on tun0 start - BEGIN
	/sbin/iptables -t nat -A CUSTOMPREROUTING -p tcp -i tun0 --dport 80 -j REDIRECT --to 800
	#linuxmuster: Added for transp. advproxy on tun0 start - END
	#Added for BlockOutTraffic start - BEGIN
	/sbin/iptables -N BOT_INPUT
	/sbin/iptables -N BOT_FORWARD
	/sbin/iptables -A CUSTOMINPUT -j BOT_INPUT
	/sbin/iptables -A CUSTOMFORWARD -j BOT_FORWARD
	/usr/local/bin/setfwrules
	#Added for BlockOutTraffic start - END
        ;;

Nach der Änderung muss der IPCop leider rebootet werden.

[tschmitt]

BTW, habe hier  http://lml.linuxmuster.net/trac/ticket/14 darauf hingewiesen, dass BOT beim Upgrade seine Regeln an den Anfang schiebt.

[tschmitt]

Siehe IPCop_1.14.21-paedml2_in_unstable