VPN 7170 <--> 7170 ok VoIP 7170 <--> 7170 nicht Auch kein Ping Box2Box

[Hein Blöd]

Erst einmal ein Hallo,

und schon mal die Bitte um Entschuldigung, falls ich einen bestehenden Thread
zu diesem Thema übersehen haben sollte.

Zwei Standorte:
1) 7170 direkt am DSL (interne IP 192.168.4.254)
2) 7170 hinter Kabelmodem (interne IP 192.168.0.253)

(AVM)IpSec-Verbindung funktioniert.
PCs aus beiden Netzen haben Zugriff ins jeweils gegenüberliegende Netz,
Zugriff auf die Weboberflächen der Boxen funktionieren Netzübergreifend.
Bis dahin also kein Problem.
Aber.
Eine Box (192.168.0.253) ist nun als SIP-Registrar eingerichtet.
Softphones aus 192.168.0.0 können sich auch anmelden.
Ich möchte aber von der 192.168.4.254 VoIP-Verbindungen zur
192.168.0.253 aufbauen.
Und das scheitert.
Ebenso wie Verbindungen von Softphones aus 192.168.4.0 zu
192.168.0.253.

Ich hab' dann mal freetz-1.1 auf die Boxen gepackt, um mit tcpdump zu schauen, was sich da tut.
Hab' gleich AVM-Firewall und VirtualIP mit draufgepackt, um zu schauen,
ob ich evtl. damit was anfangen kann.

tcpdump bleibt still.
Ping, bzw. traceroute von eine Box zur anderen auch.
Irgendwie hab' ich den Verdacht, dass die Boxen selber gar nicht die
Route ins jeweils andere Netz haben.

Bin für jeden Tipp dankbar.

Gruß
Hein Blöd

 

[smart-gp]

VoIP über VPN oder DynDNS funktioniert derzeit nicht am SIP-Registrar der FB.

Dazu gibt es bereits einige Threads. Schau mal im Telefoniebereich.

 

[Hein Blöd]

Danke für den Hinweis.

Ich hab' heute morgen einiges entdeckt, dass mit dem Thema zu tun hat.
Schien mir aber so, dass es in erster Linie darum ging, irgendwelche IP-Phones, in erster Linie Nokia Handys, an der Box anzumelden.

Mir würde es schon reichen, wenn mir jemand die Augen öffnet, wie das IpSec-VPN bei den Boxen funktioniert.
Also die Hintergründe.

Es ist ja nicht allein, dass der SIP-Client der einen Box sich nicht am Registrar der anderen anmelden kann, es geht ja weder Ping, noch traceroute von einer Box zur anderen.

Ein ifconfig zeigt mir kein Device, das ich irgendwie mit dem VPN in Verbindung bringen kann.
Pinge ich eine der Boxen von einem PC eines Remote-Netzes an, so bekommt der PC zwar "replies", aber ein tcpdump auf der Box zeigt nichts.

Scheint mir, als würden die Boxen bridgen.
Aber mit Bridging kenn ich mich in keinster Weise aus.
Stelle mir das so vor, dass dann beide Boxen auf einer (verborgene?) Schnittstelle liegen.
Und wenn es kein Transfernetz gibt, kann ich der Box auch schlecht eine Route ins andere Netz geben.
Einen dementsprechenden Eintrag suche ich in der Routingtabelle auch vergeblich.

 

[sf3978]

Stelle mir das so vor, dass dann beide Boxen auf einer (verborgene?) Schnittstelle liegen.

Mit iptraf kann man die Verbindung sehen:

UDP (29 bytes) from 82.###.###.###:4500 to 89.+++.+++.+++:4500 on wan
UDP (29 bytes) from 89.+++.+++.+++:4500 to 169.254.2.1:4500 on dsl

EDIT:
tcpdump bleibt nicht still:

