Netzwerk läuft AMOK und funktioniert nur sproradisch

[MIKQ]

Ok. Für heuet nach 10 Stunden bin ich mit meinem Latein am Ende.

Habe grade ein OpenBSD 4.4er nach diversen HowTos als Router/Firewall/DHCP Server ausgesetzt wie immer eigentlich.

Ich plage mich mit einem Haufen seltsamer Fehler die kommen und gehen. Kenne ich eigentlich nur sonst von Windows.

Das größte Problem trotz erfolgreicher Einwahl und Verbindung zum Netz kann ich von den Arbeitsstationen nicht Surfen.

Soll heißen, die Windows Rechner können ebenfalls in das Internet "pingen" und "tracen" aber kein Browser öffnet eine Seite!

Seltsam: Für 2 – 3 Seiten funktionierte es vor 5 Minuten (sehr langsam) (heise.de) für andere NICHT! (spiegel.de)
Im Moment funktioniert keine einzige Seite.

Ping hingegen bis eben kein Problem:

C:\Dokumente und Einstellungen\User2>ping www.heise.de

Ping www.heise.de [193.99.144.85] mit 32 Bytes Daten:

Antwort von 193.99.144.85: Bytes=32 Zeit=10ms TTL=247

Hier meine pf.conf

 ### VARIABLEN ###
 
    Ext = "tun0"            # Device an dem das Internet angeschlossen ist 
    Int = "xl0"      # Device an dem das interne Netz haengt
    IntNet = "192.168.0.0/24"      # Adressraum des internen Netzes
    RouterIP = "192.168.0.4"       # IP Adresse des Routers
    Loop = "lo0"                   # Loopback Device
 
    # Adressen die auf dem externen Device nicht geroutet werden
    # (Adressbereich des internen Netzes muss man wegen der Weiterleitungen zulassen)
    table <NoRoute> { 127.0.0.1/8, 172.16.0.0/12, 192.168.0.0/16, !$IntNet, 10.0.0.0/8, 255.255.255.255/32 }
 
    # Ports die geoeffnet werden sollen
    InServicesTCP = "{ ssh, ftp, auth }"
 
 
    ### OPTIONS ###
 
    # Macht Statistiken fuer die DSL-Verbindung (pfctl -s info)
    set loginterface $Ext
 
    # Beendet inaktive Verbindungen schneller - geringerer Speicherverbrauch.
    set optimization aggressive
 
    # Fragmentierte Pakete saeubern
    scrub on $Ext all fragment reassemble random-id
 
    # Queueing 
    # !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    # !! Achtung: Der unten stehende Wert von 100Kb (Kilobit) macht natuerlich
    # !! nur fuer den Standard DSL Anschluss mit 128kb upstream Sinn. Hat man
    # !! eine Verbindung mit groesserer Bandbreite beim upload, dann muss 
    # !! dieser Wert entsprechend angepasst werden. 
    # !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    altq on $Ext priq bandwidth 550Kb queue { q_pri, q_def }
    queue q_pri priority 7
    queue q_def priority 1 priq(default)
 
 
    ### NAT & FORWARD ###
 
    # NAT aktivieren (unter Linux als Masquerading bekannt)
    #nat on $Ext from $IntNet to any -> $Ext static-port
    nat on $Ext from $IntNet to any -> ($Ext) static-port
 
    # Active FTP - Umleitung zu unserem ftp-proxy
    #rdr on $Int proto tcp from !$RouterIP to !$IntNet port 21 -> 127.0.0.1 port 8021
    #rdr-anchor "redirect/*"

    #Mein ftp proxy nach:    http://www.openbsd.org/faq/pf/ftp.html
    #nat-anchor "ftp-proxy/*"
    #rdr-anchor "ftp-proxy/*"
    #rdr on $Int proto tcp from any to any port 21 -> 127.0.0.1 \ port 8021
 
    ### FILTER ###
 
    # Zum Debuggen....
    #pass quick all             # Alles durchlassen
 
    # Generelle Block Regel
    block on $Ext
 
    # Freiwillig machen wir keinen mucks ;)
    block return log on $Ext
 
    # Wir wollen kein IPv6.0
    block quick inet6
 
    # Loopback Device darf alles
    pass quick on $Loop
 
    # IP Spoofing verhindern
    block in log quick on $Ext inet from <NoRoute> to any
    block in log quick on $Ext inet from any to <NoRoute>
 
    # Active FTP erlauben
    pass in quick on $Ext inet proto tcp from any to any port > 49151 user proxy flags S/SAFR keep state
 
    # Ping akzeptieren (ablehnen ist uebrigends wenig sinnvoll)
    pass in quick on $Ext inet proto icmp all icmp-type 8 code 0 keep state
 
    # Ports nach aussen oeffnen
    pass in quick on $Ext inet proto tcp from any to any port $InServicesTCP flags S/SAFR keep state label ServicesTCP
    
    #eMule Anker  
    anchor "passin/*"
 
    #ftp proxy Regel
    anchor "ftp-proxy/*"

    # Raus darf (fast) alles
    pass out quick on $Ext keep state queue (q_def,q_pri)
    #pass out quick on ($Ext) keep state

