So übermäßig anspruchsvoll ist es eigentlich gar nicht, was ich versuche. Es geht um eine ganz normale Vernetzung von verschiedenen Standorten per VPN. Allerdings soll aus $Gründen eine Vernetzung über die VPN-Funktionalität der Fritzboxen (IPsec) stattfinden, nicht (mehr) über z. B. OpenVPN. Zu diesem Zweck sollten die Fritzboxen die PPPoE-Session terminieren/direkten Internetzugang haben (sonst ist das mit IPsec ggf. Essig).
Im Prinzip tut das bei AVMs Fritzboxen auch schnuckelig – zumindest, was die direkt verbundenen Netze angeht. Mein aktuelles Problem: die Verbindung 7270 (Berlin) zu 7570 (Gütersloh) funktioniert, auch von den angeschlossenen Netzen; von einem komischeen Effekt des Fritz-IPsec-VPNs abgesehen — die Antworten kommen immer von der Ziel-IP. Aber im Prinzip funktioniert’s:
(VoIP-Fritzbox in GT) # traceroute greebo.berlin.uu.org traceroute to greebo.berlin.uu.org (193.26.120.116), 30 hops max, 38 byte packets 1 192.168.5.245 (192.168.5.245) 11.873 ms 0.912 ms 0.612 ms 2 FB-DSL-GTSO.uu.org (192.168.177.1) 2.016 ms 1.029 ms 0.919 ms 3 greebo.berlin.uu.org (193.26.120.116) 62.780 ms 65.228 ms 58.857 ms 4 greebo.berlin.uu.org (193.26.120.116) 60.892 ms 83.577 ms 59.314 ms 5 greebo.berlin.uu.org (193.26.120.116) 59.414 ms 80.942 ms 59.454 ms
wusel@greebo.berlin.uu.org:~$ traceroute 192.168.5.229 traceroute to 192.168.5.229 (192.168.5.229), 64 hops max, 40 byte packets 1 gw.berlin.uu.org (193.26.120.113) 0 ms 0 ms 0 ms 2 fritz.box (192.168.178.1) 1 ms 1 ms 1 ms 3 FB-7170-1.uu.org (192.168.5.229) 74 ms 59 ms 59 ms 4 FB-7170-1.uu.org (192.168.5.229) 62 ms 59 ms 61 ms 5 FB-7170-1.uu.org (192.168.5.229) 74 ms 60 ms 59 ms
Was derzeit aber nicht funktioniert, ist die zweite Verbindung an der 7570, also die der 7170 im Office mit der 7570 zu Hause:
(VoIP-Fritzbox in GT) # traceroute 192.168.45.25 traceroute to 192.168.45.25 (192.168.45.25), 30 hops max, 38 byte packets 1 192.168.5.245 (192.168.5.245) 0.816 ms 0.616 ms 0.615 ms 2 FB-DSL-GTSO.uu.org (192.168.177.1) 1.174 ms 1.065 ms 1.160 ms 3 HP4050N.sld.tld (192.168.45.25) 76.193 ms 76.462 ms 75.250 ms 4 HP4050N.sld.tld (192.168.45.25) 107.226 ms 78.095 ms 101.281 ms
(FB 7170 im Office) # traceroute -m 8 192.168.5.229 traceroute to 192.168.5.229 (192.168.5.229), 8 hops max, 38 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * *
Verbinden zur 7170 kann ich mich, auch aus den hinter der 7570 liegenden Netzen. Aus dem Office allerdings: Pustekuchen. Konsequenterweise geht auch die SIP-Registrierung der Office-FB an meiner VoIP-FB nicht, was einerseits Sinn der Übung war und dafür spricht, daß der Traffic nicht durchgelassen wird. Nur: wo wird das geblockt‽ Ich sehe jetzt den Wald vor lauter Bäumen nicht mehr – oder die 7170 ist grundlegend anders als die 72er-Serie (7570 ist 7270+VDSL-Modem). Auch der Versuch, nur 1 VPN in der 7570 zu definieren (7170-7570) änderte nichts am Verhalten, sodaß ich davon ausgehe, daß es damit nichts zu tun hat. Plöd, das; die erste Verbindung war richtig flott aufgesetzt, langwierig war nur, das Konfigurationsprogramm mit WINE an den Start zu bekommen.
Vielleicht sieht ja wer einen/den(?) offensichtlicht(??) Fehler – aus der VPN-Konfiguration der 7170:
phase2localid {
ipnet {
ipaddr = 192.168.45.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 192.168.177.0;
mask = 255.255.255.0;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 192.168.177.0 255.255.255.0",
"permit ip any 192.168.5.0 255.255.255.0";
Die 7570 hat für jene Verbindung:
phase2localid {
ipnet {
ipaddr = 192.168.177.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 192.168.45.0;
mask = 255.255.255.0;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 192.168.45.0 255.255.255.0";
Nachtrag, 2012-02-27, 21:30: Nach längerem Suchen habe ich eine erste Verbindung zu einem StrongSwan auf Debian Lenny von der 7170 hinbekommen — und ich glaube, die Nebel lichten sich langsam: die 7170 scheint per VPN mit der 169.254.2.1 rauszugehen, die sie auf dem DSL-Interface aus mir unbekannten Gründen konfiguriert hat; tcpdump -n -i eth0 zeigt auf dem Server im RZ:
21:24:18.526026 IP 169.254.2.1 > 192.251.226.129: ICMP echo request, id 9222, seq 1, length 64 21:24:18.530029 IP 169.254.2.1 > 192.251.226.129: ICMP echo request, id 9222, seq 2, length 64
Und das paßt auch zur Interfacekonfiguration auf der 7170:
dsl Link encap:Point-to-Point Protocol inet addr:169.254.2.1 P-t-P:169.254.2.1 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST MTU:1500 Metric:1 RX packets:17440 errors:0 dropped:0 overruns:0 frame:0 TX packets:17445 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:1450267 (1.3 MiB) TX bytes:1845896 (1.7 MiB) lan Link encap:Ethernet HWaddr 00:15:0C:XX:XX:XX inet addr:192.168.5.229 Bcast:192.168.5.255 Mask:255.255.255.0 UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1 RX packets:514615 errors:0 dropped:0 overruns:0 frame:0 TX packets:57351 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:87867018 (83.7 MiB) TX bytes:15078398 (14.3 MiB) lan:0 Link encap:Ethernet HWaddr 00:15:0C:XX:XX:XX inet addr:169.254.1.1 Bcast:169.254.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
Diese Box macht »Internet über LAN1« und dort dann PPPoE, den Alice-IAD als DSL-Modem mißbrauchend. Aber die »7570« (ok, ich habe etwas geschwindelt: noch ist es ein Speedport 300HS und ein Speedport W530V, auf 7240 gefrizt; der W920V mit 7570-Firmware liegt noch »bei der IT zur Konfiguration«, sprch: ich teste den noch und übertrage die Konfiguration händisch) nutzt ebenfalls PPPoE über LAN1 (wo ein VDSL-Modem hängt), sieht aber gänzlich anders aus:
dsl Link encap:Point-to-Point Protocol inet addr:192.168.177.1 P-t-P:192.168.177.1 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST MTU:1500 Metric:1 RX packets:4890641 errors:0 dropped:0 overruns:0 frame:0 TX packets:2489927 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:1675787479 (1.5 GiB) TX bytes:333784871 (318.3 MiB) lan Link encap:Ethernet HWaddr 00:1A:4F:XX:XX:XX inet addr:192.168.177.1 Bcast:192.168.177.255 Mask:255.255.255.0 UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1 RX packets:2544270077 errors:0 dropped:0 overruns:0 frame:0 TX packets:381956968 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1403890285 (1.3 GiB) TX bytes:2941953283 (2.7 GiB) lan:0 Link encap:Ethernet HWaddr 00:1A:4F:XX:XX:XX inet addr:169.254.1.1 Bcast:169.254.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
WTF‽ Weitere Vergleiche ergaben entsprechende Einträge in der ar7.cfg:
dslinterface {
name = "dsl";
dhcp = no;
- ipaddr = 169.254.2.1;
- netmask = 255.255.255.255;
- dstipaddr = 169.254.2.1;
+ ipaddr = 0.0.0.0;
+ netmask = 0.0.0.0;
+ dstipaddr = 0.0.0.0;
dhcpenabled = yes;
dhcpstart = 0.0.0.0;
dhcpend = 0.0.0.0;
+ no_dnsd_static = no;
}
Fragt sich nur, wo das herkommt, richtig SInn macht es nicht. Vielleicht einmal zu selten den Factory-Reset ausgeführt? Narf, das hat mich jetzt sicher einen Tag am Wochenende gekostet\:-(
Nachtrag, 2012-02-27, 23:30: So, nach einem Abstecher zur dann doch noch abgeschossenen Fritzbox – die Einstellung von 192.168.45.1/255.255.255.0 auf dem DSL-Interface in der ar7.cfg war dann doch zu viel des Guten, die FB mochte zwar noch eine Verbindung aufbauen, nur routen, das war jetzt out –, tut es nun, wie es soll (fast, bis auf das komische ICMP-Handling):
wusel@death:~$ traceroute 192.168.45.25 traceroute to 192.168.45.25 (192.168.45.25), 64 hops max, 40 byte packets 1 albert.uu.org (192.251.226.33) 0 ms 0 ms 0 ms 2 FB-DSL-GTSO.uu.org (192.168.177.1) 1 ms 0 ms 0 ms 3 HP4050N.sld.tld (192.168.45.25) 73 ms 70 ms 71 ms 4 HP4050N.sld.tld (192.168.45.25) 81 ms 76 ms 75 ms
(FB 7170 im Office)# traceroute death.uu.org traceroute to death.uu.org (192.251.226.52), 30 hops max, 38 byte packets 1 death.uu.org (192.251.226.52) 85.860 ms 76.241 ms 72.894 ms 2 death.uu.org (192.251.226.52) 73.421 ms 74.253 ms 72.283 ms 3 death.uu.org (192.251.226.52) 75.041 ms 81.484 ms 74.811 ms
Scjön ist anders … und mein VoIP-Problem, was ich seinerzeit (um 2009) hatte mit falschen Absende-IPs könnte auch an diesem komischen Eintrag für »dsl« gelegen haben. Naja, sei’s drum; erst einmal funktioniert die Kopplung per SIP zwischen den Fritzboxen, das was das Ziel.
Was noch nicht richtig funzt ist die Verbindung zu StronSwan:
# traceroute 192.251.226.129 traceroute to 192.251.226.129 (192.251.226.129), 30 hops max, 38 byte packets 1 * * * 2 gw.mobile.uu.org (192.251.226.129) 43.732 ms 36.009 ms 35.763 ms
Allerdings klappt der Verbindungsaufbau bislang nur vom Server im DC, ein /etc/ipsec.conf und Hinweise, was in die /etc/ipsec.secrets zu schreiben ist bei einer Fritzbox mit dynamischer IP (und DynDNS-Eintrag zu jenem) wäre sehr willkommen.
(Und, ernsthaft, daß dieses IPsec-Geraffel keine Interfaces mitbringt und somit auch keine sauberen Routen verfügbar sind, ist schon ziemlich doof. Schon auf der Fritzbox fand ich es nervig, keinen Einblick zu haben, aber unter »normalem Linux« ist das ja auch nicht besser. »ipsec status all« ist auch nur ein schwacher Trost:
000 "fb-office": 192.251.226.128/28===195.xx.xx.xx @host.sld.tld @fb-office.dyn.sld.tld erouted; eroute owner: #4 000 "fb-office": ike_life: 14400s; ipsec_life: 3600s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3 000 "fb-office": dpd_action: hold; dpd_delay: 30s; dpd_timeout: 75s; 000 "fb-office": policy: PSK+ENCRYPT+TUNNEL+PFS+UP; prio: 28,24; interface: eth0:5; 000 "fb-office": newest ISAKMP SA: #3; newest IPsec SA: #4; 000 "fb-office": IKE algorithms wanted: 7_128-2-2, 000 "fb-office": IKE algorithms found: 7_128-2_160-2, 000 "fb-office": IKE algorithm newest: AES_CBC_256-SHA-MODP1024 000 "fb-office": ESP algorithms wanted: 12_128-2, 000 "fb-office": ESP algorithms loaded: 12_128-2_160, 000 "fb-office": ESP algorithm newest: AES_256-HMAC_SHA1; pfsgroup=<Phase1> 000 000 #4: "fb-office" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 3153s; newest IPSEC; eroute owner 000 #4: "fb-office" ah.c7cf3de0@78.xx.xx.xx ah.cf02ba84@195.xx.xx.xx esp.46e496b1@78.xx.xx.xx (198 bytes, 84s ago) esp.a1010464@195.xx.xx.xx (228 bytes, 84s ago) comp.69bb@78.xx.xx.xx comp.1fba@195.xx.xx.xx; tunnel 000 #3: "fb-office" STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 3152s; newest ISAKMP; DPD active
Irgendwie finde ich OpenVPN, auch wenn es »nur« ein SSL-VPN ist, mehr denn je cooler, einfacher und flexibler — von der Möglichkeit, über TCP und/oder durch Proxies zu gehen, mal ganz abgesehen. Aber jetzt habe ich Blut geleckt und würde gerne eine Verbindung Fritz<>StrongSwan hinbekommen — and Hits are appreciated! Als Kür möchte ich dann das Ganze auf den gleichen Rechner, wo schon der L2TP/IPsec-Kram mit OpenSwan läuft, umziehen. (Wahrscheinlich wegen des %any landete da aber die Fritzbox-Verbindung immer in einem L2TP-Korsett, was wohl Windows und Android so machen, Fritzboxen aber nicht. Wenn ich daran denke, wird mir auch schwindelig; da nutzt man ggf. L2TP, PPP und IPsec über DSL, was in sich schon PPPoE und Ethernet auf ATM-Basis ist. Frage mich, wie viele VPN-Tunnel verschachteln kann, bis die MTU auf 8 geschumpft ist ;-))