/var/mod/root # tcpdump -nNettvvv -i wan proto UDP
tcpdump: WARNING: wan: no IPv4 address assigned
tcpdump: listening on wan, link-type EN10MB (Ethernet), capture size 68 bytes
1245535488.686168 00:**:**:**:**:** > 00:"":"":"":"":"0, ethertype IPv4 (0x0800), length 43: (tos 0x0, ttl 64, id 231, offset 0, flags [none], proto UDP (17), length 29) 82.###.###.###.4500 > 89.+++.+++.+++.4500: [no cksum] isakmp-nat-keep-alive
1245535490.418541 00:**:**:**:**:** > 00:"":"":"":"":"0, ethertype IPv4 (0x0800), length 126: (tos 0x0, ttl 64, id 58379, offset 0, flags [none], proto UDP (17), length 112) 82.###.###.###.4500 > 89.+++.+++.+++.4500: [no cksum] UDP-encap: ESP(spi=0x36a165d6,seq=0x1), length 84
1245535491.428005 00:**:**:**:**:** > 00:"":"":"":"":"0, ethertype IPv4 (0x0800), length 126: (tos 0x0, ttl 64, id 58378, offset 0, flags [none], proto UDP (17), length 112) 82.###.###.###.4500 > 89.+++.+++.+++.4500: [no cksum] UDP-encap: ESP(spi=0x36a165d6,seq=0x2), length 84
1245535510.695962 00:**:**:**:**:** > 00:"":"":"":"":"0, ethertype IPv4 (0x0800), length 43: (tos 0x0, ttl 64, id 232, offset 0, flags [none], proto UDP (17), length 29) 82.###.###.###.4500 > 89.+++.+++.+++.4500: [no cksum] isakmp-nat-keep-alive

 

[Hein Blöd]

Na, das ist doch was.
Wenn ich da "169.254.2.1:4500 on dsl" lese,
läuft das so in Richtung meiner bridging-Vermutung.

Hab' ich Blödmann wohl zu wenig v's hinter's tcpdump gegeben, um das zu sehen.
Um das mal nachzuvollziehen, muss ich aber erst wieder andere freetz-images auf die Boxen spielen.
Wollte mal mit openvpn testen.
Allerdings hab' ich dann kein AVM-Webgui mehr.
Zu diesem Thema gibt's hier ja auch einiges zu lesen.
Mein letzter Test war openvpn statisch gelinkt.
Damit das image nicht zu gross wurde, musste ich alles andere rauswerfen.
War aber auch erfolglos.
Kann zwar ctlmgr per telnet starten.
Schmiert aber beim anmelden ab.
Ok, ist offtopic.

Ich werd' jetzt mal wieder die anderen Images flashen.
Und wie ich mit Anwendungen auf externem Speicher hantiere, muss ich auch mal lernen.

Die Idee mit OpenVpn kam auf, weil ich das vor Jahren mal auf meinen Fedora 5 Server gepackt habe, um Kollegen helfen zu können.

Das Folgende hat jetzt mit Fritz nichts zu tun.
Ich hab' mich mal testweise per OpenVpn-Client mit dem Server verbunden verbunden und der Server kann den Client anpingen.
Da funktioniert das routing also.
Ist allerdings nur Server-Client nicht net-to-net.

 

[smart-gp]

Denke damit bist Du hier dann aber inzwischen falsch.

Für Freetz und andere Modifikationen gibt's eigene Forenbereiche.

 

[sf3978]

Na, das ist doch was.
Wenn ich da "169.254.2.1:4500 on dsl" lese,
läuft das so in Richtung meiner bridging-Vermutung.

Bridging findet auf OSI-Ebene 2 mit MAC oder LLC statt. IPsec geht über OSI-Ebene 3.

Hab' ich Blödmann wohl zu wenig v's hinter's tcpdump gegeben, um das zu sehen.

Es lag nicht an den v's. Denn ohne v's ist tcpdump auch nicht still zu bekommen. Wichtig ist nach proto UDP zu schauen (steht in den conf-Dateien):

/var/mod/root # tcpdump -nNett -i wan proto UDP
tcpdump: WARNING: wan: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wan, link-type EN10MB (Ethernet), capture size 68 bytes
1245570290.061612 00:xx:xx:xx:xx:xx > 00:zz:zz:zz:zz:zz, ethertype IPv4 (0x0800), length 74: 82.###.###.###.2050 > ***.***.***.***.53: 47504+[|domain]
1245570293.887482 00:yy:yy:yy:yy:yy > 00:zz:zz:zz:zz:zz, ethertype IPv4 (0x0800), length 43: 82.###.###.###.4500 > 89.+++.+++.+++.4500: isakmp-nat-keep-alive