Ab und an taucht im dmesg folgender Fehler auf, aber nicht immer!!??!

[I]pppoe0: pap failure[/I]

Route show gibt das aus:

root@Zaphod:~\>route show
Routing tables

Internet:
Destination        Gateway            Flags   Refs      Use   Mtu  Prio Iface
default            0.0.0.1            UGS        0       33     -    48 pppoe0
loopback           localhost          UGRS       0        0 33204    48 lo0
localhost          localhost          UH         1        0 33204    48 lo0
192.168.0/24       link#2             UC         1        0     -    48 xl0
192.168.0.1        00:1a:4d:4b:d4:e0  UHLc       2      152     -    48 xl0
cras10k-sto1.netco xdsl-78-34-115-158 UH         0        0     -    48 pppoe0
BASE-ADDRESS.MCAST localhost          URS        0        0 33204    48 lo0

Internet6:
Destination        Gateway            Flags   Refs      Use   Mtu  Prio Iface
::/104             localhost.blue.sky UGRS       0        0     -    48 lo0

usw.

ifconfig das:

root@Zaphod:~\>ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33204
        groups: lo
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:30:05:21:32:96
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet6 fe80::230:5ff:fe21:3296%fxp0 prefixlen 64 scopeid 0x1
xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:50:04:6b:37:bd
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet 192.168.0.4 netmask 0xffffff00 broadcast 192.168.0.255
        inet6 fe80::250:4ff:fe6b:37bd%xl0 prefixlen 64 scopeid 0x2
enc0: flags=0<> mtu 1536
rum0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:1e:58:fe:74:4f
        groups: wlan
        media: IEEE802.11 autoselect
        status: no network
        ieee80211: nwid "" 100dBm
pppoe0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1492
        dev: fxp0 state: session
        sid: 0x3515 PADI retries: 0 PADR retries: 0 time: 00:05:40
        sppp: phase network authproto pap authname "XYZ@provider.de" 
        groups: pppoe egress
        inet6 fe80::230:5ff:fe21:3296%pppoe0 ->  prefixlen 64 scopeid 0x6
        inet 78.34.115.158 --> 213.196.239.106 netmask 0xffffffff

Ich benutze hostname.pppoe0 zur DSL Einwahl.


Noch seltsamer, obwohl es eben ging kann ich mich per Laptop nicht mehr mit PuTTy auf den OpenBSD Rechner verbinden.
PuTTY kriegt einen Connect hin fragt nach dem Usernamen (login as: ) und kommt nicht mehr wieder um ein Passwort abzufragen. (Connection timed out)

Im lokalem Netz?


Also die Thread hier am Anfang befolgt.

Die Firewall mit

pfctl –d

deaktiviert und einen

tcpdump

gemacht


Der tcpdump der externen Karte beim Ping auf die IP 193.0.0.193 der übrigens grade NICHT mehr geht ergab folgenden Dump:

03:49:48.794668 192.168.0.127 > 193.0.0.193: icmp: echo request
03:49:49.013622 192.168.0.127.3409 > 94.224.246.219.https: S 3650593396:3650593396(0) win 65535 <mss 1460,nop,nop,sackOK> (DF)
03:49:49.123148 192.168.0.127.3396 > 85.180.2.70.18090: S 2861261728:2861261728(0) win 65535 <mss 1460,nop,nop,sackOK> (DF)
03:49:49.889699 192.168.0.127.3398 > 94.224.246.219.www: S 2060373613:2060373613(0) win 65535 <mss 1460,nop,nop,sackOK> (DF)
03:49:50.327717 192.168.0.127.3399 > 86.22.101.3.61252: S 3416185555:3416185555(0) win 65535 <mss 1460,nop,nop,sackOK> (DF)
03:49:50.641415 Echo-Request, Magic-Number=804907822
03:49:50.641436 Echo-Reply, Magic-Number=385910138

