Routing mit Suse 10.1 funktioniert nicht. Denkfehler oder Bug?

Hallo TC

Das kann nicht sein was dein Provider da sagt oder einer hat etwas falsch verstanden. Nach gängigen IP Adresskonventionen darf die .128 einfach gar nicht vergeben werden. Ist sie trotzdem vergeben ist das ein böser Fehler denn die meisten aller IP Stacks würden auf so eine Adresse als Endgeräteadrresse schlicht nicht reagieren weil sie falsch ist. Schon aus dem Grunde um unterschiedliches verhalten nicht zu provozieren wäre die Vergabe dieser Adresse einfach falsch.
Es kann auch nicht sein das man ein 195er Adresse nict auf der Fritzbox konfigurierbar ist. Anhand deiner Ausführungen ist zu vermuten, das auf dem Routersegment zwischen deinem SuSE Rechner und dem Router 2 aktive IP Netze konfiguriert sind. Das ist IP technisch falsch da wie gesagt eigentlich in einem sauberen Design nicht supportet. Deshalb ist es auch klar das du nicht z.B. eine Seite mit 195.x.y.z konfigurieren kannst und die andere mit 192.168.x.y. Das ist IP technisch unmöglich !! Für die beiden Endgeräte sind das unterschiedliche IP Netze die sie nicht sehen auch wenn sie auf ein und derselben Physik stecken.
Meist können das höherwertige Router mit sog. "secondary" IP Adressen lösen aber das Problem ist das z.B. schlicht nicht definiert ist welche der unterschiedlichen IP Netze nun ICMP Dienstpackete (zu denen auch Traceroute gehört..) versendet. Das ist nicht im IP Standard vorgesehen und deshalb auch von vielen nicht supportet oder sollte wie gesagt wenn, dann nur temporär für Adressmigrationen eingesetzt werden.
Erschwerend kommt bei dir dazu das die 195er Adresse öffentlich ist die 192.168.1.x aber nicht. Höchst bedenklich auf einem Segment und würde dann wenigstens einen NAT Prozess für dies IP Netz im Router erfordern.
An diesem Router ist de facto generell was falsch mit der IP Adressierung. Die .128 darf definitiv NICHT als Geräteadresse vergeben werden, das ist ein Fehler. Auch ist die Verwendung von 2 Netzen zumindest bedenklich und kann zu weiteren Fehlern führen. Keine übliche Praxis bei Providern....

Mit deinem lokalen Zugriff auf Port 81 der externen Adresse sollte klappen wenn SSH oder ping klappt und alle Routen im IPCop soweit stimmen, was anzunehmen ist, wenn SSH auf die externe Adresse problemlos klappt.
Vermutlich wird dann Port 81 irgendwo geblockt. Auch wäre ich vorsichtig, denn TCP/UDP 81 ist ein reservierter Port den man nicht so ohne weiteres verwenden sollte. Wenn du damit eine HTTP Verbindung aufbauen willst solltest du besser 8080 oder 8088 nehmen !
Im Zweifelsfall musst du mit tcpdump oder einem Wireshark an den Interfaces mal nachsehen wer dir diese Packete "klaut". Es kann eigentlich nur irgendwo ein Port Filter sein denn wenn generell was falsch ist dürfte Ping und SSH auch nicht klappen....

Nochmal was zum Internetanschluss: Wieso "Richtfunk-Internetanschluss fällt aus, weil jemand den Funkverkehr abschneidet. Nun greife ich auf die öffentliche IP zu..." ???
Sowohl Draht als auch RiFu sollten öffentliche Adressen benutzen wenn der Provider das RiFu Netz nicht mit eigenen RFC 1918 Adressen betreibt ! So oder so MUSS er doch dafür sorgen, das sich beim Ausfall einer Strecke für dich als Kunden nichts ändert an der IP Adresse. Er kann doch nicht von dir als Kunden verlangen das du ewig deinen Zugang umkonfigurierst...das hört sich sehr komisch an und verstärkt den Verdacht, das der Provider wirklich nicht weiss was er da macht....

Nun zu deiner Laptop Kommunikation. Wenn die FW stateful ist terminiert sie die Anfrage das ist rihtig, sie darf aber den Zielport nicht verändern was sie auch nicht macht. Gesetzt den Fall du nimmst SSH (hat nicht so hohe verwirrende Portnummern..) dann eröffnet der Latop eine TCP Connection auf Port 22 zum IPCop der terminiert das und schickt auf dem outgoing Interface aber wiederum eine TCP Connection mit Ziel Port 22 an den Suse. Der Empfangsport ist sicher unterschiedlich zu dem des Laptops.
Kommt nun das Packet mit TCP 22 beim Suse an reicht er es an die Applikation weiter, die sieht aber den von IPCop verwendeten Sourceport und schickt diese Packete mit eben diesem Sourceport für IPCop als Zielport wieder zurück. Da der IPCop stateful ist sieht der in der State Tabelle nach und sieht das incoming 19380 für outgoing 12001 ist und ändert das entsprechend für den Laptop als final Destination.
Wäre der IPCop nicht stateful würden die Ports transparent durchgereicht....
Das Problem ist das die FW immer nur genau diese Ports durchlässt rückwärts die sie auch in ihrer State tabelle hat. Eröffnet die Zielapplikation weitere Ports wie z.B. bei FTP und anderen Protokollen blockt die FW diese Ports da sie dafür keine aktiven Sessions hat. Man muss bei solchen Protokollen also sehr genau sehen was passiert. VNC z.B. erhöht die Portnummer um jeweils 1 bei weiteren zusätzlichen Schirmen.... sowas blockt die FW normalerweise wenn man nicht gleich die Portrange in der FW Range freigibt.