Problem: VPN zwischen zwei Fritz Boxen

[TuX-123]

Hallo leute,

ich hoffe Ihr könnt mir bei meinem Problem ein par Tipps geben.

ich habe 2 Fritz boxen die wunderbar eine VPN verbindung aufbauen, ich kann von jeder Seite mit den PC auf das anderre Netzwerk zugreifen ohen Problem leuft echt super.

nun zu meinem Probelm:

wenn ich mich mit Telnet auf die Box verbinde, kann ich von der Fritzbox aus nicht auf das anderre Netzgreifen, z.B ping schlägt feht

# ping 192.168.2.1 PING 192.168.2.1 (192.168.2.1): 56 data bytes

--- 192.168.2.1 ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss

Hintergrund ist der, ich habe auf jeder Fritz box einen USB Stick angesteckt, und möchet von der Fritz box aus auf den Stick zugreifen, aber leider ist das Netz nicht erreicht bar

ich vermute mal es liegt an einer route die Fehlt binn mir aber nicht sicher?

# route

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

192.168.180.1 * 255.255.255.255 UH 2 0 0 dsl

192.168.180.2 * 255.255.255.255 UH 2 0 0 dsl

192.168.100.0 * 255.255.255.0 U 0 0 0 lan

95.90.8.0 * 255.255.248.0 U 2 0 0 dsl

169.254.0.0 * 255.255.0.0 U 0 0 0 lan

default * 0.0.0.0 U 2 0 0 dsl #


Hier mal meine Daten:

VPN A hat Netz IP 192.168.2.x (router 192.168.2.1)

VPN B hat Netz IP 192.168.100.x (router 192.168.100.254)

Ich hoffe Ihr habt verstanden was ich meine, und Ihr habt einen Tipp für mich

Gruss

Emu

 

[frank_m24]

Hallo,

wenn ich mich recht erinnere, war das schon immer so, dass man von der Fritz direkt nicht auf die andere Seite des VPN Tunnels kam. Die leitet nur Pakete von externen Devices in den Tunnel, nicht von localhost.

 

[MaxMuster]

Und wenn du expilizit das eigene Absende-Interface aus dem LAN nutzt, damit die ipsec-Regeln auch greifen?

ping -I 192.168.100.254  192.168.2.1

Jörg

 

[eisbaerin]

Hallo Jörg !

Entschuldigung, wenn ich mich hier mit einmische, aber das Thema interessiert mich auch sehr.

Ja, so geht es. Gerade getestet!

# [B]ping 192.168.3.1[/B]
PING 192.168.3.1 (192.168.3.1): 56 data bytes

--- 192.168.3.1 ping statistics ---
6 packets transmitted, 0 packets received, 100% packet loss           
#
#
# [B]ping -I 192.168.2.1 192.168.3.1[/B]
PING 192.168.3.1 (192.168.3.1) from 192.168.2.1: 56 data bytes
64 bytes from 192.168.3.1: seq=0 ttl=64 time=153.120 ms
64 bytes from 192.168.3.1: seq=1 ttl=64 time=145.358 ms
64 bytes from 192.168.3.1: seq=2 ttl=64 time=131.655 ms
64 bytes from 192.168.3.1: seq=3 ttl=64 time=141.223 ms
64 bytes from 192.168.3.1: seq=4 ttl=64 time=122.452 ms
64 bytes from 192.168.3.1: seq=5 ttl=64 time=190.665 ms
64 bytes from 192.168.3.1: seq=6 ttl=64 time=118.358 ms
64 bytes from 192.168.3.1: seq=7 ttl=64 time=121.539 ms

--- 192.168.3.1 ping statistics ---
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max = 118.358/140.546/190.665 ms          
#

Wie bringe ich das aber dem SIP-Client in der FB bei?
Ich will daß der sich über VPN mit dem SIP-Server der anderen FB verbindet.
Kann man da irgendwas umbiegen?

 

[frank_m24]

Hallo,

@eisbaerin: kann man den voipd beim Aufruf an ein Interface binden? Das könnte - zumindest dafür - die Lösung sein. Jetzt kommt aber das nächste Problem: Es gab auch mal Probleme mit UDP Daten durch den VPN Tunnel. Deshalb könnte sein, dass es trotzdem nicht klappt.

@TuX-123: Wie willst du denn auf den USB Speicher zugreifen? FTP? SMB? Meines Wissens hat die Box keinen passenden Client, um auf Massenspeicher anderer Geräte zuzugreifen. Dort stellt sie üblicherweise nur die Server zur Verfügung, nicht die Clients.

 

[TuX-123]

Hallo,

super schon einen schritt weiter Danke an alle,

ich dachte da an die Software

Fritz!Load
http://sourceforge.net/projects/avmload/

