[uisge]

JFTR: Nach meinen gegenwärtigen Untersuchungen kristallisiert sich eine Kombination aus ausgehenden tcp6-Paketen und 9.1-RELEASE Firewall heraus. 9.0-RELEASE läuft einwandfrei.

JFTR: Das Problem ist gelöst, es war eine Konfiguration der PF-Firewall, die seit FreeBSD 9.1 zum beschriebenen Problem mit ausgehendem tcp6 führt:

Statt der alten Regel ...

pass out log on $extIF inet6 proto {tcp, udp, icmp6, gre} all modulate state

... muß nun die neue Regel lauten:

pass out log on $extIF inet6 proto {tcp, udp, icmp6, gre} all

Auch wenn's noch etwas früh ist: Ich wünsche allerseits einen guten Rutsch!

[uisge]

Nun meine Fragen:

- Könnte das jemand mit Linux-Rechnern überprüfen, um einen Bug hinsichtlich FreeBSD ausschließen zu können?
- Hat jemand mit älteren FreeBSD-Versionen ein vergleichbares Problem?
- Kann jemand mit mehr Erfahrung den netstat Dump auf Probleme hinsichtlich Routing überprüfen?
- Ideen?

JFTR: Nach meinen gegenwärtigen Untersuchungen kristallisiert sich eine Kombination aus ausgehenden tcp6-Paketen und 9.1-RELEASE Firewall heraus. 9.0-RELEASE läuft einwandfrei.

Bin aber weiterhin auf Feedback ebenfalls Betroffener interessiert.

[uisge]

Moin, moin --

Drei Rechner in Roubaix können untereinander kein TCP über IPv6. (UDP geht!). Alle Rechner laufen unter FreeBSD 9.1-RELEASE.

Hier der relevante Teil der IPv6-Konfiguration:

# IPv6 configuration (from OVH installer)
ipv6_static_routes="ovhgw"
ipv6_route_ovhgw="2001:41d0:a:bbff:ff:ff:ff:ff -prefixlen 128 -interface em0"
ipv6_defaultrouter="2001:41d0:a:bbff:ff:ff:ff:ff"
# OVH installer (end)
ipv6_activate_all_interfaces="YES"
ipv6_gateway_enable="YES"
ifconfig_em0_ipv6="inet6 2001:41d0:a:bbcc::1 prefixlen 56"
ifconfig_em0_alias0="inet6 2001:41d0:a:bbcc:1::1 prefixlen 56"

Ich habe demnach die Konfiguration des OVH-Installers unverändert übenommen und nur zwei IPv6-Adressen zum Interface hinzugefügt. Das ergibt dann:

> netstat -nr
...
Internet6:
Destination                       Gateway                       Flags      Netif Expire
::/96                             ::1                           UGRS        lo0 =>
default                           2001:41d0:a:bbff:ff:ff:ff:ff  UGS         em0
::1                               link#4                        UH          lo0
::ffff:0.0.0.0/96                 ::1                           UGRS        lo0
2001:41d0:a:bb00::/56             link#1                        U           em0
2001:41d0:a:bbcc::1               link#1                        UHS         lo0
2001:41d0:a:bbcc:1::1             link#1                        UHS         lo0
2001:41d0:a:bbff:ff:ff:ff:ff      xx:xx:xx:xx:xx:xx             UHS         em0
fe80::/10                         ::1                           UGRS        lo0
fe80::%em0/64                     link#1                        U           em0
fe80::3a60:77ff:fe3e:a02b%em0     link#1                        UHS         lo0
fe80::%lo0/64                     link#4                        U           lo0
fe80::1%lo0                       link#4                        UHS         lo0
ff01::%em0/32                     fe80::3a60:77ff:fe3e:xxxx%em0 U           em0
ff01::%lo0/32                     ::1                           U           lo0
ff02::/16                         ::1                           UGRS        lo0
ff02::%em0/32                     fe80::3a60:77ff:fe3e:xxxx%em0 U           em0
ff02::%lo0/32                     ::1                           U           lo0

Mit einem "nc -6vw 1 2001:41d0:a:ddee:1::1 53" (anderer Server im OVH-Netz) erhalte ich timeouts. Laut tcpdump sind das checksum errors, wie bspw.:

00:00:02.066251 xx:xx:xx:xx:xx > yy:yy:yy:yy:yy, ethertype IPv6 (0x86dd), length 94: (flowlabel 0xa3c71, hlim 63, next-header TCP (6) payload length: 40) 2001:41d0:a:bbcc::1.64158 > 2001:41d0:a:ddee:1::1.53: Flags [S], cksum 0x959b (incorrect -> 0x58f9), seq 3833155181, win 65535, options [mss 1440,nop,wscale 6,sackOK,TS val 495939599 ecr 0], length 0

Interessanterweise kann ich alle Server mittels UDP über IPv6 ohne Fehler erreichen "nc -6uvw 1 2001:41d0:a:ddee:1::1 53".

Was ich aber nun ganz und gar nicht mehr verstehe, ist der Umstand, daß ich alle drei Server von einem Server außerhalb des OVH-Netzes mit der eben beschriebenen Methode anstandslos hinsichtlich tcp6 erreiche:

00:00:00.000042 xx:xx:xx:xx:xx:xx > yy:yy:yy:yy:yy:yy, ethertype IPv6 (0x86dd), length 94: (class 0x0d, flowlabel 0x0dbd6, hlim 64, next-header TCP (6) payload length: 40) 2001:41d0:a:bbcc:1::1.53 > 2001:bfxx:yyyy:zzzz::1:123.43247: Flags [S.], cksum 0xa0f9 (correct), seq 290304835, ack 1527265267, win 65535, options [mss 1440,nop,wscale 6,sackOK,TS val 360033388 ecr 76811438], length 0
00:00:00.000026 xx:xx:xx:xx:xx:xx > yy:yy:yy:yy:yy:yy, ethertype IPv6 (0x86dd), length 86: (flowlabel 0x0dbd6, hlim 64, next-header TCP (6) payload length: 32) 2001:41d0:a:bbcc:1::1.53 > 2001:bfxx:yyyy:zzzz::1:123.43247: Flags [.], cksum 0xb30f (correct), seq 1, ack 2, win 1026, options [nop,nop,TS val 360038429 ecr 76812699], length 0
00:00:00.000027 xx:xx:xx:xx:xx:xx > yy:yy:yy:yy:yy:yy, ethertype IPv6 (0x86dd), length 86: (flowlabel 0x0dbd6, hlim 64, next-header TCP (6) payload length: 32) 2001:41d0:a:bbcc:1::1.53 > 2001:bfxx:yyyy:zzzz::1:123.43247: Flags [F.], cksum 0xb30e (correct), seq 1, ack 2, win 1026, options [nop,nop,TS val 360038429 ecr 76812699], length 0

Nun meine Fragen:

- Könnte das jemand mit Linux-Rechnern überprüfen, um einen Bug hinsichtlich FreeBSD ausschließen zu können?
- Hat jemand mit älteren FreeBSD-Versionen ein vergleichbares Problem?
- Kann jemand mit mehr Erfahrung den netstat Dump auf Probleme hinsichtlich Routing überprüfen?
- Ideen?

Schon einmal vielen Dank.