OpenBSD-Router: keine Verbindung ins Inet möglich

yggdrasil

Well-Known Member
Servus,

nach einiger Zeit mit Monowall/Smallwall will ich endlich wieder einen OpenBSD-Router aufsetzen. War in der Vergangenheit ja immer recht trivial, das Monowall-Intermezzo war mehr Faulheit geschuldet. Aber heute ist irgendwie durchgehend der Wurm drin, daher bitte ich einfach mal weitere Augen hier drüber zu schauen, wo ich scheiße gebaut hab.

Situation: Telekom VDSL, wobei derzeit noch das VLAN-Tag im Modem (Vigor 130) gesetzt wird. Das Alix-Board mit Smallwall tut wunderbar, wenn ich auf das andere Board mit OpenBSD wechsle kann er zwar die PPPoE-Verbindung aufbauen, aber ich kann von der Box selbst schon nicht rauskommen. Ich glaub, ich hab irgendwo n Hirnfurz und übersehe was offensichtliches. Hier meine Konfiguration:

hostname.vr0
Code:
10.0.0.1 netmask 255.255.0.0 up

hostname.vr1
Code:
172.16.0.2 netmask 255.255.255.0 up
(Modem hat hier 172.16.0.1, ich kann auch per wget die Loginseite des Modems laden etc.)

hostname.pppoe0
Code:
#inet6 eui64
inet 0.0.0.0 255.255.255.255 NONE mtu 1442 pppoedev vr1 authproto pap authname 'blablubb#0001@t-online.de' authkey 'blablubb' up
dest 0.0.0.1
!/sbin/route add default -ifp pppoe0 0.0.0.1
#!/sbin/route add default -ifp pppoe0 fe80::
(Habe die mtu testhalber eingeführt, keine Änderung ohne)

pf.conf
Code:
set skip on lo

block return
pass

pass out on pppoe0 inet from vr0:network to any nat-to (pppoe0)

# route show
Code:
Routing tables

Internet:
Destination        Gateway            Flags   Refs      Use   Mtu  Prio Iface
default            0.0.0.1            UGS        1      182     -     8 pppoe0
10.0/16            10.0.0.1           UC         0        0     -     8 vr0  
10.0.0.1           00:0d:b9:1a:7e:c4  UHLl       0        0     -     1 lo0  
10.0.255.255       10.0.0.1           UHb        0        0     -     1 vr0  
80.<EXT_IP>        80.<EXT_IP>        UHl        0        0     -     1 lo0  
loopback           localhost          UGRS       0        0 32768     8 lo0  
localhost          localhost          UHl        0        0 32768     1 lo0  
172.16.0/24        172.16.0.2         UC         1        0     -     8 vr1  
172.16.0.1         00:1d:aa:86:e8:7c  UHLc       0        0     -     8 vr1  
172.16.0.2         00:0d:b9:1a:7e:c5  UHLl       0        0     -     1 lo0  
172.16.0.255       172.16.0.2         UHb        0        0     -     1 vr1  
217.<TKOM_IP>        80.<EXT_IP>        UH         0        3     -     8 pppoe0
BASE-ADDRESS.MCAST localhost          URS        0        0 32768     8 lo0
(route show ist besonders nervig weil jede einzelne Zeile mehrere Minuten braucht, das macht debugging nicht gerade einfacher. EXT_IP ist meine externe IP, TKOM_IP ist Telekoms PPP-Endpunkt)

# arp <IP_ADRESSE EINES SERVERS IM INET>
Code:
Host                                 Ethernet Address   Netif Expire     Flags
<IP>                          no entry

sysctl.conf
Code:
net.inet.ip.forwarding=1

rc.conf.local
Code:
dnscrypt_proxy_flags=-l /dev/null -R dnscrypt.me -a 127.0.0.1@40
ftpproxy_flags=
ntpd_flags="-s"
pkg_scripts=dnscrypt_proxy
unbound_flags=

# pfctl -s rules
Code:
block return all
pass all flags S/SA
pass out on pppoe0 inet from 10.0.0.0/16 to any flags S/SA nat-to (pppoe0) round-robin
 
The Fuck?! Gerade hab ich einfach mal so die Kiste genau so wie sie ist nochmal angestöpselt, jetzt tut's?! Ich hab definitiv keine Konfig geändert und vorhin schon mehrfach zur Sicherheit neu gestartet. Ich bin zutiefst verwirrt...
 