wenn die an FTP server rankommt sollte das doch auch gehn oder?

nur die Frage ist jetzt noch wie kann ich der Software sagen immer über diese Interface gehn oder kann man das Irgendwie auf der BOX einstellen?

Gruss

TuX

 

[sf3978]

[...]Die leitet nur Pakete von externen Devices in den Tunnel, nicht von localhost.

Die Pakete der FritzBox finden nicht den Weg zurück (Log mit iptables). Mit dem richtigen Masquerading (z. B. iptables mit Freetz) geht das ohne Probleme (telnet, ssh, ftp, etc.).

 

[MaxMuster]

Könntest du das mal genauer erklären?
Solange die Box nichts von ihrer LAN-IP schickt, sondern mit der DSL-IP oder was auch immer, dürfte die IPSec-Regel doch garnicht greifen und die Pakete sollten "normal" geroutet werden.

Eine theoretisch mögliche Lösung könnte sein, die "DSL-IP" (169.254.2.1) zusätzlich zum LAN auf der eigenen Seite beim permit mit aufzunehmen.

Jörg

 

[sf3978]

Wenn man mit iptables im OUTPUT- und INPUT-chain beider Boxen (LAN-LAN), für alle Interfaces (input und outpu) die Pakete loggt, kann man den Weg der Pakete genau verfolgen und feststellen wo man S-NAT (MASQUERADING) machen muss. Genaueres kann ich erst am Freitag, wenn ich an meinen Boxen bin, posten.

 

[MaxMuster]

o.k., dann warte ich mal ab ;-). Auf jeden Fall würd mich die Frage sehr interessieren, ob auch "nicht genattete" Pakete durchs VPN gehen, deren Source-IP nicht aus dem LAN kommt...

Jörg

 

[sf3978]

[...]Auf jeden Fall würd mich die Frage sehr interessieren, ob auch "nicht genattete" Pakete durchs VPN gehen, deren Source-IP nicht aus dem LAN kommt...

Aber die IP der Box kommt doch auch aus dem LAN (... bei einer LAN-LAN Verbindung).

 

[MaxMuster]

Hi,

Nicht zwingend: Normalerweise ist die IP (bei multi homed Geräten) abhängig vom Routing bzw. dem ausgehenden Interface. Die AVM-Merkwürdigkeiten beim Dsl-Interface mal beiseite lassend wird ein Router, wenn er eine IP im LAN anspricht, seine LAN-IP als Source nehmen, im WLAN die WLAN-IP und Richtung Internet die Internet-IP.

Deshalb sollte ein Paket mit einer "LAN-Source" durch den IPSec Tunnel gehen, denn es passt zu der entsprechenden Regel. Wenn die Box selbst keine Route für das LAN auf der Gegenseite hat (was normalerweise der Fall sein dürfte) wird sie nach meinem Verständnis "Richtung Internet" routen und deshalb (bei von ihr selbst ausgehendem Traffic) die Internet-IP nehmen. Wenn nun auf diesem Interface das IPSec die permit Regeln prüft, würde ein Paket aus dem LAN übereinstimmen und durch den Tunnel geschickt, während ein Paket mit IP vom DSL-Interface bei der oben genannten Einstellung wohl nicht passte...


Jörg

EDIT O.k., nachdem ich jetzt deine NAT-Regel kenne sehe ich meine Vermutung bestätigt: Du nattest die DSL-IP auf die LAN-IP, und damit greift IPSec (Source aus dem LAN). Ohne die NAT (so wäre meine Vermutung) sollten auf der anderen Seite überhaupt keine Pakete ankommen...

 

[sf3978]

[...]

EDIT O.k., nachdem ich jetzt deine NAT-Regel kenne sehe ich meine Vermutung bestätigt: Du nattest die DSL-IP auf die LAN-IP, und damit greift IPSec (Source aus dem LAN). Ohne die NAT (so wäre meine Vermutung) sollten auf der anderen Seite überhaupt keine Pakete ankommen...

Genau so ist es. Ein Beispiel mit telnet:
1. Ohne S-NAT:

Nov 27 18:48:30 fritz user.warn kernel: +++OUTPUT-connection:IN= OUT=dsl SRC=169.254.2.1 DST=192.168.158.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=2946 DF PROTO=TCP SPT=2172 DPT=23 WINDOW=5840 RES=0x00 SYN URGP=0

2. Mit S-NAT:

Nov 27 18:50:41 fritz user.warn kernel: +++OUTPUT-connection:IN= OUT=dsl SRC=169.254.2.1 DST=192.168.158.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=43304 DF PROTO=TCP SPT=2173 DPT=23 WINDOW=2920 RES=0x00 ACK URGP=0