Wollte mal mit openvpn testen.
Allerdings hab' ich dann kein AVM-Webgui mehr.

Warum solltest Du dann kein AVM-Webgui mehr haben? Du hast dann ein AVM- und ein Freetz-Webgui (mit OpenVPN-Gui).

 

[Hein Blöd]

Ne, wenn ich Freetz mit OpenVpn auf die Box packe,
startet ctlmgr nicht mehr.
Manuell per telnet gestartet, bekomme ich die Anmeldeseite der AVM-GUI und bei der Anmeldung ist der ctlmgr-Prozess weg.

Aber wie smart-gp schon schrieb.
Zu diesem Thema gibt's andere Threads.

Hier geht's mir halt darum, 'ne Verbindung Box2Box hinzubekommen.
Wenn's denn definitiv nicht geht, muss ich mir die Idee von der Backe putzen.

Is' halt nur, weil ich's nicht so optimal finde, für 'ne "fritzbasierte" VoIP-Verbindung durch ein VPN vier Boxen aufzubauen.

Ich hab' mal die VoIP-Client-Seite gegen 'nen Vigor2200VG getauscht.
Der Vigor hat eine Route ins VPN-Zielnetz.
Er zeigt mir drei verschiedene Interfaces an:
- Eines (IF3) mit der default-Route ins WAN GW Adresse vom Provider
- Eines (IF0) mit dem internen Netzsegment Anstelle GW directly connected
- Eines (IF4) mit dem Segment des VPN-Remote-Netz GW externe IP der Remote Fritz

So hatte ich mir das auch bei der Fritz vorgestellt.
Der Vigor-VPN-Client logt sich beim Fritz-Registrar ein und kann auch ein X-Lite im lokalen Netz der Fritz anklingeln.
X-Lite zu Vigor geht aber nicht.

Ich befürchte mal, hier liegt es wieder an der Realisierung des VPN auf der Fritz!Box.

Ok, Bridging liegt auf Layer 2.
Darauf setzt der Layer 3 auf.
Im Layer 3 liegt IpSec.

Wenn mich nicht alles täuscht, sitzt auf Layer 3 IP und somit das ganze Routinggedöns.

Hier fehlt mir die sichtbare Abbildung.
Die 169.254.2.1 sehe ich auf beiden Boxen.
Und auch auf beiden Boxen die 169.254.1.1 / 16 lan:0
Könnte es sein, dass sich der VPN-Verkehr tummelt?
Muss mal schauen, ob ich diese Adresse auch auf 'ner Box ohne VPN hab'.

Übrigens hab ich gerade mal mit den empfohlenen tcpdump Schaltern aufs WAN-Interface geschaut.
Da tut sich auch was, wenn ich versuche den Vigor anzuklingeln.
Zwischen den beiden öffentlichen IPs.

Klingel ich von einem X-Lite eines PCs aus dem LAN der Fritz!Box (Registrar) zu einem X-Lite auf einem PC im (zur Zeit) VigorNetz, so klingelt dort X-Lite.
Nehme ich den Ruf an, so zeigt mir das angerufene X-Lite "Call established".
Beim anrufenden X-Lite im lokalen Netz des Fritz-Registrars tut sich nichts.
Bis nach einiger Zeit "Call failed: Request Timeout" erscheint.
Kann es sein, dass die Fritz!Box hier die Signalisierung ins VPN schickt, aber nach Rufannahme über die externe IP geht?

Ok, ok, die Problembeschreibung ist alles Telefonie- und nicht Internetkram.
Das Problem selbst scheint mir aber im Bereich der VPN-Implementierung, und somit im Bereich Internet zu liegen.

 

[MrVenus]

AVM-VPN IPSec zw. zwei Boxen

Habe das gleiche Problem. Möchte Daten über VPN zwischen zwei Boxen abgleichen (per Skript)