(route show ist besonders nervig weil jede einzelne Zeile mehrere Minuten braucht, das macht debugging nicht gerade einfacher. EXT_IP ist meine externe IP, TKOM_IP ist Telekoms PPP-Endpunkt)
route -n show

# arp <IP_ADRESSE EINES SERVERS IM INET>
Ist ansich schon Käse, weil ARP für dich nur im lokalen Segment eine Rolle spielt.

Code:
dnscrypt_proxy_flags=-l /dev/null -R dnscrypt.me -a 127.0.0.1@40
ftpproxy_flags=
ntpd_flags="-s"
pkg_scripts=dnscrypt_proxy
unbound_flags=
Argumente mit Leerzeichen besser in "" fassen.

Ansonsten deuten die Verzögerungen bei route show (ohne -n) darauf hin, dass mit der DNS-Auflösung was nicht passt(e). Ich weiß nicht, was dnscrypt genau macht, aber evtl. lag es daran. Edit: Da -R dnscrypt.me anscheinend bedeutet, dass du dich für simple DNS-Anfragen von einem externen Dienst abhängig machst (wer braucht sowas?), kann das gut sein, dass dieser zu der Zeit nicht erreichbar war. Das würde zu den Symptomen passen.
 
Das Grundlegendste habe ich natürlich übersehen: Was heißt eigtl. "nicht rauskommen"? ping 8.8.8.8 z.B. hätte funktionieren müssen.
 
Hab ich dann auch rausgefunden

Ist ansich schon Käse, weil ARP für dich nur im lokalen Segment eine Rolle spielt.
Ich dachte aus irgend einem Grund, dass ich zumindest für die PPP-Gegenstelle einen ARP-Eintrag haben müßte, warum auch immer ich da drauf gekommen bin.

Argumente mit Leerzeichen besser in "" fassen.
Stammt alles von rcctl. Aber ich finde es auch seltsam, dass rcctl das nicht automatisch macht.

Edit: Da -R dnscrypt.me anscheinend bedeutet, dass du dich für simple DNS-Anfragen von einem externen Dienst abhängig machst (wer braucht sowas?)
Äh, was? Du bist für DNS immer von nem Dienst abhängig, sei es von deinem ISP, Google, oder was auch immer. Einen DNSCrypt-fähigen Resolver des OpenNIC-Projektes ist mir da lieber als Google, oder die grottigen Telekom-DNS-Server, die statt anständiger Fehlermeldungen auf ne "Haben Sie sich vielleicht vertippt?"-Seite umleiten.

Aber generell: dass mein lokaler DNS-Cache noch nicht so richtig tut wie ich das will ist mir schon klar. Aber um Namensauflösung ging es ja nicht. Irgendwie hab ich bei dreimal korrekturlesen nicht gemerkt, dass ich nirgends schrieb, dass es mir in der Tat um ein simples "ping <IP>" ging, nicht "ping <DOMAIN>". Sorry dafür. Nach wie vor keine Ahnung, was da los war.

TCM, ich hab beim recherchieren nach Telekom + IPv6 + OpenBSD deinen alten Thread gefunden, der genau das thematisiert. Weißt du wie hier der aktuelle Stand ist, da ein (recht simpler) Test meinerseits nicht zu einer v6-Zuweisung von Telekomseite führt.
 
oder die grottigen Telekom-DNS-Server, die statt anständiger Fehlermeldungen auf ne "Haben Sie sich vielleicht vertippt?"-Seite umleiten
Dieses Verhalten der DNS Server ist für deinen Anschluss konfigurierbar. Das Kundencenter lässt dich die Einstellung auf die klassisch korrekte Fehlerbehandlung vornehmen. Nichtsdestotrotz verweisen die T DNS Server nicht immer auf die performantesten Server bei CDNs.
 
Idealerweise nimmt man natürlich einen lokalen rekursiven Resolver und gar keinen externen.

Ich hab für pppoe0 "inet6 autoconf" konfiguriert, und zwar vor "inet 0.0.0.0/32", da inet das Interface sofort hochbringt und das Interface beim Hochkommen eine IPv6-Adresse haben muss, sonst macht der Kernel kein IPV6CP. Dann sollte das Interface ein /64 kriegen und man kann sich daraufhin mit DHCPv6 das /56 holen.

Code:
pppoedev vlan7 authproto pap authname '...' authkey '...'

inet6 autoconf autoconfprivacy
# XXX: man page says fe80:: ?
#!route add -inet6 -label default -ifp ${if} default ::1
!route add -inet6 -label default -ifp ${if} default fe80::

