Router-Probleme mit wenigen Webseiten

Herakles

Herakles

Profifragensteller
Moin!

In alter Urvertrautheit habe ich nach einem Umzug wieder meinen Heimrouter (neu) mit OpenBSD bestückt. Installiert ist demzufolge Version 5.3.

Die Konfiguration habe ich wie üblich vorgenommen, das Gerät macht bisher nicht viel mehr als per DHCP Adressen verteilen und eben routen - und zwar das lokale NEtzwerk ins Internet. Ich habe also zwei Netzwerkinterfaces, eins für LAN und eins für PPPoE. Letzteres habe ich via hostname.pppoe konfiguriert, also Kernel-pppoe.

Soweit, so gut. Nun habe ich Probleme, gewisse Seiten im Internet von den dahinter angeschlossenen Geräten zu erreichen, offenbar unabhängig vom Betriebssystem (ich habe Windows 7 und Ubuntu Linux getestet). Beispiele dafür sind:

rot-weiss.tv
noip.com

Während rot-weiss.tv zumindest grundsätzlich lädt, dann aber ewig mit dem Warten auf

p.jwpcdn.com

verweilt, steht noip.com beim Warten auf

d357soeboisp8.cloudfront.net

ohne dass irgendwas im Browserfenster angezeigt wird (weiße Seite). Mit einem zuvor angeklemmten Netgear-Router habe ich keinerlei Probleme bemerkt.

Bevor ich nun jeden einzelnen Schritt meiner Konfiguration des OpenBSD-Routers hier poste: Hat irgendwer eine Idee, was hier falsch gelaufen sein könnte?

Viele Grüße
Herakles

[EDIT]
Auf spiegel.de beobachte ich vergleichbares. Die Seite lädt vollständig, wenn ich Unterartikel anklicke, verharrt der Firefox in einem "Nachladestadium", will also ständig weitere Daten von variierenden Links haben, der IE10 arbeitet die Seite aber sauber ab. Hingegen bei noip.com lädt auch der IE10 keine Daten...
[/EDIT]
 
Zuletzt bearbeitet:
Ähnliches hatte ich mal festgestellt als ich verschiedene Ports geschlossen hatte. Ich kenne mich mit OpenBSD zwar nicht aus, aber evtl wäre ein Blick in die Firewallregeln interessant.
 
@laedomost: Ich fänd's auch schöner, wenn die Nummer "rot-blau.tv" hieße. Aber offenbar ist zu so einer Aktion nur die Stadt Essen im Stande. Da gibt's am Freitagabend Regionalligafußball zu sehen. Essen gegen Krefeld. Auf jeden Fall einen Blick wert... :)

@Rakor: Ich werde die pf-Regeln nochmal eingehend prüfen.

Danke
 
Ich hatte auch so ein verhalten in letzter Zeit, dass Webseiten machmal erst nach X Sekunden sich geöffnet haben oder das sie bis zu zwei Minuten gebraucht haben, bis sie ganz geladen waren.

Ich habe in der Firewall gesucht in der Routing-Table ect. Schlussendlich war es ein DNS Problem!

Ich hatte die DNS Server des CCC in der "/etc/resolv.conf" eingetragen und jetzt die meines Providers. Damit läuft die Büchse wieder.
 
hi

du musst pf bzw. scrub an passen

da hat sich einwenig getan auch in bezug auf die mtu geschichte .

schau mal in man vom kernel pppoe (4) ,

vermutlich ist das dein problem.

holger
 
Herakles schrieb:
Moin!

In alter Urvertrautheit habe ich nach einem Umzug wieder meinen Heimrouter (neu) mit OpenBSD bestückt. Installiert ist demzufolge Version 5.3.

Die Konfiguration habe ich wie üblich vorgenommen, das Gerät macht bisher nicht viel mehr als per DHCP Adressen verteilen und eben routen - und zwar das lokale NEtzwerk ins Internet. Ich habe also zwei Netzwerkinterfaces, eins für LAN und eins für PPPoE. Letzteres habe ich via hostname.pppoe konfiguriert, also Kernel-pppoe.

Soweit, so gut. Nun habe ich Probleme, gewisse Seiten im Internet von den dahinter angeschlossenen Geräten zu erreichen, offenbar unabhängig vom Betriebssystem (ich habe Windows 7 und Ubuntu Linux getestet). Beispiele dafür sind:

rot-weiss.tv
noip.com

Während rot-weiss.tv zumindest grundsätzlich lädt, dann aber ewig mit dem Warten auf

p.jwpcdn.com

verweilt, steht noip.com beim Warten auf

d357soeboisp8.cloudfront.net

ohne dass irgendwas im Browserfenster angezeigt wird (weiße Seite). Mit einem zuvor angeklemmten Netgear-Router habe ich keinerlei Probleme bemerkt.