Bin ziemlich verzweifelt.

Weiß jemand Rat?

MIKQ

 

[d4mi4n]

Stimmen deine Zugangsdaten?
pap bedeutet: Password Authentication Protocol

Edit: ja mit dem Lesen hab ichs nicht so. Pingen kannst ja nach draussen.
PAP Fehler habe ich damals unter m0n0 wärend einer DSL Störung bei der T-Com gesehen.

Wird bei dir immer nur diese eine Zeile ausgegeben?
"pppoe0: pap failure"

 

[Schläfer]

Geht denn die Verbindung vom Router in die weite Welt? Falls nicht würde ich routing und pf deaktivieren und userland-ppp anfeuern, da sieht man mehr (besser zum debuggen). Da siehst Du auch die Datenrate auf dem DSL-Link. Wenn das nicht vernuenftig geht, den Provider anhusten. Ich hatte aehnliche Probleme schon mit verschiedenen Providern, einwandfreie Verbindung zum Peer und ab da war dann Schicht.

Stimmt die Verkabelung im internen Netz? Hast Du da vernuenftige Uebertragunsgraten? Evtl. IP doppelt vergeben?

Was steht in der hostname.pppoe0?

 

[mapet]

ich hatte diese probleme mal, bis ich die MTU fest in der hostname.pppoe0 runtergeschraubt habe. bei dir sehe ich 1492. das hat bei mir nur mit der telekom funktioniert. versuche diese mal manuell in der config runterzudrücken, vielleicht gehts dann ja schon.

 

[MIKQ]

Vielen Dank für eure Hilfe!

Ich habe es gelöst in dem ich wieder per PPPOE(8) ins Netz gegangen bin.

Ich denke makenoob hatte recht und es war ein massives Problem mit der MTU Size.
Nochmals vielen Dank für diesen rettenden Hinweis!
Die aufgetretenen Fehler ließen aber alles vermuten, und waren teilweise so massiv dass ich Anfing an BSD zu zweifeln.

Leider gibt es kein mssfixup für PPPOE(4) und mir ist auch nicht bekannt wo und wie man die MTU Size erfolgreich setzen kann.

ifconfig –a

beharrte trotz

ifconfig destroy pppoe0

und

ifconfig create pppoe0

darauf dass die MTU Size für pppoe0 1492 zu sein hat und die anderen Devices wollten 1500 haben.
Die Windows Kisten haben völlig verrückt gespielt und maximal Google.de aufgerufen, aber so gut wie keine andere Webseite.

Ich denke ich habe noch ein paar Fehlermeldungen entschlüsselt und die will ich euch nicht vorenthalten:

pppoe0: pap failure

Falls meine Internetverbindung zum Provider noch besetzt war, durch die ganze Netwerkkabel Umsteckerei, gab pppoe0 gerne diesen Fehler aus.
Sollte im Prinzip nur heißen, ich bekomme keine Antwort dein DSL ist noch besetzt.

pfctl: SIOCGIFMTU: Device not configured.

Durch vergebliche Versuche in der hostname.pppoe0 die MTU Size zu setzen die PPPOE(4) nicht erkennt.


Ich habe jetzt in der /etc/ppp/ppp.conf folgendes stehen:

default:
<snip>

verbindungsname:
       set mtu max 1454    
       set mru max 1454     
        <snip>
       enable mssfixup

ist das nicht doppelt gemoppelt? Sollte nicht mssfixup schon dafür sorgen dass alles rund läuft?
Warum noch mal die mtu und mru setzen?

Gruß
MIKQ

 

[Schläfer]

Du weisst, dass kernel-ppp (ppp(4) bzw. pppoe(4)) und userland-ppp (die mit der 8) zwei vollkommen verschiedene Sachen sind, die nichts miteinander zu tun haben, ausser dass sie versuchen, das gleiche Problem zu lösen?

Ich habe jetzt in der /etc/ppp/ppp.conf folgendes stehen:

deafult:

Ich glaube Dir nicht, dass das so funktioniert.

<snip>

verbindungsname:
       set mtu max 1454    
       set mru max 1454     
        <snip>
       enable mssfixup