inet 0.0.0.0/32
dest 0.0.0.1
!route add -inet  -label default -ifp ${if} default 0.0.0.1

Ergibt:

Code:
[...]
  inet6 fe80::[...]%pppoe0 ->  prefixlen 64 scopeid 0xd
  inet [...] netmask 0xffffffff
  inet6 [...] ->  prefixlen 64 autoconf pltime 1469 vltime 14069
  inet6 [...]:9c2a:204:28f3:3f62 ->  prefixlen 64 deprecated autoconf autoconfprivacy pltime 0 vltime 1612
  inet6 [...]:486e:f0a4:c6f4:2fcf ->  prefixlen 64 deprecated autoconf autoconfprivacy pltime 0 vltime 3869
  inet6 [...]:58d4:261:fc5c:23e6 ->  prefixlen 64 deprecated autoconf autoconfprivacy pltime 0 vltime 6121
  inet6 [...]:48fa:15df:827c:fc89 ->  prefixlen 64 deprecated autoconf autoconfprivacy pltime 0 vltime 8367
  inet6 [...]:4c7d:4e9d:fbd:a4f2 ->  prefixlen 64 deprecated autoconf autoconfprivacy pltime 0 vltime 10681
  inet6 [...]:3060:2962:4993:a581 ->  prefixlen 64 autoconf autoconfprivacy pltime 316 vltime 12916
 
Danke TCM, das scheint in der Tat zu tun. Weißt du zufällig, was genau der Sinn der zwei Netzte ist, die die Telekom uns gibt (das /64 und das /56)? Bei meinem letzten Anbieter wars einfach ein einzelnes /48.

Idealerweise nimmt man natürlich einen lokalen rekursiven Resolver und gar keinen externen.
Das war früher immer mein Setup. Aber der hämmert doch dann immer direkt auf die Root-Server ein, oder nicht? DNS ist jetzt nicht gerade mein Spezialgebiet, aber sollte es nicht so ähnlich sein wie bei NTP-Servern? Man läßt Stratum 0/die Rootserver in Frieden und nutzt Resolver in höheren Strata?
 
Das macht glaub ich nicht viel Unterschied, ob jetzt /64+/56 oder ein Block am Stück. "Ist halt so" fällt mir nur ein.

Zum Anderen: die Rootserver sind ja nicht rekursiv. Die fragst du quasi einmal alle 2 Wochen, welche Server alle für z.B. .net zuständig sind und dann hangelt sich dein Resolver entsprechend weiter. Dafür bist du von nichts weiter abhängig.
 
Boah, die Woche fängt ja schon gut an. Erst hängt sich Firefox komplett unbenutzbar auf, was zu stundenlangem Fehlersuchen führt, jetzt hab ich auch noch folgendes seltsame Verhalten:
Manche (wenige) Seiten laden nicht oder nur unvollständig. Vom Verhalten her war der erste Gedanke "MTU zu hoch?!", auch wenn mir das schon etwas seltsam vorkam. Zwar wurde es besser mit geringerer MTU auf dem pppoe0 device, aber ich scheine bestenfalls an einem Symptom rumzudoktorn. Momentan kann ich z.B. www.cracked.com nicht vom Netzwerk aus laden, wohl aber vom Router selbst aus?!

Wenn ich auf einem Rechner im Netz ein "wget www.cracked.com" absetze bleibt das bei
Code:
Resolving www.cracked.com (www.cracked.com)... 93.184.220.20
Connecting to www.cracked.com (www.cracked.com)|93.184.220.20|:80... connected.
HTTP request sent, awaiting response...
stehen.

tcpdump auf'm Router sagt folgendes:

# tcpdump -i pppoe0 host www.cracked.com
Code:
tcpdump: listening on pppoe0, link-type PPP_ETHER
20:33:52.760780 80<EXT_IP>.50540 > 93.184.220.20.www: S 948591678:948591678(0) win 65535 <mss 1440,nop,wscale 6,sackOK,timestamp 1220556 0> (DF)
20:33:52.780083 93.184.220.20.www > 80<EXT_IP>.50540: S 1124377396:1124377396(0) ack 948591679 win 65535 <mss 1460,sackOK,timestamp 2608130809 1220556,nop,wscale 9> (DF)
20:33:52.780375 80<EXT_IP>.50540 > 93.184.220.20.www: . ack 1 win 1026 <nop,nop,timestamp 1220576 2608130809> (DF)
20:33:52.780382 80<EXT_IP>.50540 > 93.184.220.20.www: P 1:145(144) ack 1 win 1026 <nop,nop,timestamp 1220576 2608130809> (DF)
20:33:52.799866 93.184.220.20.www > 80<EXT_IP>.50540: . ack 145 win 285 <nop,nop,timestamp 2608130814 1220576> (DF)
                        [[ hier Strg-C im wget ]]
