• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Problem mit OpenVPN, bzw. eher mit SuSEfirewall2

Also ich habe nen Debian Server, auf dem ich (mit alien und manueller "Pfuscherei" = Pfadanpassung) eine SuSEfirewall2 draufgekloppt habe, da ich von SuSE 9.2 umgestiegen bin und das Masquerading und Firewalling innerhalb kurzer Zeit wieder luppen sollte.
Das klappt jetzt auch schon seit ca. nem Jahr und aus der Quick'n'Dirty Lösung ist natürlich immer noch nix Eleganteres geworden :roll:

Mittlerweile habe ich einen OpenVPN Server aufgesetzt. Einwahl von einem anderen Standort übers Internet funktioniert - auch mehrere gleichzeitig mit unterschiedlichen unique Zertifikaten.
Kommunikation vom Clienten (Linux oder WinXP SP2) und zurück funktioniert.
Der Server ist aber mit einer Netzwerkbrücke (br0) konfiguriert, die das lokale LAN (eth0) und das OpenVPN Device (tap0) verbindet.
br0, tap0 und eth0 stehen in der SuSEfirewall2 als INT Device drin
der Prot 1194 (default nach IANA für OpenVPN) ist selbstverständlich an EXT offen, sonst würd ja gar nix gehen.

Nun zum Problem:
Ist die SuSEfirewall2 aus, kann ich vom client über die Brücke ins lokale LAN pingen (incl. Broadcast, Win Netzwerkumgebung etc.), ist sie eingeschaltet (was absolut notwendig ist, aus Sicherheitsgründen und dem Masquerading, das sie bereitstellt), werden die Pakete OpenVPN Client --> lokales LAN geblockt.