ist das nicht doppelt gemoppelt? Sollte nicht mssfixup schon dafür sorgen dass alles rund läuft?
Warum noch mal die mtu und mru setzen?

mtu/mru bestimmen die Groesse der ppp-frames.
mssfixup beeinflusst die Groesse der tcp-pakete (welche in diese Frames passen sollten).
Bei pppoe sollen mtu/mru nicht groesser sein als die nutzlast eines ethernet-frames. Wegen des ppp-overheads bleibt fuer TCP etc. noch etwas weniger Platz im Ethernetframe als ohne, dafuer is mssfixup. Das sind eher Optimierungen, funktioneren sollte es auch ohne, dann muessen frames bzw. Pakete halt geteilt werden.

Deine hostname.pppoe0 interessiert mich immer noch.

 

[MIKQ]

aber gern.
Welche Version darf es denn sein?
Hier die ohne meine MTU Versuche:

inet 0.0.0.0 255.255.255.255 NONE \
                   pppoedev fxp0 authproto pap \
                   authname 'XYZ@provider.de' authkey 'Passwort' up
           dest 0.0.0.1
           !/sbin/route add default -ifp pppoe0 0.0.0.1
           ! sh -c "/sbin/pfctl -e -F all -f /etc/pf.conf"

Zu Deiner Frage:
Jetzt ja. Bin leider immer noch BSD Anfänger. Zwei sehr unterschiedliche Programme (von Befehlen kann man ja fast nicht mehr sprechen) bis auf eine Nummer identisch zu nennen die sich dann in den man pages
eben nur um diese Nummer unterscheiden macht ganz schön Kopfschmerzen. Man hätte es ja auch upppoe für Userland pppoe nennen können....

 

[Schläfer]

Gemein, nichwa? Hat bei mir eine ganze Weile gedauert, bis ich das auseinandersortiert hatte.

hostname.pppoe0 sieht schick aus.
Wie kommst Du eigentlich auf pap? Die Provider, mit denen ich bisher zu tun hatte, fanden alle chap ganz toll. Eigentlich sollten das die beiden Peers auch alleine ausknobeln, vorausgesetzt Du gibst die auth-Daten an.

Falls das Problem persistiert, würde ich, wie gesagt, das Forwarding erstmal ganz unterbinden und die beiden Netze "drinnen" und "draussen" getrennt untersuchen, fuer draussen mit ppp(8), weil besser zum debuggen geeignet.

 

[MIKQ]

Ja, extrem gemein

Da ich den meisten Code nur zusammenklaue habe ich mir um die Authentifizierung einfach keine Gedanken gemacht.

Das war scheinbar nicht das Problem.
Ich bleibe jetzt erst mal beim Userland ppp das funktioniert wie eine Rakete und gibt ab und an auch wenigstens mal Hinweise aus.
Was Windooze zu viel an Meldungen in die Welt pustet untertreibt OpenBSD wieder... :-)

Gruß
MIKQ

 

[mapet]

so, da ich gestern bei einem großen belgischen provider auch massive probleme hatte, die mit der MTU zusammenhängen und damit MIKQ auch weiss, wie man die MTU festzurrt, hier mal das, was mir geholfen hat:

root@seanchan                                                           
~ # cat /etc/hostname.pppoe0                                                  
inet 0.0.0.0 255.255.255.255 0.0.0.1 pppoedev sis1 authproto pap authname <meinname> authkey geheim mtu 1450 up
!/sbin/route add default 0.0.0.1

das reichte aber alleine nicht. den rest muss aber dann pf machen (hab ich mal schamlos aus der misc@ gebuddelt):

scrub in on pppoe0 max-mss 1400 fragment reassemble
scrub out on pppoe0 max-mss 1400 no-df random-id fragment reassemble

vielleicht hiflts ja demnächst dem ein oder anderen weiter

 

[MIKQ]

Jetzt spinnen sie die Römer

Vielleicht kann mir dass versammelte Fachwissen eine Frage beantworten.

Habe jetzt schon zwei mal beobachten müssen dass sich mein OpenBSd Router weghängt, bzw. keinerlei Netzwerkverbindung zum Gerät möglich ist nachdem meine Windows Vista Workstation aus dem Standby „Energie Sparen“ aufgewacht ist und sich erneut versucht per WLAN an das rum Device anzumelden.

Messages gibt folgendes aus:

