SuSEfirewall2 - Fehler beim Zugriff auf eigenen Server über symbolischen Namen

[ironarrow]

Hallo,

ich habe ein Problem mit der SuSEfirewall2.

Ich habe hier einen Server mit SuSE 9.0 laufen (ist Gateway bzw. Router für das interne Netzwerk). Dieser wählt sich per DSL ins Internet und meldet bei no-ip.com seine neue IP-Adresse. Damit bin über den symbolischen Namen von außerhalb (also aus dem Internet) erreichbar.

So weit so gut.

Gebe ich nun von einem internen PC den symbolischen Namen im IE oder anderen Web-Browser ein, dann passiert nichts. Ich gelange nicht auf die Seiten auf meinem Server. (von außerhalb klappt es aber). Gebe ich statt des symbolischen Namens die interne IP-Adresse des Servers ein (192.168.1.1), dann komme ich auf die Seiten.

starte ich /sbin/SuSEfirewall2 test, dann kann ich auch von den internen PCs den symbolischen Namen aufrufen.

eth0 : internes Netzwerk 192.168.1.1
eth1: verbunden mit DSL-Modem 10.0.0.1
ppp0: DSL-Modem

Ich habe lediglich den Apache, ProFTP, Samba und den SSH-Dienst laufen. Samba soll nur vom internen Netz erreichbar sein, die anderen drei Dienste auch von extern.

Ich hoffe, Ihr könnt mir helfen.

Gruß,

Rainer

Könnt mich auch unter rainer.stuelp@gsd-kerpen.de erreichen.

Hier mal meine /etc/sysconfig/SuSEfirewall2

FW_QUICKMODE="no"
FW_DEV_EXT="ppp0"
FW_DEV_INT="eth0"
FW_DEV_DMZ=""
FW_ROUTE="yes"
FW_MASQUERADE="yes"
FW_MASQ_DEV="$FW_DEV_EXT"
FW_MASQ_NETS="0/0"
FW_PROTECT_FROM_INTERNAL="no"
FW_AUTOPROTECT_SERVICES="yes"
FW_SERVICES_EXT_TCP="20:22 80 443"
FW_SERVICES_EXT_UDP="20:22 80 443"
FW_SERVICES_EXT_IP=""
FW_SERVICES_DMZ_TCP=""
FW_SERVICES_DMZ_UDP=""
FW_SERVICES_DMZ_IP=""
FW_SERVICES_INT_TCP=""
FW_SERVICES_INT_UDP=""
FW_SERVICES_INT_IP=""
FW_SERVICES_QUICK_TCP=""
FW_SERVICES_QUICK_UDP=""
FW_SERVICES_QUICK_IP=""
FW_TRUSTED_NETS="192.168.1.0/255.255.255.0"
FW_ALLOW_INCOMING_HIGHPORTS_TCP="yes"
FW_ALLOW_INCOMING_HIGHPORTS_UDP="DNS"
FW_SERVICE_AUTODETECT="yes"
FW_SERVICE_DNS="no"
FW_SERVICE_DHCLIENT="no"
FW_SERVICE_DHCPD="no"
FW_SERVICE_SQUID="no"
FW_SERVICE_SAMBA="yes"
FW_FORWARD=""
FW_FORWARD_MASQ=""
FW_REDIRECT=""
FW_LOG_DROP_CRIT="yes"
FW_LOG_DROP_ALL="no"
FW_LOG_ACCEPT_CRIT="yes"
FW_LOG_ACCEPT_ALL="no"
FW_LOG="--log-level warning --log-tcp-options --log-ip-option --log-prefix SuSE-FW"
FW_KERNEL_SECURITY="yes"
FW_STOP_KEEP_ROUTING_STATE="no"
FW_ALLOW_PING_FW="no"
FW_ALLOW_PING_DMZ="no"
FW_ALLOW_PING_EXT="no"

FW_ALLOW_FW_TRACEROUTE="no"
FW_ALLOW_FW_SOURCEQUENCH="yes"
FW_ALLOW_FW_BROADCAST="no"
FW_IGNORE_FW_BROADCAST="yes"
FW_ALLOW_CLASS_ROUTING="no"
FW_CUSTOMRULES=""
FW_REJECT="no"
FW_HTB_TUNE_DEV=""

[Rat]

Das ist erstmal ein DNS Problem und hat IMHO nichts mit der Firewall zu tun. Andersrum wäre es was anderes.

Welchen DNS Server hast Du bei Deinen internen Kisten eingetragen? Das sollte in der Regel, in Deinem Falle, der Gateway/Router sein.

Hier musst Du dem DNS-Cache diese IP mit geben, die Du auf non-ip einträgst, dann sollte es gegen. Was sagt denn ein traceroute?

Gruß
Jürgen

[ironarrow]

Ich glaube nicht, dass es am DNS-Server liegt. Die internen PCs haben den gleichen (externen) DNS-Server eingetragen, wie der Server selbst. Die IP wird auch richtig aufgelöst.

Ich habe die Firewall noch mal auf Testbetrieb geschaltet und mir dir /var/log/messages angeschaut. Dort habe ich dann folgenden Eintrag gefunden:

Code: Select all

Nov 12 09:27:02 server kernel: SuSE-FW-ACCESS_DENIED_INT IN=eth0 OUT= MAC=00:04:76:10:98:7a:00:0d:61:c6:6b:c7:08:00 SRC=192.168.1.12 DST=_MEINE_T_ONLINE_IP LEN=48 TOS=0x08 PREC=0x00 TTL=128 ID=49409 DF PROTO=TCP SPT=1886 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B401010402) 

Ich müßte wohl lediglich der Firewall sagen, dass die Zugriffe über eth0 auf die T-Online-IP zugelassen werden sollen. Jedoch weiß ich nicht, wo ich das einzutragen habe bzw. wie der Befehl lautet

Gruß,

Rainer

[RAT]

Das Suse Firewall Script ist IMHO ganz schön undurchsichtig.
Eine gute Einführung gibt es hier:
http://www.teamunix.de/howto/iptableshowto.php

Der Befehl wäre in etwa:
iptables -A INPUT -d =_MEINE_T_ONLINE_IP -s 192.168.1.12 -j ACCEPT

Sofern es die Tabelle INPUT gibt.
Aber das kannst Du dann prüfen, wenn Du iptables beendest und neu startest.

[ironarrow]

Danke, werde es die nächsten Tage ausprobieren.

Gruß,

Rainer