Hi Leute, ich habe es endlich geschafft, Masquerding einzurichten. Firewall sollte eigentlich deaktiviert sein, scheint aber doch zu funtzen ?! weil ich bekomme von außen keinen Zugriff auf Telnet. Ich komme auf JEDE Seite im WWW. Jedoch auf www.gmx.de kann ich net zugreifen. Weiß jemand von euch, wodran das liegt ??? Ich habe einen Kumpel gefragt, der kommt drauf. mfG Owen
Hallo Owen, Du schmeißt ziemlich viele Sachen durcheinander. Also: a) Mach die Firewall an, wenn Du ins Internet gehst, ansonsten ist diese fast sinnlos. b) Telnet mußt Du über inetd.conf und hosts.allow explizit anbieten und konfigurieren... c) Benutzt Du DSL? Stell mal mit ipconfig die MTU auf 1452 oder benutzte das Module mssclampfw. Die MTU stellst Du mit "ifconfig eth0 mtu 1452", Informationen sollte die Supportdatenbank unter sdb.suse.de liefern. Siehe auch http://sdb.suse.de/de/sdb/html/hoe_adsl_router.html Gruß Sebastian www.wolfgarten.com
Hallo Freaks, hat jemand aus dieser Liste Erfahrungen mit Fidonet (Mailer, Tosser, Areafix etc.) unter Suse-Linux? Gruss Eduard www.ninabbs.de www.was-ist-fido.de
Hallo, at Friday 30.11.2001 (23:21 +0100), Eduard Reiter wrote:
hat jemand aus dieser Liste Erfahrungen mit Fidonet
Man, das ist jetzt ca. 12 Jahre her, wo ich meine eigene Mailbox, mit selbst gestricktem BBS-System, hatte. Hat das Fidonet überhaupt noch eine Überlebenschance in Zeiten von Internet ?? Gruß Michael -- Phone/Fax +49 7000 MACBYTE (+49 7000-6222983) Registered Linux User #228306 HomePage http://www.macbyte.info/ http://counter.li.org/ PGP-Key http://www.macbyte.info/shared/mykey.pkr ++ CGI-Hosting ++ Domains ++ Webspace ++ PHP Development ++
Hallo Michael,
Man, das ist jetzt ca. 12 Jahre her, wo ich meine eigene Mailbox, mit selbst gestricktem BBS-System, hatte. Hat das Fidonet überhaupt noch eine Überlebenschance in Zeiten von Internet ??
Aber sicher. Läuft hier seit 3 Jahren mit knapp 30 Points. Mailaufkommen stagniert, Node- und Pointzahlen gehen zurück, aber es gibt immer noch einige verbissene (ich zähle mich dazu), die sich an dieser veralteten Technik festklammern :-)) Ausserdem könnte ich ohne meine knapp 14 k Batchzeilen garnicht leben :-) Gruss Eduard www.ninabbs.de www.was-ist-fido.de
Hallo, Am Freitag, 30. November 2001 23:21, schrieb Eduard Reiter :
Hallo Freaks,
hat jemand aus dieser Liste Erfahrungen mit Fidonet (Mailer, Tosser, Areafix etc.) unter Suse-Linux? Willst Du als Node oder Point teilnehmen? Als Point kannst Du Terminate unter Dosemu gut nutzen. Ansonsten ist wohl auf den SuSE-Cds ein Progamm als reines Linuxprogramm. Such mal nach Fido.
-- Mit den besten Wünschen Thomas Burgau
Hallo Thomas, Thomas Burgau wrote on Samstag, 1. Dezember 2001 09:35 about Re: Fidonet unter Linux:
hat jemand aus dieser Liste Erfahrungen mit Fidonet (Mailer, Tosser, Areafix etc.) unter Suse-Linux?
Willst Du als Node oder Point teilnehmen? Als Point kannst Du Terminate unter Dosemu gut nutzen. Ansonsten ist wohl auf den SuSE-Cds ein Progamm als reines Linuxprogramm. Such mal nach Fido.
Ich fahre seit zwei Jahren meine Fido-Box in der dosemu; allerdings gibt es zuletzt (SuSE 7.2, Kernel 2.4.x) zunehmend Probleme mit der Datenübertragung. Ich habe auch schonmal mit den dosemu Entwicklern Kontakt aufgenommen, aber da geht keiner an den seriellen Code ran. Mit meinem Mailer "Portal of Power" gibt es dabei noch deutlich geringere Probleme als mit Terminate, da ich ersteren sourcemäßig verändert habe. Mit dosemu 1.0.1 und Kernel 2.4.x ist die Situation viel schlechter geworden, insbesondere die Empfangsrichtung ergibt massenweise CRC-Fehler. Oder hast Du spezielle Einstellungen für die dosemu gefunden? Kannst Du mal deine dosemu Konfiguration posten? -- Gruss Marcus Marcus Roeckrath -- Vikarsbusch 8 -- D-48308 Senden -- Germany Phone : +49-2536-9944 -- Mailer/BBS/Fax : +49-2536-9943 (V34, X75) FidoNet: 2:2449/523 E-Mail : marcus.roeckrath@gmx.de WWW : http://home.foni.net/~marcusroeckrath/
Hallo Markus, Am Samstag, 1. Dezember 2001 10:43, schrieb Marcus Roeckrath :
Oder hast Du spezielle Einstellungen für die dosemu gefunden? Kannst Du mal deine dosemu Konfiguration posten?
Leider habe ich mich Anfang dieses Jahres vom Fido verabschiedet. Deshalb habe ich auch keine Config mehr zu bieten. Bis dahin hatte ich die Suse6.2 mit Kernel 2.2.13(?) laufen. Probleme mit der Übertragung hatte ich nicht, was aber auch an meinem 14.4er Modem gelegen haben kann. -- Mit den besten Wünschen Thomas Burgau
Am Freitag, 30. November 2001 23:21 schriebst Du:
Hallo Freaks,
hat jemand aus dieser Liste Erfahrungen mit Fidonet (Mailer, Tosser, Areafix etc.) unter Suse-Linux?
Gruss Eduard
Hallo, habe zwar keine Erfahrung mit Fido unter Linux ( habe Fido früher unter Win verwendet ), aber ich habe vor ein paar Tagen ein Howto gesehen: /usr/share/doc/howto/de/html/DE-Fido... hoffe, dass dir das evtl. hilft. Aye Markus
Am Freitag, 30. November 2001 23:10 schrieb Sebastian Wolfgarten:
c) Benutzt Du DSL? Stell mal mit ipconfig die MTU auf 1452 oder benutzte das Module mssclampfw. Die MTU stellst Du mit "ifconfig eth0 mtu 1452",
Na, jetzt aber keine falschen Tipps geben. Die Ethernet-mtu gehört in Ruhe gelassen und kann auf 1500 stehen bleiben. Die ppp-mtu ist auf 1492 zu setzen, wie hier schon hundertfach erwähnt.
Informationen sollte die Supportdatenbank unter sdb.suse.de liefern.
Das tut sie auch: http://sdb.suse.de/de/sdb/html/cg_pmtu2.html (weils offenbar zu viel Mühe macht). - Matthias -- LPI Level 1 Certified http://www.selflinux.de
Hi, jo stimmt die ppp0 MTU muß auf 1492 gesetzt werden, das genannte Beispiel mit eth0 war nur zu Demonstationszwecken. Gruß Sebastian
Saturday, December 01, 2001, 1:54:48 AM, Matthias Kleine wrote:
Na, jetzt aber keine falschen Tipps geben. Die Ethernet-mtu gehört in Ruhe gelassen und kann auf 1500 stehen bleiben. Die ppp-mtu ist auf 1492 zu setzen, wie hier schon hundertfach erwähnt.
Informationen sollte die Supportdatenbank unter sdb.suse.de liefern.
Das tut sie auch:
Nunja... ich habe das gleiche Problem, habe schon all diese Tipps aus der Datenbank in die Tat umgesetzt, aber geholfen hat es bisher nicht. mssclampfw brachte auch nicht den gewünschten Erfolg. Hat jemand für diesen Fall noch Ideen? System: Suse 7.1 mit 2.4.8er Kernel, ipchains. Jörg --- Samstag, 1. Dezember 2001 11:32 mailto:linux@vague.de http://www.vague.de
Am Samstag, 1. Dezember 2001 11:34 schrieb Jörg Nehls:
Nunja... ich habe das gleiche Problem, habe schon all diese Tipps aus der Datenbank in die Tat umgesetzt, aber geholfen hat es bisher nicht.
mssclampfw brachte auch nicht den gewünschten Erfolg. Hat jemand für diesen Fall noch Ideen?
"debug" Option im ppp/options setzen. Verbinden. Auszug der Verbindung aus /var/log/messages in die Liste posten. - Matthias -- LPI Level 1 Certified http://www.selflinux.de
Nunja... ich habe das gleiche Problem, habe schon all diese Tipps aus der Datenbank in die Tat umgesetzt, aber geholfen hat es bisher nicht.
mssclampfw brachte auch nicht den gewünschten Erfolg. Hat jemand für diesen Fall noch Ideen?
System: Suse 7.1 mit 2.4.8er Kernel, ipchains. ^^^^^^^^^^^^^^ 2.4 er Kernel? => iptables + SuSEfirewall2
Gruß Andreas _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Saturday, December 01, 2001, 1:40:41 PM, Andreas Bacher wrote:
System: Suse 7.1 mit 2.4.8er Kernel, ipchains. ^^^^^^^^^^^^^^ 2.4 er Kernel? => iptables + SuSEfirewall2
Ist das grundsätzlich oder nur, wenn ich DSL verwende? Bisher ging ja mein masq unter 2.4 mit ipchains und ISDN ganz wunderbar. Das installieren/konfigurieren der SuSEFW2 scheiterte bisher bzw. beim booten gibt es reichlich Fehlermeldungen: Starting Firewall Initialization: (phase 2 of 3) modprobe: modprobe: Can't locate module ippp2 modprobe: modprobe: Can't locate module ippp2 modprobe: modprobe: Can't locate module ippp2 modprobe: modprobe: Can't locate module ippp2 modprobe: modprobe: Can't locate module ppp0 modprobe: modprobe: Can't locate module ppp0 modprobe: modprobe: Can't locate module ppp0 modprobe: modprobe: Can't locate module ppp0 modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_REJECT modprobe: modprobe: Can't locate module ipt_REJECT modprobe: modprobe: Can't locate module ipt_REJECT modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module iptable_mangle modprobe: modprobe: Can't locate module ipt_state modprobe: modprobe: Can't locate module ipt_LOG modprobe: modprobe: Can't locate module ipt_TCPMSS done Wie gesagt handelt es sich beim Kernel um einen selbstgebauten 2.4.8er. Unter den Options von "IP: Netfilter Configuration" habe ich alles als Modul bauen lassen... Iptables verwende ich in der Version 1.2.2, welches ja auch zu der SuSEFW2 gehören soll. Hat jemand einen Tip für mich? Gruß, Jörg --- Samstag, 1. Dezember 2001 18:47 mailto:linux@vague.de http://www.vague.de
Am Samstag 01 Dezember 2001 18:50 schrieb Jörg Nehls:
Saturday, December 01, 2001, 1:40:41 PM, Andreas Bacher wrote:
System: Suse 7.1 mit 2.4.8er Kernel, ipchains.
^^^^^^^^^^^^^^ 2.4 er Kernel? => iptables + SuSEfirewall2
Ist das grundsätzlich oder nur, wenn ich DSL verwende? Bisher ging ja mein masq unter 2.4 mit ipchains und ISDN ganz wunderbar.
Ob iptables oder ipchains ist eine Frage der Konfiguration beim 2.4.x. Kernel. Kannst Du frei entscheiden, nur nicht beide gleichzeitig ;-) IIRC benutzt aber Susi FW 2 iptables (benutze ich nicht, kann ich also nicht mit Sicherheit behaupten). Welche Art Netzzugang Du hast, ist aber egal.
Das installieren/konfigurieren der SuSEFW2 scheiterte bisher bzw. beim booten gibt es reichlich Fehlermeldungen:
Starting Firewall Initialization: (phase 2 of 3) modprobe: modprobe: Can't locate module ippp2 modprobe: modprobe: Can't locate module ippp2 modprobe: modprobe: Can't locate module ippp2
[... ganz viele Can't locate Einträge umweltgercht entsorgt... ] Schau doch mal ob die Module wirklich nicht unterhalb von /lib/modules/<version>/ zu finden sind. Wenn sie dort nicht sind, dann ist beim Backen der Kernels was schiefgelaufen.
Wie gesagt handelt es sich beim Kernel um einen selbstgebauten 2.4.8er. Unter den Options von "IP: Netfilter Configuration" habe ich alles als Modul bauen lassen...
Das wäre ja dann ok!
Iptables verwende ich in der Version 1.2.2, welches ja auch zu der SuSEFW2 gehören soll.
Hat jemand einen Tip für mich?
Gruß, Jörg
Sunday, December 02, 2001, 1:39:09 PM, Arne-Erik Martin wrote:
Ist das grundsätzlich oder nur, wenn ich DSL verwende? Bisher ging ja mein masq unter 2.4 mit ipchains und ISDN ganz wunderbar.
Ob iptables oder ipchains ist eine Frage der Konfiguration beim 2.4.x. Kernel. Kannst Du frei entscheiden, nur nicht beide gleichzeitig ;-) IIRC benutzt aber Susi FW 2 iptables (benutze ich nicht, kann ich also nicht mit Sicherheit behaupten). Welche Art Netzzugang Du hast, ist aber egal. Gut... ich habe nun die FW1 runtergeschmissen und bin auf die FW2 umgestiegen... nach einigen Problemchen habe ich die FW allerdings in den Griff bekommen, so daß ich nun nur noch ein kleines Problem habe:
Wenn ich meine DSL Verbindung trenne, kann ich danach keine erneute Einwahl starten, der Verbindungsaufbau bleibt beim "Sending PADI" stehen. Ich vermute, daß es mit folgenden Eitnräge in var/log/messages etwas zu tun hat: --- Dec 3 13:02:00 saskia kernel: SuSE-FW-UNALLOWED-ROUTINGIN=eth0 OUT=ppp0 SRC=192.168.0.3 DST=168.122.208.93 LEN=48 TOS=0x00 PR EC=0x00 TTL=127 ID=2580 DF PROTO=TCP SPT=1798 DPT=1214 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B401010402) Dec 3 13:02:00 saskia kernel: SuSE-FW-UNALLOWED-ROUTINGIN=eth0 OUT=ppp0 SRC=192.168.0.3 DST=192.197.118.59 LEN=48 TOS=0x00 PR EC=0x00 TTL=127 ID=2836 DF PROTO=TCP SPT=1801 DPT=1214 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B401010402) --- Das sind nicht alle Einträge, die würden diese Mail nur unnötig gross machen. Die anderen haben aber die gleiche "Kernaussage".
Schau doch mal ob die Module wirklich nicht unterhalb von /lib/modules/<version>/ zu finden sind. Wenn sie dort nicht sind, dann ist beim Backen der Kernels was schiefgelaufen. Das war in der tat der fall. Warum das passiert ist, weiss ich auch nicht, schliesslich hatte ich das ganze mehrfach gechecked ;-)
Gruß, Jörg --- Sonntag, 2. Dezember 2001 13:51 mailto:linux@vague.de http://www.vague.de
Am Sonntag 02 Dezember 2001 13:55 schrieb Jörg Nehls:
Sunday, December 02, 2001, 1:39:09 PM, Arne-Erik Martin wrote:
Ist das grundsätzlich oder nur, wenn ich DSL verwende? Bisher ging ja mein masq unter 2.4 mit ipchains und ISDN ganz wunderbar.
Ob iptables oder ipchains ist eine Frage der Konfiguration beim 2.4.x. Kernel. Kannst Du frei entscheiden, nur nicht beide gleichzeitig ;-) IIRC benutzt aber Susi FW 2 iptables (benutze ich nicht, kann ich also nicht mit Sicherheit behaupten). Welche Art Netzzugang Du hast, ist aber egal.
Gut... ich habe nun die FW1 runtergeschmissen und bin auf die FW2 umgestiegen... nach einigen Problemchen habe ich die FW allerdings in den Griff bekommen, so daß ich nun nur noch ein kleines Problem habe:
Wenn ich meine DSL Verbindung trenne, kann ich danach keine erneute Einwahl starten, der Verbindungsaufbau bleibt beim "Sending PADI" stehen.
Hat man Dir die "Einweg-DSL" (einmal benutzen und dann wegwerfen ...) verkauft (SCNR) Aber im Ernst. Klappt es denn mit deaktivierter FW? Wenn ja, würde ich mal tippen, es liegt daran, das beim Verbindungsabbau die FW sich "verkonfiguriert".
Ich vermute, daß es mit folgenden Eitnräge in var/log/messages etwas zu tun hat:
--- Dec 3 13:02:00 saskia kernel: SuSE-FW-UNALLOWED-ROUTINGIN=eth0 OUT=ppp0 SRC=192.168.0.3 DST=168.122.208.93 LEN=48 TOS=0x00 PR EC=0x00 TTL=127 ID=2580 DF PROTO=TCP SPT=1798 DPT=1214 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B401010402) Dec 3 13:02:00 saskia kernel: SuSE-FW-UNALLOWED-ROUTINGIN=eth0 OUT=ppp0 SRC=192.168.0.3 DST=192.197.118.59 LEN=48 TOS=0x00 PR EC=0x00 TTL=127 ID=2836 DF PROTO=TCP SPT=1801 DPT=1214 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B401010402) ---
"unallowed routing" klingt wohl nach meinem Verdacht ... Also teste mal (aber nur kurz online bleiben!) ohne FW.
Das sind nicht alle Einträge, die würden diese Mail nur unnötig gross machen. Die anderen haben aber die gleiche "Kernaussage".
Schau doch mal ob die Module wirklich nicht unterhalb von /lib/modules/<version>/ zu finden sind. Wenn sie dort nicht sind, dann ist beim Backen der Kernels was schiefgelaufen.
Das war in der tat der fall. Warum das passiert ist, weiss ich auch nicht, schliesslich hatte ich das ganze mehrfach gechecked ;-)
Gruß, Jörg --- Sonntag, 2. Dezember 2001 13:51 mailto:linux@vague.de http://www.vague.de
Sunday, December 02, 2001, 6:56:17 PM, Arne-Erik Martin wrote:
Hat man Dir die "Einweg-DSL" (einmal benutzen und dann wegwerfen ...) verkauft (SCNR) Zuzutrauen ist der DTAG das ohne Wimperzucken ;-)
Aber im Ernst. Klappt es denn mit deaktivierter FW? Wenn ja, würde ich mal tippen, es liegt daran, das beim Verbindungsabbau die FW sich "verkonfiguriert". "unallowed routing" klingt wohl nach meinem Verdacht ... Also teste mal (aber nur kurz online bleiben!) ohne FW.
Das ist richtig. Komisch ist nur, daß via ip-down sehr wohl ein "runterfahren" der fw ausgeführt wird, dieses ist anscheinend fehlerhaft. Nach dem Trennen der Verbindung muss ich die FW von Hand nochmals runterfahren, damit ich wieder eine Einwahl hinbekomme.... Gruß, Jörg --- Sonntag, 2. Dezember 2001 19:25 mailto:linux@vague.de http://www.vague.de
Moinsen, On 02.12.2001 19:27:22 Jörg Nehls wrote:
Sunday, December 02, 2001, 6:56:17 PM, Arne-Erik Martin wrote:
Hat man Dir die "Einweg-DSL" (einmal benutzen und dann wegwerfen ...) verkauft (SCNR) Zuzutrauen ist der DTAG das ohne Wimperzucken ;-)
Ist da wenigstens ein Grüner Punkt drauf? *g* Sorry, man sollte sein erstes Posting nicht mit nem blöden Spruch beginnen, aber CNR2 :)
Aber im Ernst. Klappt es denn mit deaktivierter FW? Wenn ja, würde ich mal tippen, es liegt daran, das beim Verbindungsabbau die FW sich "verkonfiguriert". "unallowed routing" klingt wohl nach meinem Verdacht ... Also teste mal (aber nur kurz online bleiben!) ohne FW.
Das ist richtig. Komisch ist nur, daß via ip-down sehr wohl ein "runterfahren" der fw ausgeführt wird, dieses ist anscheinend fehlerhaft. Nach dem Trennen der Verbindung muss ich die FW von Hand nochmals runterfahren, damit ich wieder eine Einwahl hinbekomme....
Ich kenn die SuSE FW nicht, hab mir meine selbst gebastelt. Aber das Filter-Problem kenn ich. Auf dem DSL-Interface müssen alle UDP pakete durchgelassen werden, die von port bootps (67) nach bootpc (68) gehen. Darüber läuft der DSL-Handshake ab. Bei mir sehen die Regeln folgendermaßen aus ($IPT=iptables): <snip> # PPPoE interface filtering $IPT -t filter -A INPUT -i $IF_DSL -p udp --sport bootps \ --dport bootpc -j ACCEPT $IPT -t filter -A INPUT -i $IF_DSL -j DROP $IPT -t filter -A OUTPUT -o $IF_DSL -j DROP </snip> K.A. wie man das in die SuSE FW einträgt, aber damit sollteste weiterkommen... Firewall nach dem disconnect entladen ist IMHO eh eine ziemlich böde Idee, meine steht 24/7. Allein schon, um irgendwelchen Besuchern den Zugriff auf {pop|service}.t-online.de zu verweigern :) Gruss Malte
* Sonntag, 02. Dezember 2001 um 20:38 (+0100) schrieb Malte S. Stretz:
Auf dem DSL-Interface müssen alle UDP pakete durchgelassen werden, die von port bootps (67) nach bootpc (68) gehen. Darüber läuft der DSL-Handshake ab.
Woher hast du diese Information? Ich halte das für eine
Fehlinterpretation...
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Hallo, at Sunday 02.12.2001 (21:58 +0100), Andreas Koenecke wrote:
* Sonntag, 02. Dezember 2001 um 20:38 (+0100) schrieb Malte S. Stretz:
Auf dem DSL-Interface müssen alle UDP pakete durchgelassen werden, die von port bootps (67) nach bootpc (68) gehen. Darüber läuft der DSL-Handshake ab.
Woher hast du diese Information? Ich halte das für eine Fehlinterpretation...
Ich auch. Denn ich blocke diesen Port und habe bisher kein Problem festgestellt. Gruß Michael -- Phone/Fax +49 7000 MACBYTE (+49 7000-6222983) Registered Linux User #228306 HomePage http://www.macbyte.info/ http://counter.li.org/ PGP-Key http://www.macbyte.info/shared/mykey.pkr ++ CGI-Hosting ++ Domains ++ Webspace ++ PHP Development ++
On 02.12.2001 22:16 Michael Raab wrote, at least in part:
at Sunday 02.12.2001 (21:58 +0100), Andreas Koenecke wrote:
* Sonntag, 02. Dezember 2001 um 20:38 (+0100) schrieb Malte S. Stretz:
Auf dem DSL-Interface müssen alle UDP pakete durchgelassen werden, die von port bootps (67) nach bootpc (68) gehen. Darüber läuft der DSL-Handshake ab.
Woher hast du diese Information? Ich halte das für eine Fehlinterpretation...
Ich auch. Denn ich blocke diesen Port und habe bisher kein Problem festgestellt.
Hmmm... woher hatte ich das bloss... könnte unter [1] gewesen sein. Ich muss zugeben, die Bemerkung, dass darüber der DSL-Handshake abläuft, war meine Interpretation ;-) Aber BOOTP ist doch AFAIK ein Protokoll, um automatisch Netzwerkeinstellungen zuzuordnen, oder? WAI, ich hab zumindest in einem Fall die Erfahrung gemacht, dass es mit gefiltertem bootp{s|c} port nicht funzte, mit aber schon. Konkret war das eine Always-on Firewall, bei dem alle Tables die Policy DENY hatten und damit auch sämtlicher Verkehr über das DSL-Interface (d.h., die Netzwerkkarte an der das Modem hängt; bei mir eth1) abgeblockt wurde. Gruss Malte [1] http://www.adsl4linux.de/
Hallo, at Monday 03.12.2001 (19:08 +0100), Malte S. Stretz wrote:
Aber BOOTP ist doch AFAIK ein Protokoll, um automatisch Netzwerkeinstellungen zuzuordnen, oder?
Nein, les mal hier weiter http://www.aldev.8m.com/disklesshowto-RFC-951.html Gruß Michael -- Phone/Fax +49 7000 MACBYTE (+49 7000-6222983) Registered Linux User #228306 HomePage http://www.macbyte.info/ http://counter.li.org/ PGP-Key http://www.macbyte.info/shared/mykey.pkr ++ CGI-Hosting ++ Domains ++ Webspace ++ PHP Development ++
Moin SuSE-Linux, On 03.12.2001 19:19 Michael Raab wrote, at least in part:
Hallo,
at Monday 03.12.2001 (19:08 +0100), Malte S. Stretz wrote:
Aber BOOTP ist doch AFAIK ein Protokoll, um automatisch Netzwerkeinstellungen zuzuordnen, oder?
Nein, les mal hier weiter http://www.aldev.8m.com/disklesshowto-RFC-951.html
Hab nur "2. Overview" kurz überflogen: <snip> This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. </snip> Das ist doch im Prinzip genau das, worum's geht. Wie Michael schrieb ist das ganze ein Vorgänger von DHCP. Ok, Schritt 2, das BootROM aus dem Netz zu laden, wird bei T-Offline wohl nicht statt finden (obwohl... wer weiss?), aber der Rest findet wohl so statt wie dort beschrieben. Also: nix bootp{s|c} => nix IP => nix DSL ;-) Versuch doch einfach mal folgendes: <tt> rcadsl stop # oder heisst das rcpppoed...? k.A. iptables -I INPUT -i $DEIN_DSL_IF -p udp --sport bootps \ --dport bootpc rcadsl start </tt> Ich bin gespannt auf das Ergebnis. Gruss Malte
* Montag, 03. Dezember 2001 um 20:07 (+0100) schrieb Malte S. Stretz:
Das ist doch im Prinzip genau das, worum's geht. Wie Michael schrieb ist das ganze ein Vorgänger von DHCP. Ok, Schritt 2, das BootROM aus dem Netz zu laden, wird bei T-Offline wohl nicht statt finden (obwohl... wer weiss?), aber der Rest findet wohl so statt wie dort beschrieben.
Falsch, der Verbindungsaufbau bei PPPoE (T-DSL) geschieht ins 2 Stufen (RFC 2516): Stufe 1 (Discovery Stage): Kontaktaufnahme mit dem PPPoE-Server und Aushandeln einer Session-ID. Diese Stufe arbeitet auf der Ethernet-Schicht, filtern auf IP-Ebene ist nutzlos... Stufe 2 (PPP Session Stage): Authentifizierung und Aushandeln der Verbindungsparameter (Local-IP, Remote-IP, NS usw.) mit Hilfe der "normalen" PPP-Protokolle. Danach Übertragung der Nutzdaten (IP) über die PPP-Verbindung.
Also: nix bootp{s|c} => nix IP => nix DSL ;-) Versuch doch einfach mal folgendes: <tt> rcadsl stop # oder heisst das rcpppoed...? k.A. iptables -I INPUT -i $DEIN_DSL_IF -p udp --sport bootps \ --dport bootpc rcadsl start </tt> Ich bin gespannt auf das Ergebnis.
Es funktioniert trotzdem -- natürlich!
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Moinsen, On 03.12.2001 20:46 Andreas Koenecke wrote, at least in part:
* Montag, 03. Dezember 2001 um 20:07 (+0100) schrieb Malte S. Stretz:
Das ist doch im Prinzip genau das, worum's geht. Wie Michael schrieb ist das ganze ein Vorgänger von DHCP. Ok, Schritt 2, das BootROM aus dem Netz zu laden, wird bei T-Offline wohl nicht statt finden (obwohl... wer weiss?), aber der Rest findet wohl so statt wie dort beschrieben.
Falsch, der Verbindungsaufbau bei PPPoE (T-DSL) geschieht ins 2 Stufen (RFC 2516):
Stufe 1 (Discovery Stage): Kontaktaufnahme mit dem PPPoE-Server und Aushandeln einer Session-ID. Diese Stufe arbeitet auf der Ethernet-Schicht, filtern auf IP-Ebene ist nutzlos...
Stufe 2 (PPP Session Stage): Authentifizierung und Aushandeln der Verbindungsparameter (Local-IP, Remote-IP, NS usw.) mit Hilfe der "normalen" PPP-Protokolle. Danach Übertragung der Nutzdaten (IP) über die PPP-Verbindung.
Hmmmtja. Wird wohl stimmen wenn's da steht. Aber (a) trau ich der Telekom alles zu (OT: ZZt. lauf ich bei T-Offline unter zwei Benutzerkennungen. Weiß der Teufel warum, aber die rechnen mir jeden Monat die Flat 2x an. Klingt sinnlos? Isses auch!) und (b) funzt es - aus welchen Gründen auch immer - bei mir nur mit freigegebenen BOOTP Ports... Was sagt eigentlich Jörg, der Auslöser dieses Threads zu dem Thema...? Hmmm... hab mir grad noch mal seine mitgeposteten Logs angeschaut und da wird nicht versucht, auf einen der BOOTP Ports zuzugreifen, sondern auf dem FastTrack/KaZaA/Morpheus Port (1214)...
Also: nix bootp{s|c} => nix IP => nix DSL ;-) Versuch doch einfach mal folgendes: <tt> rcadsl stop # oder heisst das rcpppoed...? k.A. iptables -I INPUT -i $DEIN_DSL_IF -p udp --sport bootps \ --dport bootpc rcadsl start </tt> Ich bin gespannt auf das Ergebnis.
Es funktioniert trotzdem -- natürlich!
Flusht Deine Firewall beim Hochfahren die Tables? Was sagt denn `iptables -L INPUT | grep bootp` nach dem Einwählen? Gruss Malte
Moin Michael,
at Sunday 02.12.2001 (21:58 +0100), Andreas Koenecke wrote:
* Sonntag, 02. Dezember 2001 um 20:38 (+0100) schrieb Malte S. Stretz:
Auf dem DSL-Interface müssen alle UDP pakete durchgelassen werden, die von port bootps (67) nach bootpc (68) gehen. Darüber läuft der DSL-Handshake ab.
Woher hast du diese Information? Ich halte das für eine Fehlinterpretation...
Ich auch. Denn ich blocke diesen Port und habe bisher kein Problem festgestellt.
Was auch immer darüber abläuft, es scheint keine negativen Auswirkungen zu haben, wenn man die Ports blockt. Zumindest funktioniert T-DSL. Leider füllen sich /var/log/messages und /var/log/firewall zusehens, weil 10-20 Mal pro Minute eine DENY-Zeile eingetragen wird. Da schickt der T-Online Einwahlrechner fröhlich bootp-Broadcasts an die Kundschaft, wobei er da die Client-Rolle übernimmt. 1) Ich könnte schwören, das begann erst nach dem Blackout for 3-4 Wochen. 2) man bleibt bei dial-on-demand ständig online 3) die Logs schwellen an (OK, weil ich nicht weiß, wie man das bei SuSEfirewall2 für diesen einen Port unterdrückt) 4) OK, Ich hab ne Flat aber wer zahlt andernfalls das Volumen ? 584 Bytes bei ca 15 Hits/Minute ... da komm ich -- über den Daumen gepeilt -- auf 360MB im Monat. 5) Wer zahlt die Zeit, wenn man keine Flat hat ? ZB bei Modem/ISDN Verbindungen überwachen etliche Provider die Leitung und schubsen einen raus. Zumindest hat man eine Chance, dass die egene Kiste "auflegt", falls grad alle Welt versucht bei mir Sub7, Morpheus, etc zu finden. 6) Was soll das ? T-Onlines Hotline meinte: a) zu 2) "Was wollen Sie denn ? Sie werden doch um Mitternacht ohnehin automatisch gekickt." (Nach 24 Std. aber egal ...) b) zu 4) darauf gingen beide Hotliner nicht ein. c) zu 5) goto a =8-{ Wie kann man die Standard-inbound-ports, die ständig unerwünscht von außen abgefragt werden, aus dem Dial-On-Demand raus nehmen, sodaß die meine Büxe nicht unnötig t-online halten können ? Wo trägt man eine Regel in den SuSEfirewall2 ein, die das Loggen dieser bootp-broadcasts unterdrückt ? Ich habe jetzt LOG-DROP-CRIT auf NO und das finde ich auch nicht soo doll. aus /var/log/messages (xxx.xxx.xxx.xxx ist mein P-t-P Uplink bei T-Online) ------------------------------------------------------------- Dec 4 17:23:34 FEBRUAR kernel: SuSE-FW-UNALLOWED-TARGETIN=ppp0 OUT= MAC= SRC=xxx.xxx.xxx.xxx DST=255.255.255.255 LEN=604 TOS=0x00 PREC=0x00 TTL=255 ID=54221 PROTO=UDP SPT=68 DPT=67 LEN=584 Dec 4 17:23:37 FEBRUAR kernel: SuSE-FW-UNALLOWED-TARGETIN=ppp0 OUT= MAC= SRC=xxx.xxx.xxx.xxx DST=255.255.255.255 LEN=604 TOS=0x00 PREC=0x00 TTL=255 ID=54417 PROTO=UDP SPT=68 DPT=67 LEN=584 Dec 4 17:23:40 FEBRUAR kernel: SuSE-FW-UNALLOWED-TARGETIN=ppp0 OUT= MAC= SRC=xxx.xxx.xxx.xxx DST=255.255.255.255 LEN=604 TOS=0x00 PREC=0x00 TTL=255 ID=54613 PROTO=UDP SPT=68 DPT=67 LEN=584 -------------------------------------------------------------
Hallo, on Sat, 08 Dec 2001 01:19:34 +0100 Andreas Fiesser wrote:
Leider füllen sich /var/log/messages und /var/log/firewall zusehens, weil 10-20 Mal pro Minute eine DENY-Zeile eingetragen wird.
Bei mir nicht. Denn diese Rule wird bei mir nicht geloggt. ;-)
T-Onlines Hotline meinte:
T-Onlines Hotline kannste doch in die Tonne treten. Die haben doch arge Probleme Dir gescheiten Support zu leisten wenn Du mit Windows rummachst. Denn bekommt man den Spruch zu hören: "Wir supporten nur die T-Online Software". Wo ich meinen Linuxrouter - ohne X & Co. - aufgesetzt habe, wollte ich von T-Online wissen, ob eine Störung im unserem Ortsnetz vorliegt. Die Tante meint nur, "Öffnen Sie bitte die Systemsteurung". Ich sagte ihr, das ich keine hätte. Sie meinte darauf, das gibt es doch nicht, jeder PC hat ne Systemsteuerung. *lol* Als ich ihr dann sagte, das ich mit Linux Online bin, da hats ihre Sprache verschlagen.
Wie kann man die Standard-inbound-ports, die ständig unerwünscht von außen abgefragt werden, aus dem Dial-On-Demand raus nehmen, sodaß die meine Büxe nicht unnötig t-online halten können ?
Die inbounds blockst Du schon ? Wenn ja, weiss ich auch nicht. Das einzige was mir dazu einfällt ist, den ppp-Treiber zu modifizieren.
Wo trägt man eine Regel in den SuSEfirewall2 ein, die das Loggen dieser bootp-broadcasts unterdrückt ?
Nutzt Susefirewall nicht iptables ?? Kann man da nicht ein eignes Rulescript schreiben ? Gruß Michael -- Phone/Fax +49 7000 MACBYTE Registered Linux User #228306 HomePage http://www.macbyte.info/ http://counter.li.org/ PGP-Key http://www.macbyte.info/shared/mykey.pkr ++ CGI-Hosting ++ Domains ++ Webspace ++ PHP Development ++
Hallo,
Bei mir nicht. Denn diese Rule wird bei mir nicht geloggt. ;-)
Bei SuSEfirewall2 wohl und was eigenes basteln is mir jetzt zu stressig.
Die inbounds blockst Du schon ? Wenn ja, weiss ich auch nicht. Das einzige was mir dazu einfällt ist, den ppp-Treiber zu modifizieren.
Der Paketfilter, der die inbounds blockliert, sitz ja hinter dem ppp also hilft das garnix. ppp-Treiber modifizieren ... ich ... ähm :) Eigentlich sollte man ja vermuten, dass noch mehr -- und fähigere -- Leute das Problem haben. Immerhin sind Scans auf 80, 1214, Bearshare, 139, sub7 usw Gang und Gäbe. ... af
Hallo, on Sat, 08 Dec 2001 03:38:37 +0100 Andreas Fiesser wrote:
Bei mir nicht. Denn diese Rule wird bei mir nicht geloggt. ;-)
Bei SuSEfirewall2 wohl und was eigenes basteln is mir jetzt zu stressig.
Ich kenne die SuseFirewall nicht. Denn ich hatte das Glück mir meine Firewall selbst zu häckeln. ;-) Bei Redhat geht es doch einwenig anders zu. Was macht die SuseFirewall denn ? Erstellt die ein Script für iptables ? Wenn ja, ist es eigentlich kein Problem dieses anzupassen. Wenn es ein Sript ist, dann müsste eigentlich folgende Anweisung $IPTABLES -A INPUT -p udp -i $DEV_INET -d 0.0.0.0/0 --dport 68 -j DROP den bootp blocken, aber nicht loggen. $IPTABLES ist der Pfad zu iptables und $DEV_INET ist die DSL-Schnittstelle ppp0. Gruß Michael -- Phone/Fax +49 7000 MACBYTE Registered Linux User #228306 HomePage http://www.macbyte.info/ http://counter.li.org/ PGP-Key http://www.macbyte.info/shared/mykey.pkr ++ CGI-Hosting ++ Domains ++ Webspace ++ PHP Development ++
* Samstag, 08. Dezember 2001 um 03:38 (+0100) schrieb Andreas Fiesser:
Der Paketfilter, der die inbounds blockliert, sitz ja hinter dem ppp also hilft das garnix. ppp-Treiber modifizieren ... ich ... ähm :)
Der pppd besitzt dazu eine Option 'active-filter', die AFAIR trotz des
Hinweises in der Man-Page auf NetBSD auch mit Linux funktionieren
soll.
Allerdings müssen dazu vermutlich Kernel und pppd mit 'PPP_FILTER' neu
übersetzt werden.
Eine (IMHO flexiblere) Alternative wäre Dial-On-Demand mit dem diald
statt der demand-Option des pppd. Der diald ist allerdings auch nicht
ganz einfach einzurichten...
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Malte S. Stretz schrieb am 02.12.2001 um 20:38:22 +0100: Hallo Malte,
Ich kenn die SuSE FW nicht, hab mir meine selbst gebastelt. Aber das Filter-Problem kenn ich. Auf dem DSL-Interface müssen alle UDP pakete durchgelassen werden, die von port bootps (67) nach bootpc (68) gehen. Darüber läuft der DSL-Handshake ab. Bei mir sehen die Regeln folgendermaßen aus ($IPT=iptables):
<snip> # PPPoE interface filtering $IPT -t filter -A INPUT -i $IF_DSL -p udp --sport bootps \ --dport bootpc -j ACCEPT $IPT -t filter -A INPUT -i $IF_DSL -j DROP $IPT -t filter -A OUTPUT -o $IF_DSL -j DROP </snip>
K.A. wie man das in die SuSE FW einträgt, aber damit sollteste weiterkommen... Firewall nach dem disconnect entladen ist IMHO eh eine ziemlich böde Idee, meine steht 24/7. Allein schon, um irgendwelchen Besuchern den Zugriff auf {pop|service}.t-online.de zu verweigern :)
ganz sicher? Währe mir neu. Ich zumindest benötige das nicht um per DSL was zu machen. Mich würde mal interessieren woher Du das hast. Bis denne, Michael
-----Original Message----- From: Owen Walsh [mailto:walsh@addcom.de] Sent: Friday, November 30, 2001 10:34 PM To: suse-linux@suse.com Subject: Masquerding und GMX.de !!!
Hi Leute,
ich habe es endlich geschafft, Masquerding einzurichten. Firewall sollte eigentlich deaktiviert sein, scheint aber doch zu funtzen ?! weil ich bekomme von außen keinen Zugriff auf Telnet. Ich komme auf JEDE Seite im WWW. Jedoch auf www.gmx.de kann ich net zugreifen. Weiß jemand von euch, wodran das liegt ??? Ich habe einen Kumpel gefragt, der kommt drauf.
Hallo, System: SuSE 7.0 org. SuSE 2.2er kernel masq. mit ipchains ich habe leider dasselbe prob, und hab die antworten auch schon verfolgt. habe die mtu&mru auf 1492 gestellt (auch schon 1452), versucht wie in der susedb beschrieben die ethernet mtu auf 1400 zu stellen, aber ohne erfolg. ich kann ein traceroute auf www.gmx.de machen: root@gateway:/home/yannw > traceroute www.gmx.de traceroute to www.gmx.de (213.165.65.100), 30 hops max, 40 byte packets 1 212.185.251.85 (212.185.251.85) 28 ms 28 ms 27 ms 2 212.185.251.86 (212.185.251.86) 37 ms 28 ms 26 ms 3 INXS-gw20.M.net.DTAG.DE (194.25.6.14) 34 ms 33 ms 34 ms 4 62.156.128.226 (62.156.128.226) 35 ms 35 ms 34 ms 5 www.gmx.net (213.165.65.100) 34 ms 36 ms 35 ms ein ping jedoch funtzt net. komme nirgendwie dran. laut suse sind diese probs aber nur beim 2.4er kernel. duerften also bei mir garnicht auftreten... *grübel* *willmeinemailsbeigmx.dehaben:)* -- MfG Yann Wissenbach www : http://www.world-wide-wait.de http://www.vw-opel-ig.de mail : yann@world-wide-wait.de ICQ : 98297452 Linux - Life is too short for reboots
Hallo,
"Yann Wissenbach"
From: Owen Walsh [mailto:walsh@addcom.de]
Hallo,
System: SuSE 7.0 org. SuSE 2.2er kernel masq. mit ipchains
ich habe leider dasselbe prob, und hab die antworten auch schon verfolgt. habe die mtu&mru auf 1492 gestellt (auch schon 1452), versucht wie in der susedb beschrieben die ethernet mtu auf 1400 zu stellen, aber ohne erfolg. ich kann ein traceroute auf www.gmx.de machen: [...]
Welche icmp Protokolle werden denn von deinen ipchains Regeln gefiltert und welche werden durchgelassen ? -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour
-----Original Message----- From: Dieter Kluenter [mailto:dieter@incode.com] Sent: Tuesday, December 04, 2001 10:51 AM To: suse-linux@suse.com Subject: Re: Masquerding und GMX.de !!!
Hallo,
"Yann Wissenbach"
writes: From: Owen Walsh [mailto:walsh@addcom.de]
Hallo,
System: SuSE 7.0 org. SuSE 2.2er kernel masq. mit ipchains
ich habe leider dasselbe prob, und hab die antworten auch schon verfolgt. habe die mtu&mru auf 1492 gestellt (auch schon 1452), versucht wie in der susedb beschrieben die ethernet mtu auf 1400 zu stellen, aber ohne erfolg. ich kann ein traceroute auf www.gmx.de machen: [...]
Welche icmp Protokolle werden denn von deinen ipchains Regeln gefiltert und welche werden durchgelassen ?
Hallo, Ich habe derzeit nur diese regel, da ich mich nicht wirklich toll damit auskenne. /sbin/ipchains -A forward -s 192.168.1.0/24 -j MASQ und ich lade noch folgende module: insmod /lib/modules/2.2.16/ipv4/ip_masq_ftp.o insmod /lib/modules/2.2.16/ipv4/ip_masq_quake.o insmod /lib/modules/2.2.16/ipv4/ip_masq_raudio.o insmod /lib/modules/2.2.16/ipv4/ip_masq_portfw.o insmod /lib/modules/2.2.16/ipv4/ip_masq_irc.o insmod /lib/modules/2.2.16/ipv4/ip_masq_autofw.o insmod /lib/modules/2.2.16/ipv4/ip_masq_vdolive.o insmod /lib/modules/2.2.16/ipv4/ip_masq_cuseeme.o insmod /lib/modules/2.2.16/ipv4/ip_masq_mfw.o -- MfG Yann Wissenbach www : http://www.world-wide-wait.de http://www.vw-opel-ig.de mail : yann@world-wide-wait.de ICQ : 98297452 Linux - Life is too short for reboots
* Dienstag, 04. Dezember 2001 um 18:57 (+0100) schrieb Yann Wissenbach:
Ich habe derzeit nur diese regel, da ich mich nicht wirklich toll damit auskenne.
/sbin/ipchains -A forward -s 192.168.1.0/24 -j MASQ
und ich lade noch folgende module:
[...]
Es fehlt noch das Modul 'mssclampfw.o', das du IIRC auch bei SuSE
findest.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
-----Original Message----- From: Yann Wissenbach [mailto:yann@world-wide-wait.de] Sent: Monday, December 03, 2001 11:24 PM To: suse-linux@suse.com Subject: RE: Masquerding und GMX.de !!!
[...]
System: SuSE 7.0 org. SuSE 2.2er kernel masq. mit ipchains
ich habe leider dasselbe prob, und hab die antworten auch schon verfolgt. habe die mtu&mru auf 1492 gestellt (auch schon 1452), versucht wie in der susedb beschrieben die ethernet mtu auf 1400 zu stellen, aber ohne erfolg. ich kann ein traceroute auf www.gmx.de machen:
root@gateway:/home/yannw > traceroute www.gmx.de traceroute to www.gmx.de (213.165.65.100), 30 hops max, 40 byte packets 1 212.185.251.85 (212.185.251.85) 28 ms 28 ms 27 ms 2 212.185.251.86 (212.185.251.86) 37 ms 28 ms 26 ms 3 INXS-gw20.M.net.DTAG.DE (194.25.6.14) 34 ms 33 ms 34 ms 4 62.156.128.226 (62.156.128.226) 35 ms 35 ms 34 ms 5 www.gmx.net (213.165.65.100) 34 ms 36 ms 35 ms
ein ping jedoch funtzt net. komme nirgendwie dran. laut suse sind diese probs aber nur beim 2.4er kernel. duerften also bei mir garnicht auftreten... *grübel*
*willmeinemailsbeigmx.dehaben:)*
Hallo, endlich klappts .-)))) ich komme auf gmx.de *freu* http://sdb.suse.de/de/sdb/html/hoe_adsl_router.html --- Damit Pakete, die von den Clients mit einer Paketgrösse von > 1490 Bytes an das Gateway geschickt werden, korrekt fragmentiert werden, muss das Modul mssclampfw geladen sein. Nur für SuSE Linux Versionen kleiner 7.0: Leider befindet sich das Modul erst ab SuSE Version 7.1 in binärer Form auf den SuSE CDs. Besitzer älterer Versionen haben zwei Möglichkeiten: Laden Sie das Modul von unserem FTP-Server --> ftp://ftp.suse.com/pub/projects/T-DSL/mssclampfw.o. mv mssclampfw.o /lib/modules/2.2.16/misc/ sie können das Modul nun sofort mit insmod /lib/modules/2.2.16/misc/mssclampfw laden Damit das Modul beim Systemstart automatisch geladen wird, sollten Sie in die Datei /etc/modules.conf die Einträge post-install pppox insmod mssclampfw pre-remove pppox rmmod mssclampfw einfügen und depmod -a aufrufen. --- *so, jetzt kann ich schlafen gehen* p.S. jetzt muesste ich eigentlich die mtu und mru auch wieder auf 1500 stellen koennen anstatt 1492, oder ?!? -- MfG Yann Wissenbach www : http://www.world-wide-wait.de http://www.vw-opel-ig.de mail : yann@world-wide-wait.de ICQ : 98297452 Linux - Life is too short for reboots
Hallo. at Wednesday 05.12.2001 (00:14 +0100), Yann Wissenbach wrote:
p.S. jetzt muesste ich eigentlich die mtu und mru auch wieder auf 1500 stellen koennen anstatt 1492, oder ?!?
Bei ppp0 lass ihn auf 1492. Gruß Michael -- Phone/Fax +49 7000 MACBYTE (+49 7000-6222983) Registered Linux User #228306 HomePage http://www.macbyte.info/ http://counter.li.org/ PGP-Key http://www.macbyte.info/shared/mykey.pkr ++ CGI-Hosting ++ Domains ++ Webspace ++ PHP Development ++
-----Original Message----- From: Michael Raab [mailto:raab.edv@gmx.de] Sent: Wednesday, December 05, 2001 12:29 AM To: Suse Maillingliste Subject: Re: Meine Loesung: Masquerding und GMX.de !!!
Hallo.
at Wednesday 05.12.2001 (00:14 +0100), Yann Wissenbach wrote:
p.S. jetzt muesste ich eigentlich die mtu und mru auch wieder auf 1500 stellen koennen anstatt 1492, oder ?!?
Bei ppp0 lass ihn auf 1492.
Hallo, gibts bestimmte gruende (firewalls?!) oder sinds dann wieder 1508 byte wenn ich se auf 1500 stelle ? -- MfG Yann Wissenbach www : http://www.world-wide-wait.de http://www.vw-opel-ig.de mail : yann@world-wide-wait.de ICQ : 98297452 Linux - Life is too short for reboots
Michael Raab wrote:
at Wednesday 05.12.2001 (00:14 +0100), Yann Wissenbach wrote:
p.S. jetzt muesste ich eigentlich die mtu und mru auch wieder auf 1500 stellen koennen anstatt 1492, oder ?!?
Bei ppp0 lass ihn auf 1492.
Yep, ppp0 wird garnicht händisch manipuliert. 1492 ist als Wert in die Konfigdateien einzutragen, das Setzen dieses Wertes geschieht dann während der Verhandlung mit dem AC. - Matthias
participants (18)
-
Andreas Bacher
-
Andreas Fiesser
-
Andreas Koenecke
-
Arne-Erik Martin
-
Dieter Kluenter
-
Eduard Reiter
-
Jörg Nehls
-
Malte S. Stretz
-
Marcus Roeckrath
-
Markus Weber
-
Matthias Kleine
-
Matthias Kleine
-
Michael Raab
-
Michael Schulz
-
Owen Walsh
-
Sebastian Wolfgarten
-
Thomas Burgau
-
Yann Wissenbach