Mar  3 20:23:49 Zaphod ppp[29736]: tun0: Warning: 0.0.0.0/0: Change route failed: errno: No such process
Mar  3 20:23:49 Zaphod ppp[29736]: tun0: Warning: ff01:7::/32: Change route failed: errno: Network is unreachable
Mar  3 20:23:49 Zaphod ppp[29736]: tun0: Warning: ff02:7::/32: Change route failed: errno: Network is unreachable
Mar  3 20:23:49 Zaphod savecore: no core dump
Mar  3 20:23:50 Zaphod dhcpd[25105]: Can't listen on pflog0 - it has no IP address.
Mar  3 20:23:50 Zaphod dhcpd[25105]: Can't listen on bridge0 - it has no IP address.Mar  3 20:23:50 Zaphod dhcpd[25105]: Can't listen on rum0 - it has no IP address.
Mar  3 20:23:50 Zaphod dhcpd[25105]: Can't listen on fxp0 - it has no IP address

Außerdem habe ich trotz angeblicher 54MBit Verbindung Übertragungsraten von 70 KB !

Wo und wie kann ich diesen Fehlern auf die Spur kommen?

Gruß
MIKQ

 

[MIKQ]

Ob, diesen Fehlermeldungen konnte ich auf den Grund gehen.
Wie IHR sicherlich wisst und ich jetzt auch muss ich seit der Version 4.4 den dhcpd auf eine Netzwerkkarte binden wenn ich nicht will dass er auf jeder aktiven Netzwerkkarte versucht DHCP Leases zu verteilen.

Am sinnvollsten geht dass über die rc.conf.local

dhcpd_flags="xl0"

Ich werde mal weiter beobachten ob sich mein 4.4er seltsam verhält.
Selten so ein OpenBSD Release gesehen dass ich so „zickig“ verhält…

MIKQ

 

[mapet]

eigentlich ist der dhcpd schlau genug, sich nur an die karten zu hängen, die eine ip haben UND deren netz auch in der dhcpd.conf angegeben ist. aus genau diesem grund ist es seit 4.4 eigentlich nicht mehr nötig, dem dhcpd das interface mitzugeben, wo es vorher notwendig war.

 

[d4mi4n]

Oh ah, ich wollte doch längst mal das Tutorial im Wiki anpassen. Momentan nutze ich noch 3.8... Wenn ich meinen Router mal update passe ich die Sachen an, es sei denn jemand Anderes ist schneller

 

[mapet]

3.8? das ist wie lange EOL? nuja, hab meinen zu hause auch noch auf 4.3 laufen und bin noch net zu nem hochziehen auf ein aktuelles STABLE gekommen

 

[d4mi4n]

3.8? das ist wie lange EOL? nuja, hab meinen zu hause auch noch auf 4.3 laufen und bin noch net zu nem hochziehen auf ein aktuelles STABLE gekommen

Ähm......

# uname -a
OpenBSD knarsch 4.2 GENERIC#375 i386

Ich bin ein bisl blöd, warum ich 3.8 geschrieben habe kann ich nicht erklären...

 

[MIKQ]

Meinung gefragt

Was die dhcpd Einstellungen angeht habe ich das HowTo schon aktualisiert.
Würde aber gerne Wissen ob die Damen und Herren meine Konfiguration die ich gerne ins HowTo übertragen würde begutachten und als sicher genug oder eben nicht klassifizieren?
Konstruktive Kritik ist immer willkommen.
Der Thread findet sich hier.

MIKQ

 

[mark05]

hi

grosses kino hier .....

das kann nicht gehen weil
a: statisches nat .(nat regel sollte in der form (nat on wan_if from any to any) sein
siehe man pf.conf

b: <noRoute> er benutzt ein netz 192.xxx was per <noRoute> geblockt wird. ( desweiteren sollte localhost oder 127.0.0. da raus )

c: das mtu thema kann per set im ppp gesetzt werden., falls du den kernel
pppoe benutzt siehe man pppoe .
desweiteren sollte im regelfile fuer die fw sowas wie

scrub out on pppoe0 max-mss 1440

stehen siehe auh man 4 pppoe

holger

 

[Elwood]

MIKQ: Stell dein Howto doch einfach ins Wiki. Mit dem Hinweis, daß du noch nicht sicher bist, ob es 100% in Ordnung ist oder nicht. Es bietet dann den Anderen die Möglichkeit Änderung beizusteuern.