20:34:29.264253 80<EXT_IP>.50540 > 93.184.220.20.www: F 145:145(0) ack 1 win 1026 <nop,nop,timestamp 1257041 2608130814> (DF)
20:34:29.283610 93.184.220.20.www > 80<EXT_IP>.50540: . ack 146 win 285 <nop,nop,timestamp 2608139935 1257041> (DF)

(vr0 ist das interne IF des Routers)
# tcpdump -i vr0 host www.cracked.com
Code:
tcpdump: listening on vr0, link-type EN10MB
20:33:52.760621 10.0.1.1.18745 > 93.184.220.20.www: S 948591678:948591678(0) win 65535 <mss 1460,nop,wscale 6,sackOK,timestamp 1220556 0> (DF)
20:33:52.780130 93.184.220.20.www > 10.0.1.1.18745: S 1124377396:1124377396(0) ack 948591679 win 65535 <mss 1440,sackOK,timestamp 2608130809 1220556,nop,wscale 9> (DF)
20:33:52.780273 10.0.1.1.18745 > 93.184.220.20.www: . ack 1 win 1026 <nop,nop,timestamp 1220576 2608130809> (DF)
20:33:52.780301 10.0.1.1.18745 > 93.184.220.20.www: P 1:145(144) ack 1 win 1026 <nop,nop,timestamp 1220576 2608130809> (DF)
20:33:52.799901 93.184.220.20.www > 10.0.1.1.18745: . ack 145 win 285 <nop,nop,timestamp 2608130814 1220576> (DF)
                        [[ hier Strg-C im wget ]]
20:34:29.264139 10.0.1.1.18745 > 93.184.220.20.www: F 145:145(0) ack 1 win 1026 <nop,nop,timestamp 1257041 2608130814> (DF)
20:34:29.283651 93.184.220.20.www > 10.0.1.1.18745: . ack 146 win 285 <nop,nop,timestamp 2608139935 1257041> (DF)

Auf dem Rechner im Netz, der das wget absetzt:
# tcpdump -i re0 host www.cracked.com
Code:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re0, link-type EN10MB (Ethernet), capture size 65535 bytes
21:02:49.488335 IP 10.0.1.1.50335 > 93.184.220.20.http: Flags [S], seq 1611167941, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 2956843 ecr 0], length 0
21:02:49.508099 IP 93.184.220.20.http > 10.0.1.1.50335: Flags [S.], seq 2459649116, ack 1611167942, win 65535, options [mss 1440,sackOK,TS val 713481870 ecr 2956843,nop,wscale 9], length 0
21:02:49.508119 IP 10.0.1.1.50335 > 93.184.220.20.http: Flags [.], ack 1, win 1026, options [nop,nop,TS val 2956863 ecr 713481870], length 0
21:02:49.508146 IP 10.0.1.1.50335 > 93.184.220.20.http: Flags [P.], seq 1:145, ack 1, win 1026, options [nop,nop,TS val 2956863 ecr 713481870], length 144
21:02:49.528445 IP 93.184.220.20.http > 10.0.1.1.50335: Flags [.], ack 145, win 285, options [nop,nop,TS val 713481875 ecr 2956863], length 0
                        [[ hier Strg-C im wget ]]
21:03:18.318349 IP 10.0.1.1.50335 > 93.184.220.20.http: Flags [F.], seq 145, ack 1, win 1026, options [nop,nop,TS val 2985673 ecr 713481875], length 0
21:03:18.338042 IP 93.184.220.20.http > 10.0.1.1.50335: Flags [.], ack 146, win 285, options [nop,nop,TS val 713489077 ecr 2985673], length 0


pf.conf
Code:
set skip on lo

block return log
pass log

match on pppoe0 all scrub (max-mss 1440)

pass on vr0 inet proto tcp from vr0:network to vr0
pass out log on pppoe0 inet from vr0:network to any nat-to (pppoe0)

Die MTU auf pppoe0 ist momentan 1464.

Ich steh total auf'm Schlauch. Jegliche Hinweise werden dankend angenommen.
 