Bevor ich nun jeden einzelnen Schritt meiner Konfiguration des OpenBSD-Routers hier poste: Hat irgendwer eine Idee, was hier falsch gelaufen sein könnte?

Viele Grüße
Herakles

[EDIT]
Auf spiegel.de beobachte ich vergleichbares. Die Seite lädt vollständig, wenn ich Unterartikel anklicke, verharrt der Firefox in einem "Nachladestadium", will also ständig weitere Daten von variierenden Links haben, der IE10 arbeitet die Seite aber sauber ab. Hingegen bei noip.com lädt auch der IE10 keine Daten...
[/EDIT]
Zum Vergrößern anklicken....

Moin mein Bester,

so also folgendes sei froh und dem Firefox dankbar das es so ist, cross-site-request's

installiere Dir mal Request Policy als Addon für den Firefox :

https://www.requestpolicy.com/support-requestpolicy.html

dann siehste was da los ist und warum FF nicht weiterleitet-durchleitet das ist vollkommen okay!

dann weist Du warum das so ist dem IE kannst nicht vertrauen weil der blind weiterleitet und das ist Bullshit

MFG
 
Äh, davon abgesehen, ob man zu diesen Hosts tatsächlich auch hinwill, sollten Verbindungen rein technisch schon funktionieren. RequestPolicy löst hier also kein Problem.
 
Mein ideologischer Dank an rudy: immer kritisch bleiben! (Und nichts anderes bin ich von Dir gewöhnt...) ;)

Mein inhaltlicher Dank geht aber an mark05. Die manpage von pppoe(4) gab es tatsächlich her. Es war ein Dreher mit der MTU in Verbindung mit scrub. Die Manpage sagt hier

Problems can arise on machines with private IPs connecting to the
Internet via a machine running both Network Address Translation (NAT) and
pppoe. Standard Ethernet uses a maximum transmission unit (MTU) of 1500
bytes, whereas PPPoE mechanisms need a further 8 bytes of overhead. This
leaves a maximum MTU of 1492. pppoe sets the MTU on its interface to
1492 as a matter of course. However, machines connecting on a private
LAN will still have their MTUs set to 1500, causing conflict.

While pppoe(8) has an internal option, ``mssfixup'', which is enabled by
default and takes care of this, pppoe users have to rely on other
methods. Using a packet filter, the maximum segment size (MSS) can be
set (clamped) to the required value. The following rule in pf.conf(5)
would set the MSS to 1440:

match on pppoe0 scrub (max-mss 1440)
Zum Vergrößern anklicken....

Demzufolge habe ich das Problem gelöst, indem ich folgendes in meine pf.conf einfügte:

Code: 
match in all scrub (no-df random-id max-mss 1440)

Danke, Problem gelöst!
Herakles
 
Ich mal wieder... Das Problem mit den Internetseiten ist gelöst, dafür habe ich nun ein Problem mit einem online-Spiel: GTL. Ein tolles Autorennspiel, das ich auf einem Internetserver seit einigen Jahre spiele. Bis vor einem Umzug war stets eine Fritzbox der Telekom Heimrouter, nun ist ein Modem installiert und eine OpenBSD-Kiste übernimmt den Routerjob - siehe weiter oben im Thread. Seither fliegt ich bei dem Spiel ständig vom Server - nach einigen Minuten.

Könnte auch das mit der pf.conf oder mit kernel.pppoe zusammenhängen? Wenn irgendwelche logs her müssen, nur Bescheid sagen. Ich poste alles, was geht.

Grüße
Herakles
 
Herakles schrieb:
Ich mal wieder... Das Problem mit den Internetseiten ist gelöst, dafür habe ich nun ein Problem mit einem online-Spiel: GTL. Ein tolles Autorennspiel, das ich auf einem Internetserver seit einigen Jahre spiele. Bis vor einem Umzug war stets eine Fritzbox der Telekom Heimrouter, nun ist ein Modem installiert und eine OpenBSD-Kiste übernimmt den Routerjob - siehe weiter oben im Thread. Seither fliegt ich bei dem Spiel ständig vom Server - nach einigen Minuten.

Könnte auch das mit der pf.conf oder mit kernel.pppoe zusammenhängen? Wenn irgendwelche logs her müssen, nur Bescheid sagen. Ich poste alles, was geht.

Grüße
Herakles
Zum Vergrößern anklicken....

hi

ggf wird kein keep alive gemacht zwischen cleint und server.


du kannst via pf mal seperate regeln fuer diese verbindung bauen mit langen stateful timeouts

holger
 
Hi mark05,