Leider kann man von Box1 zu Box2 über VPN nicht zugreifen obwohl das Netzwerk funktioniert.
PCs die an der Box angeschlossen sind, können von Netz1 zu Netz2 über VPN zugreifen.

Wollte fragen ob jemand schon eine Lösung gefunden hat?
Wäre für jede Hilfe dankbar...


venus

 

[sf3978]

[...]
Leider kann man von Box1 zu Box2 über VPN nicht zugreifen obwohl das Netzwerk funktioniert.
[...]

Siehe hier: klick

 

[MrVenus]

Danke...

Danke ...bekomme jetzt Zugriff mit Hilfe von iptables und S-Nat

so wie hier beschrieben:
http://www.ip-phone-forum.de/showpost.php?p=1437502&postcount=752
http://www.ip-phone-forum.de/showthread.php?t=209625


Habe ich das so richtig verstanden ???

Box A: 192.168.1.1
Box B: 192.168.2.1

# Pakete, die den Rechner über dsl verlassen:

iptables -t nat -A POSTROUTING -o dsl "AKTION"

# "AKTION" Source-NAT: Absender zu 192.168.2.1 ändern

-j SNAT --to-source 192.168.2.1

# Pakete, die die FritzBox über dsl von/über ( -s 169.254.2.1 ) als Ziel ( -d 192.168.1.1 )
# verlassen bekommt die ( --to-source 192.168.2.1 ) als Absende-IP

iptables -t nat -A POSTROUTING -s 169.254.2.1 -d 192.168.1.1 -o dsl -j SNAT --to-source 192.168.2.1

...kann dann aber auch nur die IP (also nur die Box selbst) "-s 169.254.2.1" auf die andere Box zugreifen oder klaue ich mir durch das "Absender IP ändern" - Sicherheit ?

Was meint RalfFriedl dazu ( src-Eintrag - Route ) ??? :
http://www.ip-phone-forum.de/showpost.php?p=1486836&postcount=8

...danke nochmals Venus

 

[sf3978]

[...]
...kann dann aber auch nur die IP (also nur die Box selbst) "-s 169.254.2.1" auf die andere Box zugreifen oder Klaue ich mir durch das "Absender IP ändern" Sicherheit ?
[...]

Wer was kann bzw. darf oder nicht kann bzw. nicht darf, kannst Du mit iptables in den INPUT- und OUPUT-chains der Boxen festlegen/regeln. Achtung, ... dass Du dich nicht aussperrst.

 

[zoomy84]

Sehr Interessantes Thema, da ich momentan vor dem gleichen Problem stehe...

Wir möchten gerne mehrere FB an einem zentralen Lancom Router über VPN (IPSec) als SIP-Client nutzen. Leider scheitern wir ebenfalls an der Adresse des DSL-Interface welche bei allen Paketen von der FB am Lancom auftaucht. Wir möchten nun ungern alle Kundengeräte mit IPTables versorgen und sind deshalb auf der Suche nach einer alternativen Möglichkeit.

Testweise hatten wir bereits versucht den Host 169.254.2.1 / 255.255.255.255 ins Routing vom Lancom aufzunehmen. Leider scheint es jedoch so, das die Fritzbox anfragen über VPN an die 169.254.2.1 generell blockt. Mit dieser Lösung wäre wenigstens der Betrieb einer Box pro Lancom möglich.

Gibt es eine Möglichkeit dies zu gestatten oder müsste das 169er Netz in die VPN-Regeln der FB aufgenommen werden?

Mich würde auch sehr interessieren was RalfFriedl mit seinem Beitrag meinte...

http://www.ip-phone-forum.de/showpost.php?p=1486836&postcount=8

Schonmal danke...

 

[RalfFriedl]

Da hier anscheined schon mehrfach Fragen auftauchten, was mit dem [POST=1486836]src-Eintrag der Route[/POST] gemeint ist, hier der Hinweis, daß ich dort auch eine [POST=1555328]Erläuterung[/POST] dazu geschrieben habe.

Wenn noch mehr Fragen dazu offen sind, bitte dort schreiben.