Hallo auf der Basis von SuSE 7.0 (Kernel 2.2.16) haben ich einen Router konfiguriert. Die Einwahl aus dem LAN funktioniert auch. Leider tritt das in diversen SDB Dokumenten beschriebene Problem mit den dynamisch vergebenen IP-Adressen des Providers auf. Die Variable IP_DYNIP habe ich in der rc.config auf 'YES' gesetzt und den Eintrag im /proc Filesystem kontrolliert. In '/var/log/messages' kann ich jedoch keine Eintraege die 'ip_rewrite_addrs' lauten finden und das Laden einer Webseite funktioniert erst nach einem Reload. Falls es hilft hier noch ein Auszug aus der /var/log/messages: kernel: ippp0: dialing 1 00191011... isdnlog: Mar 30 08:20:42 * tei 71 calling +1 91011, USA, with +49 7123/2, Metzingen RING (Datenuebertragung (64 kBit/s oder V.110)) isdnlog: Mar 30 08:20:42 tei 71 calling +1 91011, USA, with +49 7123/2, Metzingen UNKNOWN ELEMENT 25: 41 6d 74 20 20 32 [Amt 2], le isdnlog: Mar 30 08:20:44 tei 71 calling +1 91011, USA, with +49 7123/2, Metzingen UNKNOWN ELEMENT 25: 41 6d 74 20 20 32 [Amt 2], le isdnlog: Mar 30 08:20:44 tei 71 calling +1 91011, USA, with +49 7123/2, Metzingen RING (Datenuebertragung (64 kBit/s oder V.110)) isdnlog: Mar 30 08:20:44 tei 71 calling +1 91011, USA, with +49 7123/2, Metzingen Time:Fri Mar 30 09:16:01 2001 isdnlog: Mar 30 08:20:44 tei 71 calling +1 91011, USA, with +49 7123/2, Metzingen CONNECT isdnlog: Mar 30 08:20:44 tei 71 calling +1 91011, USA, with +49 7123/2, Metzingen CHARGE: 0.480 DM/60s = 0.480 DM/Min (DTAG ISDN, We isdnlog: Mar 30 08:20:44 tei 71 calling +1 91011, USA, with +49 7123/2, Metzingen HINT: Better use 01013:Tele 2 Privatkunden, 0.100 isdnlog: Mar 30 08:20:44 tei 71 calling +1 91011, USA, with +49 7123/2, Metzingen 1.CI 0.480 DM (now) isdnlog: Mar 30 08:20:44 tei 71 calling +1 91011, USA, with +49 7123/2, Metzingen NEXT CI AFTER 01:00 (DTAG ISDN, Welt 1, täglich) ipppd[193]: Local number: 2, Remote number: 00191011, Type: outgoing ipppd[193]: PHASE_WAIT -> PHASE_ESTABLISHED, ifunit: 0, linkunit: 0, fd: 7 ipppd[193]: sent [0][LCP ConfReq id=0x1 <mru 1524> <magic 0x7ec84e47>] kernel: isdn_net: ippp0 connected ipppd[193]: rcvd [0][LCP ConfReq id=0x1 <mru 1524> <auth pap> <MPmrru 0x5f4> <MPdiscr: 0x1 [ 73 74 61 63 6b 69 6e 67 ]>] ipppd[193]: sent [0][LCP ConfRej id=0x1 <MPmrru 0x5f4>] ipppd[193]: rcvd [0][LCP ConfAck id=0x1 <mru 1524> <magic 0x7ec84e47>] ipppd[193]: rcvd [0][LCP ConfReq id=0x2 <mru 1524> <auth pap> <MPdiscr: 0x1 [ 73 74 61 63 6b 69 6e 67 ]>] ipppd[193]: sent [0][LCP ConfAck id=0x2 <mru 1524> <auth pap> <MPdiscr: 0x1 [ 73 74 61 63 6b 69 6e 67 ]>] ipppd[193]: lcp layer is UP ipppd[193]: sent [0][PAP AuthReq id=0x6c user="[Ist o.k.]" password not logged for security reasons! Use '+pwlog' opt ipppd[193]: rcvd [0][PAP AuthAck id=0x6cmsg=""] ipppd[193]: Remote message: ipppd[193]: MPPP negotiation, He: No We: No ipppd[193]: sent [0][IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>] ipppd[193]: rcvd [0][IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 62.225.245.133>] ipppd[193]: sent [0][IPCP ConfRej id=0x1 <compress VJ 0f 01>] ipppd[193]: rcvd [0][IPCP ConfNak id=0x1 <addr 217.0.92.168> <ms-dns1 193.158.141.116> <ms-dns2 194.25.2.129>] ipppd[193]: sent [0][IPCP ConfReq id=0x2 <addr 217.0.92.168> <ms-dns1 193.158.141.116> <ms-dns2 194.25.2.129>] ipppd[193]: rcvd [0][IPCP ConfReq id=0x2 <addr 62.225.245.133>] ipppd[193]: sent [0][IPCP ConfAck id=0x2 <addr 62.225.245.133>] ipppd[193]: rcvd [0][IPCP ConfAck id=0x2 <addr 217.0.92.168> <ms-dns1 193.158.141.116> <ms-dns2 194.25.2.129>] ipppd[193]: local IP address 217.0.92.168 ipppd[193]: remote IP address 62.225.245.133 ip-up: Modified /etc/resolv.conf for DNS at ippp0 SuSEfirewall: Firewall rules successfully set. Das aller erstaunlichste ist, daß es ab und zu doch funktioniert. Und zwar nur von einer LINUX-Box (nicht von NT-Rechnern) aus. Ich habe beobachtet, daß dann vor der SuSEfirewall-Zeile folgende Zeile auftaucht: kernel: IP_MASQ:ip_fw_masquerade(): change masq.addr from 192.168.0.99 to 217.0.94.205 Soll das ein Ersatz fuer die 'ip_rewrite_addrs' Zeile sein ? Unterbreche ich die Verbindung mit 'isdnctrl hangup ippp0' und versuche erneut eine WWW-Seite zu laden erscheint obige Zeile nicht mehr und die Seite wird auch nicht geladen. Von NT-Rechnern funktioniert das Ganze nie unabhaengig von der obigen Meldung. Im übrigen verwende ich folgendes Firewall-Script: #!/bin/sh EXTIF=ippp+ ANY=0.0.0.0/0 LAN=192.168.1.0/10 # Masquerading Module /sbin/modprobe ip_masq_ftp /sbin/modprobe ip_masq_irc /sbin/modprobe ip_masq_raudio # kein IP spoofing if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ] ; then for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $i done fi # SYN Flood protection if [ -e /proc/sys/net/ipv4/tcp_syncookies ] ; then echo 1 > /proc/sys/net/ipv4/tcp_syncookies fi # Disable Source Routed Packets for i in /proc/sys/net/ipv4/conf/*/accept_source_route; do echo 0 > $i done # enable forwarding echo 1 > /proc/sys/net/ipv4/ip_forward # IPCHAINS /sbin/ipchains -F forward /sbin/ipchains -F input /sbin/ipchains -F output /sbin/ipchains -P input ACCEPT /sbin/ipchains -P output ACCEPT /sbin/ipchains -P forward DENY # keine ankommenden Verbindungen von aussen /sbin/ipchains -A input -l -i $EXTIF -p TCP -y -j DENY # Deny TCP and UDP packets to privileged ports /sbin/ipchains -A input -l -i $EXTIF -d $ANY 0:1023 -p udp -j DENY /sbin/ipchains -A input -l -i $EXTIF -d $ANY 0:1023 -p tcp -j DENY # Masquerading /sbin/ipchains -A forward -s $LAN -j MASQ O.k. ich weiss das klingt zwar alles sehr dubios aber vielleicht kann mir ja trotzdem jemand helfen. -- mfg Harry Hinderer mailto:harry.hinderer@gmx.de