Bei mir hat pppoe0 die MTU 1492 (automatisch ohne explizite Konfig.) und pf.conf setzt max-mss auf 1452 und ich hab keine Probleme.
 
Da kann es auch definitiv nicht dran liegen, das war nur ein weiterer Hirnfurz meinerseits (die letzten Tage sind irgendwie voll davon...). Gerade die alte Monowall wieder drangehängt, jetzt geht alles wieder wunderbar. Muß also definitiv an irgendeiner Einstellung des OpenBSD-Routers liegen. Oder die Hardware geht an Arsch, aber das glaube ich erstmal nicht.
 
jmt: ja, sind ALIX-Boards, aber warum ist das relevant? Die Smallwall läuft auf nem 2d3 (Variante mit 3x Ethernet), OpenBSD auf nem (galub ich) 2d2 mit 2x Ethernet.

TCM: Auf dem SmallWall kann man das leider net so wirklich einsehen, da es kein pfctl zu geben scheint, mit dem ich das aktuelle Ruleset ausgeben könnte. Weiß daher die max-mss nicht, order ob SmallWall da überhaupt eine setzt. Aber laut ifconfig ist eine MTU von 1492 gesetzt. Standard halt.
 
Ja sag mal, ich glaub ich spinn jetzt total. Gerade den OpenBSD-Router wieder angeschlossen, mtu aus pppoe0 rausgenommen (wird ja dann automatisch auf 1492 gesetzt), jetzt scheints zu laufen mit der scrub-Regel von oben (max-mss 1440). Also wieder alles wie vorher, als es nicht tat. Leute, ich weiß auch nicht was hier die letzten Tage los ist, aber ich glaube ich geh erstmal meine IT mit Weihwasser besprühen... Vielen Dank jedenfalls für die Hilfestellungen.
 
Code:
pppoedev vlan7 authproto pap authname '...' authkey '...'

inet6 autoconf autoconfprivacy
# XXX: man page says fe80:: ?
#!route add -inet6 -label default -ifp ${if} default ::1
!route add -inet6 -label default -ifp ${if} default fe80::

inet 0.0.0.0/32
dest 0.0.0.1
!route add -inet  -label default -ifp ${if} default 0.0.0.1

An der Stelle muss ich mich mal korrigieren. Da sind teilweise Änderungen drin, die ich im laufenden Betrieb gemacht habe und die so tatsächlich gar nicht funktionieren (Danke OpenBSD!)

"inet6 autoconf autoconfprivacy" funktioniert in der Shell, aber nicht in hostname.if(5), weil dort das autoconfprivacy als Netzmaske interpretiert wird (gibt Sinn, oder? /facepalm). Beim Studieren von /etc/netstart musste ich mich an der Stelle leicht übergeben, als ich das absolute Gefrickel dazu gesehen habe. Einfach die Zeilen 1:1 an ifconfig anhängen war anscheinend zu einfach.

Muss also lauten:
Code:
inet6 autoconf
inet6 autoconfprivacy

Desweiteren ist eine Defaultroute für IPv6 völlig überflüssig. Diese wird im Rahmen von autoconf automatisch gesetzt. Letztendlich also:
Code:
pppoedev vlan7 authproto pap authname '...' authkey '...'

inet6 autoconf
# inet6 in der nächsten Zeile eigtl. optional
inet6 autoconfprivacy

inet 0.0.0.0/32
dest 0.0.0.1
!route add -inet -label default -ifp ${if} default 0.0.0.1
 
Ja, das mit autoconfprivacy ist mir auch schon aufgefallen, danke für deine Ergänzungen.

Mein Problem von oben, daß ich periodisch auf manche IPs nicht zugreifen kann scheint gerade wieder aufzutreten. Vorhin war es ovh.de/com (hab da nen Billigst-Spielwiesen-Server), jetzt gerade ist es dragonflydigest.com. Wie zuvor kann ich den Hostnamen in IP auflösen, kann aber nicht auf die IP verbinden. Von woanders (anderer Server in nem RZ) krieg ich immer problemlos ein wget <problematischedomain> hin. Hab leider zu spät dran gedacht nen traceroute zu starten.
Bevor ich jetzt die Hardware des Routers angehe und da dran rumschraube: Hat das so schonmal jemand erlebt? Ich meine, auf dem Router zeigt die Route für die problematischen Domains immer korrekt an (interface pppoe0, gateway die ppp-gegenstelle), woran kann das jetzt noch liegen? Abgesehen von Problemen im Telekomnetz, was ich aber erstmal ausschließen will.
 
Zurück
Oben