in /var/log/messages kommt folgende Fehlermeldung (bei "ping 192.168.0.60 vom OVPN Client ins LAN):
Mar 15 11:45:06 Router kernel: SFW2-FWDint-DROP-DEFLT IN=br0 OUT=br0 PHYSIN=tap0 PHYSOUT=eth0 SRC=192.168.0.201 DST=192.168.0.60 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=3 DF PROTO=ICMP TYPE=8 CODE=0 ID=37151 SEQ=4

Was könnte ich an der SuSEfirewall2 config änder müssen, um dieses Verhalten abzuschalten.
Da das VPN auf Zertifikaten basiert, die durch Passworte abgesichert sind und ich nur vertrauenswürdige Personen reinlasse, kann das tap0 ruhig "offen" bleiben ohne Schutz und soll sich transparent ins LAN einfügen.
 
OP
C

Commander1024

Newbie
Ok, vielleicht ist ein wenig mehr Info angebracht. Da das Problem ja offensichtlich nicht an OpenVPN, sondern an der Firewall liegt, spar ich mir die VPN Conf mal (es sei denn jemand braucht diese auch noch um das Problem zu analysieren) und beschränke mich auf /etc/sysconfig/SuSEfirewall2

Code:
FW_QUICKMODE="no"
FW_DEV_EXT="ppp0"
FW_DEV_INT="eth0 br0 tap0"
FW_DEV_DMZ=""
FW_ROUTE="yes"
FW_MASQUERADE="yes"
FW_MASQ_DEV="$FW_DEV_EXT"
FW_MASQ_NETS="0/0"
FW_PROTECT_FROM_INT="no"
FW_AUTOPROTECT_SERVICES="yes"
FW_SERVICES_EXT_TCP="3724 5100 6112 4662 5662 6662 6881:6882 8000 http ssh 12771"
FW_SERVICES_EXT_UDP="1194 12771 4672 5100 5672 6672 8767"

# Portnummer(n):        Dahinterstehende(r) Dienst(e):          ggf. Zielcomputer:
# 21,tcp (ftp)          ProFTPD (xampp)
# 22,tcp (ssh)          OpenSSHD
# 80,tcp (http)         Apache2 (xampp)
# 1723, tcp (vpn)       PPTP VPN Server
# 8000,tcp              Icecast
# 3724,tcp              Blizzard Downloader                     Commander
# 4662,tcp 4672,udp     eMule                                   Martin
# 5662,tcp 5672,udp     eMule                                   Ines
# 6662,tcp 6672,udp     eMule                                   Commander
# 12771,udp             Skype                                   Commander
# 14534,tcp 8767,udp    TeamSpeak2 RC2
# 27030:27039,tcp 27000:27015,udp 1200,udp   HLDS/SRCDS (CS1.6/CSS)
# 7999,tcp
# 6112,tcp              BitTorrent
# 27960:27972,udp,tcp
# 13327,tcp
# 5100,tcp,udp                  Yahoo Supercam Modus                    Ines
# 1194,udp              OpenVPN

FW_SERVICES_EXT_IP=""
FW_SERVICES_EXT_RPC=""
FW_SERVICES_DMZ_TCP=""
FW_SERVICES_DMZ_UDP=""
FW_SERVICES_DMZ_IP=""
FW_SERVICES_DMZ_RPC=""
FW_SERVICES_INT_TCP=""
FW_SERVICES_INT_UDP=""
FW_SERVICES_INT_IP=""
FW_SERVICES_INT_RPC=""
FW_SERVICES_QUICK_TCP=""
FW_SERVICES_QUICK_UDP=""
FW_SERVICES_QUICK_IP=""
FW_TRUSTED_NETS=""
FW_ALLOW_INCOMING_HIGHPORTS_TCP="no"
FW_ALLOW_INCOMING_HIGHPORTS_UDP="no"
FW_SERVICE_AUTODETECT="yes"
FW_SERVICE_DNS="yes"
FW_SERVICE_DHCLIENT="no"
FW_SERVICE_DHCPD="yes"
FW_SERVICE_SQUID="yes"
FW_SERVICE_SAMBA="yes"
FW_FORWARD=""
FW_FORWARD_MASQ="0/0,192.168.0.3,tcp,6662 0/0,192.168.0.40,tcp,4662 0/0,192.168.0.3,udp,6672 0/0,192.168.0.2,tcp,5662 0/0,192.168.0.2,udp,5672 0/0,192.168.0.40,udp,4672 0/0,192.168.0.3,tcp,12771 0/0,192.168.0.3,udp,12771 0/0,192.168.0.3,tcp,3724 0/0,192.168.0.2,tcp,5100 0/0,192.168.0.2,udp,5100"
FW_REDIRECT=""
FW_LOG_DROP_CRIT="yes"
FW_LOG_DROP_ALL="yes"
FW_LOG_ACCEPT_CRIT="no"
FW_LOG_ACCEPT_ALL="no"
FW_KERNEL_SECURITY="yes"
FW_ANTISPOOF="no"
FW_STOP_KEEP_ROUTING_STATE="no"
FW_ALLOW_PING_FW="yes"
FW_ALLOW_PING_DMZ="no"
FW_ALLOW_PING_EXT="no"
FW_ALLOW_FW_TRACEROUTE="yes"
FW_ALLOW_FW_SOURCEQUENCH="yes"
FW_ALLOW_FW_BROADCAST_INT="int"
FW_IGNORE_FW_BROADCAST="no"
FW_ALLOW_CLASS_ROUTING="no"
FW_CUSTOMRULES=""
FW_REJECT="no"
FW_HTB_TUNE_DEV="ppp0,570"
FW_IPv6="drop"
FW_IPv6_REJECT_OUTGOING="yes"
FW_IPSEC_TRUST="no"
FW_LOG=""
FW_SERVICES_DROP_EXT=""
FW_SERVICES_REJECT_EXT="0/0,tcp,113"
FW_LOG_LIMIT=""
 

buho

Newbie
Ich hatte grad vorhin dasselbe Problem. Die Lösung ist, im SuSEfirewall2 config "/etc/sysconfig/SuSEfirewall2" die Option

FW_ALLOW_CLASS_ROUTING="yes"

auf "yes" setzen, damit SuSEfirewall2 Packete zwischen Interfaces gleicher Klasse (INT, EXT, DMZ) austauschen kann.
In dem Fall zwischen eth0 und br0. Das "tap0" Interface muss nicht zwingend unter "FW_DEV_INT" angegeben werden.
Es reicht auch FW_DEV_INT="eth0 br0".

so.. dies zur Vollständigkeit. Wünsche allgemein gutes Gelingen
dr.Buho
 
Oben