Dein Beitrag hat mich zum Nachdenken gebracht, ich habe allerdings zunächst mal weiter in Richtung MTU geforscht. Eine Einstellung von 1452 als MTU lässt das Spiel scheinbar normal arbeiten. Ob es das nun aber wirklich war, muss ich erst noch im Langzeittest prüfen.

In pppoe(4) steht auch was von Jumbo-Frames in Verbindung mit einem pppoe-Zugang. Sollte die Gegenstelle RFC 4638 konform arbeiten, dann müsste eine MTU von mehr als 1500 auf der pppoe-Schnittstelle möglich sein. Das habe ich ausgetestet, es funktioniert aber nicht. Ich komme demzufolge nicht um eine MTU-Einstellung in der pf.conf herum.

Um das alles aber richtig - und wirklich richtig - einzustellen, möchte ich gern wissen, was genau sich geändert hat. In Posting Nr. 6 schreibst du:

du musst pf bzw. scrub an passen

da hat sich einwenig getan auch in bezug auf die mtu geschichte .
Zum Vergrößern anklicken....

Ich finde leider in den pf-FAQs nicht wirklich was zu scrub. Kannst Du mir einen Hinweis geben, wo ich mich weiter informieren kann?

Viele Grüße
Herakles
 
Solltest du glauben mit ner MTU > 1500 irgendwo außerhalb deiner ganz eigenen darauf getesteten Infrastruktur glück zu werden muss ich dich leider enttäuschen. Die meiste Hardware kommt gerade mit der Vergrößerung durch VLAN Tags klar. Sicherlich lässt sich das meiste etwas intelligentere Gigabit Ethernet Equipment auf etwas höheres als 1500 einstellen, aber es gibt ein paar lästige Nebenwirkungen. Erstens kann bei weitem nicht alles wirklich ne MTU von 9000 ab. Zweitens gibt es keinerlei Möglichkeit die MTU auszuhandeln bei Ethernet. Somit werden die Frames einfach gedroppt von Hardware die sie nicht versteht. Das führt zu lustigen Problemen z.B. SSH Logins gehen mit Passwort, aber Loginversuche 4096 Bit RSA Schlüsseln hängen bis zum TCP Timeout.
 
Es ging um eine leicht aufgebohrte MTU vom Router zum Modem hin, nicht um MTU 9000 im ganzen LAN.
 
hi

also jumo frames in verbindung mit pppoe ist mit gaenzlich unbekannt .( habe ich nur im speziellen umgebungen mit iscsi genutzt )


das interface auf dem das pppoe laeuft braucht nur ein up.
alle weiteren wrte werde via pppoe oder pf gesetzt .

und so wie ich das im kopf habe braucht pppoe ne mtu von 1492 steht aber alles im man 4 pppoe

holger
 
Herakles schrieb:
Ich komme demzufolge nicht um eine MTU-Einstellung in der pf.conf herum.

Um das alles aber richtig - und wirklich richtig - einzustellen, möchte ich gern wissen, was genau sich geändert hat.
Zum Vergrößern anklicken....

Das hast du doch in Posting #9 geschrieben, wie du scrubbing bei pf einsetzt.
Code: 
# scrub incoming packets
match in all scrub (no-df random-id max-mss 1440)

Die MTU für das Interface kannst du in der /etc/hostname.pppoe0 setzen:
ifconfig schrieb:
mtu
value Set the MTU for this device to the given value. Cloned routes will inherit this value as a default. Currently, not all devices support setting the MTU.
Zum Vergrößern anklicken....
Bei Telekomanschlüssen funktioniert es meist mit den voreingestellten 1492. Bei den meisten Reselleranschlüßen/anderen Anbietern muss es weniger sein, da du sonst mit Verbindungsabbrüchen oder anderen Fehlern zu kämpfen hast. 1452 ist hier ein brauchbarer Wert.
 
Moin!

Ich habe nach wie vor keinen Erfolg mit meinen Versuchen, das Ganze zum Laufen zu bewegen. Vielleicht hat jemand ähnliche Probleme mit anderen Spielen beobachten können? Oder vielleicht ist der ISP namens Versatel eine schlechte Wahl?

Nochmal zu Erinnerung: Ich kann mich in das Spiel "GT Legends" online auf einen Server einwählen, bekomme allerdings falsche Anzeigen bezüglich der Rundezeiten anderer Fahrer und kann diese mitunter nicht auf der Strecke sehen. Das Problem besteht seit einem Umzug, zuvor funktionierte alles einwandfrei. Änderung des Setups: Zuvor T-online als ISP und Fritzbox als Router, jetzt Versatel als ISP und OpenBSD auf ALIX als Router.

Hier einmal die Optionen, die ich in der pf.conf durchprobiert habe:
  • scrub
Code: 
match in all scrub (reassemble tcp no-df random-id max-mss 1440)

Die Zeile steht nun so in der pf.conf, zwischenzeitlich habe ich mit der max-mss herumgespielt oder auch das reassemble mal weggelassen, alles ohne Erfolg.
  • modulate state
Code: 
pass out on $ExtDev all nat-to ($ExtDev) modulate state

Auch die Zeile findet sich in der pf.conf, ich habe mit den Timeouts dafür herumgespielt:

Code: 
# seconds between purges of expired states and packet fragments. default: 10
set timeout interval 20
# seconds before an unassembled fragment is expired. default: 30
set timeout frag 60
# seconds to keep a source tracking entry in memory after the last state expires. default: 0
set timeout src.track 30

Jeden der Werte habe ich krass rauf- und auch runtergesetzt, alles ohne Effekt. Ich nutze - wie oben im Thread bereits beschrieben - pppoe(4), also die Kernelvariante, nicht die aus dem Userspace.

Freunde, ich bin ratlos. Ich suche den Fehler seit Wochen und komme einfach nicht voran. Denke ich, es klappt, dann funktioniert es doch beim zwanzigsten Versuch nicht. Am besten reproduzierbar ist der Fehler, wenn ich das Spiel komplett neu starte und mich in einen Internetserver einlogge. Dann habe ich den Fehler fast immer. Weg geht er dann, wenn ich mich von einem Server auslogge und dann wieder einlogge. Allerdings kann es dann passieren, dass ich nach einer halben Stunde mit einem Fehler wie "ich befinde mich plötzlich allein auf der Start-Ziel Geraden ohne Gegner, obwohl ich eine Sekunde zuvor noch in einer Kurve am anderen Ende der Strecke war" habe.

Irgendeine Idee????????

Grüße
der Ratlose
 
Also wenn die Fehler so highlevel sind, würde ich mal grundlegende Netzwerkprobleme ausschließen.
 
hi
am state tracking rum tu spielen bringt nix .

im pf sollte reichen

Code: 
block in log on $wan_if
block out log on $wan_if

match out on $wan_if scrub (max-mss 1440)

pass out quick on $wan_if from 192.168.1.0/24 to any nat-to ($wan_if)

netz natuerlich ensprechenden passen


interfaces

Code: 
# cat ../hostname.msk0
up \
-inet6

cat ../hostname.pppoe0
inet 0.0.0.0 255.255.255.255 NONE \
pppoedev msk0 authproto pap \
authname 'bla' authkey 'blub' up
dest 0.0.0.1
!/sbin/route add default -ifp pppoe0 0.0.0.1


ergo die interfaces sind ohne mtu what ever optionen configurtuert,

holger
 
Ich glaube, das Problem gelöst zu haben (nachdem ich sogar schon Netzwerkkabel ausgetauscht hatte und Switches aus der Verbindung ausgeklinkt hatte). Es scheint ein Problem des Kernel-pppoe zu sein. Wenn ich das System mit pppoe(8) laufen lasse, funktioniert es. Arbeite ich mit pppoe(4), funktioniert es nicht.

Sollte das sich nun im Langzeittest wirklich bewahrheiten, was mache ich dann? Einen Bugreport abschicken? Wer gehört in dem Fall informiert?

Grüße
Herakles
 
hi

also ich kann das nicht wirklich glauben das am kernel pppoe ein bug zu finden ist .

ich arbeite mit dem seit jahren ohne probleme.

holger
 
In so ziemlich allem was jahrelang perfekt läuft sind Bugs versteckt. Selbst, wenn man sich die Mühe macht Tests zu schreiben, die 100% Codeabdeckung haben, kann das noch passieren.

Und bei hardwarenaher Software ist das schlicht unmöglich.
 
Füge mal das hier in die sysctl.conf hinzu: net.inet.tcp.mssdflt=1440 oder in der shell: sysctl net.inet.tcp.mssdflt=1440
Hier noch meine komplette pf.conf falls es wen interessiert:

Code: 
anchor "ftp-proxy/*"
lan_net="10.1.0.0/21"
int_if="bge0"
int_if2="ral0"
ext_if="bge1"
icmp_types="echoreq"

set skip on lo

match in all scrub (no-df max-mss 1440)

block log all

pass quick on $int_if2 inet proto udp from any port 67:68 to any port 67:68

pass in quick on $int_if inet proto tcp to port 21 divert-to 127.0.0.1 port 8021

block in quick from urpf-failed

match out on $ext_if from $lan_net nat-to ($ext_if)

pass out on $int_if to $lan_net

pass in quick on $int_if from $lan_net

pass in quick log inet proto tcp to port 80 divert-to 127.0.0.1 port 3128
pass in quick log inet proto tcp to port 443 divert-to 127.0.0.1 port 3128

pass in inet proto icmp all icmp-type $icmp_types

pass out on $ext_if
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben