[Problem] VPN zwischen 2 Fritzboxen mit statischer Route

stephensworld

Neuer User
Mitglied seit
17 Sep 2006
Beiträge
23
Punkte für Reaktionen
0
Punkte
1
Hallo,

ich habe folgendes Problem. Ich habe zwei Standorte mit Fritzbox VPN vernetzt, wobei am Standort A noch ein zweites Subnetz vorhanden ist, das über eine statische Route erreichbar ist. Dieses Subnetz soll auch vom Standort B erreichbar sein.

Folgende Szenario:
Standort A
192.168.1.0/24
192.168.3.0/24 über statische Route 192.168.1.100

Standort B
192.168.6.0/24

Die Kommunikation beider Standorten funktioniert zwischen den Netzen 192.168.1.0 <-> 192.168.6.0 einwandfrei.
Ebenso funktioniert die Kommunikation 192.168.1.0 -> 192.168.3.0
Wenn ich mich mit einem iPhone per VPN mit der Fritzbox am Standort A verbinde, komme ich auch in das Netz 192.168.3.0

Allerdings kann ich das Netz 192.168.3.0 vom Standort B nicht erreichen.


Bin für jede Hilfe dankbar.

Grüße
Stephan

Folgende Config wurde bei der Fritzbox am Standort B verwendet:

Code:
vpncfg {
        connections   {
                enabled = yes;
                conn_type = conntype_lan;
                name = "name_der_verbidnung";
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
                remotehostname = "www.standort.a";
                localid {
                        fqdn = "www.standort.b";
                }
                remoteid {
                        fqdn = "www.standort.a";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "-------------";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.6.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.1.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.1.0 255.255.255.0",
			     "permit ip any 192.168.3.0 255.255.255.0";
			   

        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500", 
                            "udp 0.0.0.0:4500 0.0.0.0:4500";
}


// EOF
 
Zuletzt bearbeitet:
Der Weg von Standort B zu 192.168.3.0/24 führt tatsächlich über "dev dsl" (notfalls als default, wenn kein expliziter Eintrag existiert) ? Ein "traceroute" auf der Box oder ein analoges Kommando von einem Client am Standort B sollte Auskunft darüber geben.

Wie sieht die "accesslist" in der VPN-Konfiguration von Standort A für die Verbindung zum Standort B aus ?
Hintergrund: Von Standort B aus ist der Zugriff auf die 192.168.3.0/24 erlaubt, aber wie sieht es mit dem Rückweg für die Pakete von Standort A dort aus ?
Auch dort müßte dann als zusätzliche Zeile in der "accesslist" eine Regel "permit ip any 192.168.6.0 255.255.255.0" eingetragen sein.

EDIT: Theoretisch könnte das aber auch von der ohnehin vorhandenen "accesslist" mit abgedeckt werden, fällt mir gerade noch auf. Also vergiss meinen Beitrag ... ich will ihn nur nicht komplett löschen, bin aber wohl doch auf dem Holzweg.

Oder vergiss ihn nicht komplett ... wenn Du am Standort A mal einen Packetdump auf "dev lan" machst, siehst Du zumindest schon mal, ob von 192.168.6.0/24 überhaupt Pakete ankommen und es damit am Rückweg liegt oder ob schon der Hinweg nicht funktioniert.
 
Zuletzt bearbeitet:
Hi,

vielen Dank für die ausführliche Antwort. Ich habe jetzt mal einen traceroute am Standort B ins 192.168.3.0 Netz gemacht.

Macintosh-3:~ stephan$ traceroute 192.168.3.1
traceroute to 192.168.3.1 (192.168.3.1), 64 hops max, 52 byte packets
1 fritz.box (192.168.6.1) 0.691 ms 0.416 ms 1.005 ms
2 192.168.3.1 (192.168.3.1) 23.448 ms 20.966 ms 26.157 ms
3 * * *
4 * * *
5 *^C
Macintosh-3:~ stephan$

Ist es doch ein Problem mit dem Rückweg?
Wenn ich mich mit dem iPhone per VPN zum Standort A verbinde dann klappt es ins 192.168.3.0 Netz. Am Standort A sind sämtliche VPN Configs mit dem Webinterface erstellt.

Vielen Dank

Gruß
Stephan
 
Das VPN müßte ordentlich laufen, aber:

Was ist das für ein Router am Standort A zwischen den Netzen?
Wie ist der eingerichtet? Macht der NAT?
 
Der Router am Standort A ist ein Ubiquitti Nano Beam (Richtfunk)
Er macht NAT.
 
Zuletzt bearbeitet:
Wenn ich mich mit dem iPhone per VPN zum Standort A verbinde dann klappt es ins 192.168.3.0 Netz. Am Standort A sind sämtliche VPN Configs mit dem Webinterface erstellt.
Das ist zwar ein Hinweis, aber da dann auch nicht der Router am Standort B involviert ist und es einen riesigen Unterschied beim Einrichten des Routings durch die FRITZ!Box macht, ob man Host-LAN- oder LAN-LAN-VPN-Verbindungen hat, ist das nicht sehr aussagekräftig. Bei Host-LAN-Verbindungen wird vom avmike explizit eine Route in der Art "ip route add <ip_des_hosts> dev dsl" gesetzt, damit nicht die - normalerweise ja im Subnet auf "dev lan" liegende - Adresse per ARP versucht wird aufzulösen und die Pakete korrekt an "dev dsl" zum "Einpacken" gelangen. Das passiert bei LAN-LAN-Verbindungen bei der AVM-Firmware nicht, da verläßt man sich auf die Standardroute, die ja zum "dev dsl" zeigt und die Tatsache, daß Adressen im entfernten LAN ja gerade nicht im Subnet von "dev lan" liegen und damit automatisch auf die Default-Route geschickt werden.

Was mich im Traceroute-Output irritiert, ist der fehlende Hop auf 192.168.1.1 ... wenn ich das richtig verstanden habe, wie das Netz da aufgebaut ist, hätte ich diesen an zweiter Stelle erwartet. Wenn das nicht irgendwas mit Proxy-ARP zu tun hat (also es in Wirklichkeit die 192.168.1.1 ist, die da antwortet), dann verstehe ich auch nicht, warum das Traceroute da nicht schon beendet ist.

Zieh' Dir mal die Support-Daten am Standort A bei aktivierter VPN-Verbindung und extrahiere die Angaben aus der Routing-Tabelle und aus /var/vpnroutes (bei Telnet-Zugriff zur FRITZ!Box kannst Du die Angaben auch alle direkt auslesen). Die müßtest Du noch bekanntmachen ... genauso wäre ein jeweils dazu passender Auszug aus der ARP-Tabelle (arp -a) interessant, damit man dort eventuell vorhandene Proxy-Einträge (zwei IP-Adressen für dieselbe MAC-Adresse) identifizieren kann. Die ARP-Einträge haben aber keine lange Lebensdauer, deshalb muß das jeweils zeitnah zu einem Versuch mit einem IP-Paket erfolgen. Das dann auch noch parallel für Standort B, dann kommen wir dem Problem sicherlich auf die Spur, es gibt - zumindest in der Theorie - eigentlich keinen Grund, warum das so nicht funktioniert. Und auch wenn ich die Idee mit der "accesslist" zurückgezogen habe, die Konfiguration von Standort A (auch die Erklärung, wie Du die Route zu 192.168.3.0/24 eingerichtet hast, selbst wenn es nur simpel über das AVM-GUI ist) wäre u.U. schon noch hilfreich, falls sich dort noch irgendwelche Probleme verstecken.

Zweiter Versuch wäre es, ein Traceroute aus dem 192.168.3.0/24-Netz am Standort A zur 192.168.6.1 zu machen und mal zu schauen, wie es da aussieht.
 
Standort A
# cat /var/vpnroutes
192.168.5.0 255.255.255.0
192.168.1.170 255.255.255.255
192.168.1.171 255.255.255.255
192.168.1.172 255.255.255.255
192.168.6.0 255.255.255.0
192.168.20.0 255.255.255.0
192.168.1.201 255.255.255.255
192.168.0.0 255.255.255.0
192.168.4.0 255.255.255.0
#


# arp -a
61.1.168.192.in-addr.arpa (192.168.1.61) at 00:0c:29:d6:30:cd [ether] on lan
Josef-PC.fritz.box (192.168.1.78) at 00:27:10:69:24:cc [ether] on lan
? (192.168.1.46) at b4:f0:ab:c6:32:1b [ether] on lan
HP2.fritz.box (192.168.1.249) at b4:39:d6:b8:bf:c0 [ether] on lan
? (192.168.1.98) at 20:59:a0:bb:d5:b9 [ether] on lan
? (192.168.1.45) at <incomplete> on lan
HP.fritz.box (192.168.1.224) at 2c:27:d7:17:7f:e8 [ether] on lan
? (192.168.1.200) at 38:60:77:0d:6d:74 [ether] on lan
NAS.fritz.box (192.168.1.9) at 00:11:32:2e:aa:9d [ether] on lan
HTTP-Server.fritz.box (192.168.1.6) at c8:2a:14:58:09:03 [ether] on lan
? (192.168.1.101) at 04:18:d6:27:74:bb [ether] on lan
1.1.168.192.in-addr.arpa (192.168.1.1) at 00:0c:29:e2:3e:e5 [ether] on lan
? (192.168.1.53) at 00:14:a9:72:55:8d [ether] on lan
70.1.168.192.in-addr.arpa (192.168.1.70) at 00:0c:29:58:0a:13 [ether] on lan
? (192.168.1.102) at bc:05:43:c4:8c:b3 [ether] on lan
? (192.168.1.58) at <incomplete> on lan
? (192.168.1.95) at 00:a0:57:10:f6:1b [ether] on lan
39.1.168.192.in-addr.arpa (192.168.1.39) at 00:0c:29:c7:78:6b [ether] on lan
iPad2.fritz.box (192.168.1.42) at <incomplete> on lan
iPad.fritz.box (192.168.1.47) at 84:29:99:61:e4:d1 [ether] on lan
C2K8R2V1.fritz.box (192.168.1.64) at 00:0c:29:a9:12:72 [ether] on lan
? (192.168.1.172) at * PERM PUP on lan
? (192.168.1.201) at * PERM PUP on lan
? (192.168.1.171) at * PERM PUP on lan
? (192.168.1.170) at * PERM PUP on lan
#

Die Route am Standort A ist wie folgt eingerichtet:
Bildschirmfoto 2015-01-10 um 13.08.01.png

Am Standort B läuft eine 6360 von KDG. Leider kann ich darauf kein Telnet freischalten

Vielen Dank
 
Zuletzt bearbeitet:
Am Standort B läuft eine 6360 von KDG. Leider kann ich darauf kein Telnet freischalten
1. Die Routingtabelle von Standort A fehlt noch.
2. Auch eine 6360 kann aber Support-Daten erzeugen, dann ist es eben etwas aufwändiger, die Daten daraus zu extrahieren.
3. Falls wir uns tatsächlich mißverstanden haben ... der Inhalt der ARP-Tabelle hat nur dann Aussagekraft, wenn unmittelbar zuvor oder noch besser sogar parallel ein traceroute oder ping oder ähnliches läuft, was auch eine ARP-Auflösung erfordert. Ansonsten sind die Einträge dort im Handumdrehen "expired" und werden nicht mehr angezeigt.
4. Die VPN-Konfiguration von A fehlt auch noch.

Und die Frage von der eisbärin (inzwischen hast Du das ja noch etwas ergänzt), will ich auch noch einmal aufgreifen ... Du hast also am Standort A eine FRITZ!Box (welches Modell?), die an einem LAN-Anschluß einen weiteren Router hat, der seinerseits als LAN das Netz 192.168.3.0/24 aufspannt ? Dieser Router hat dann auf Seiten der FRITZ!Box ja eine zu dieser lokale Adresse und die Route zu 192.168.3.0/24 muß dann ja über dieses Gerät führen. Das bringt mich dann wieder zu der schon einmal gestellten Frage, wie Du diese Route konkret eingerichtet hast. Da fehlt die Erläuterung und die fehlende Routingtable von FB A habe ich schon aufgezählt. Auch bringt nur ein Test von einem Gerät in 192.168.3.0/24 dann auch Aufschluß, ob dort abgesandte Pakete an 192.168.6.0/24 überhaupt an die 192.168.1.1 zur Weiterleitung durch den VPN-Tunnel geroutet werden oder ob die dort an ein falsches Gateway gesendet werden.

Ich würde Dir gerne helfen, aber besonders redselig bist Du offenbar eher nicht ... oder täuscht das ?

PS: Beim Posten bitte "graphische Smileys deaktivieren".
 
Was mich im Traceroute-Output irritiert, ist der fehlende Hop auf 192.168.1.1
Ist bei mir aber auch so. Und bei mir geht alles (mit 3 FB's):
Code:
C:\Dokumente und Einstellungen>tracert 192.168.0.240

Routenverfolgung zu 192.168.0.240 über maximal 30 Abschnitte

  1    <1 ms    <1 ms    <1 ms  192.168.8.1
  2     1 ms     1 ms     1 ms  192.168.3.1
  3    70 ms    69 ms    70 ms  192.168.0.240   [COLOR="#FF0000"]hier fehlt die 192.168.0.1=FB[/COLOR]
  4    70 ms    70 ms    69 ms  192.168.0.240   [COLOR="#FF0000"]warum die 2 mal auftaucht ???[/COLOR]

Ablaufverfolgung beendet.

C:\Dokumente und Einstellungen>tracert 192.168.0.1

Routenverfolgung zu 192.168.0.1 über maximal 30 Abschnitte

  1    <1 ms    <1 ms    <1 ms  192.168.8.1
  2     1 ms     2 ms     1 ms  192.168.3.1
  3    69 ms    68 ms    69 ms  192.168.0.1

Ablaufverfolgung beendet.

Wenn der Ubiquitti Nano Beam aber wirklich NAT macht, und in die richtige Richtung, dann werden eigentlich keine zusätzlichen Routen und auch kein zusätzlicher Eintrag in der accesslist gebraucht.
Wenn, dann müßten in den Router Portfreigaben eingetragen werden.
So geht es zumindest bei mir.
 
Zuletzt bearbeitet:
1. Die Routingtabelle von Standort A fehlt noch.

Code:
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
212.18.3.5      *               255.255.255.255 UH    2      0        0 dsl
192.168.180.1   *               255.255.255.255 UH    2      0        0 dsl
93.104.116.212  *               255.255.255.255 UH    2      0        0 dsl
192.168.180.2   *               255.255.255.255 UH    2      0        0 dsl
192.168.1.172   *               255.255.255.255 UH    2      0        0 dsl
212.18.0.5      *               255.255.255.255 UH    2      0        0 dsl
192.168.1.201   *               255.255.255.255 UH    2      0        0 dsl
192.168.1.170   *               255.255.255.255 UH    2      0        0 dsl
192.168.1.171   *               255.255.255.255 UH    2      0        0 dsl
192.168.179.0   *               255.255.255.0   U     0      0        0 guest
192.168.3.0     192.168.1.101   255.255.255.0   UG    0      0        0 lan
192.168.1.0     *               255.255.255.0   U     0      0        0 lan
169.254.0.0     *               255.255.0.0     U     0      0        0 lan
44.0.0.0        192.168.1.101   255.0.0.0       UG    0      0        0 lan
default         *               0.0.0.0         U     2      0        0 dsl
#

2. Auch eine 6360 kann aber Support-Daten erzeugen, dann ist es eben etwas aufwändiger, die Daten daraus zu extrahieren.

Da werde ich mich gleich einlesen :)


3. Falls wir uns tatsächlich mißverstanden haben ... der Inhalt der ARP-Tabelle hat nur dann Aussagekraft, wenn unmittelbar zuvor oder noch besser sogar parallel ein traceroute oder ping oder ähnliches läuft, was auch eine ARP-Auflösung erfordert. Ansonsten sind die Einträge dort im Handumdrehen "expired" und werden nicht mehr angezeigt.

Bei parallelem Ping von 192.168.3.1:
Code:
# arp -a
61.1.168.192.in-addr.arpa (192.168.1.61) at 00:0c:29:d6:30:cd [ether]  on lan
Josef-PC.fritz.box (192.168.1.78) at 00:27:10:69:24:cc [ether]  on lan
? (192.168.1.46) at b4:f0:ab:c6:32:1b [ether]  on lan
? (192.168.1.4) at 00:1a:4f:ef:10:aa [ether]  on lan
HP2.fritz.box (192.168.1.249) at b4:39:d6:b8:bf:c0 [ether]  on lan
? (192.168.1.98) at 20:59:a0:bb:d5:b9 [ether]  on lan
? (192.168.1.45) at 70:ee:50:04:f6:00 [ether]  on lan
HP.fritz.box (192.168.1.224) at 2c:27:d7:17:7f:e8 [ether]  on lan
? (192.168.1.200) at 38:60:77:0d:6d:74 [ether]  on lan
NAS.fritz.box (192.168.1.9) at 00:11:32:2e:aa:9d [ether]  on lan
HTTP-Server.fritz.box (192.168.1.6) at c8:2a:14:58:09:03 [ether]  on lan
? (192.168.1.101) at 04:18:d6:27:74:bb [ether]  on lan
iPhone-von-Josef.fritz.box (192.168.1.44) at cc:08:e0:25:e7:c2 [ether]  on lan
1.1.168.192.in-addr.arpa (192.168.1.1) at 00:0c:29:e2:3e:e5 [ether]  on lan
70.1.168.192.in-addr.arpa (192.168.1.70) at 00:0c:29:58:0a:13 [ether]  on lan
? (192.168.1.102) at bc:05:43:c4:8c:b3 [ether]  on lan
39.1.168.192.in-addr.arpa (192.168.1.39) at 00:0c:29:c7:78:6b [ether]  on lan
iPad.fritz.box (192.168.1.47) at 84:29:99:61:e4:d1 [ether]  on lan
C2K8R2V1.fritz.box (192.168.1.64) at 00:0c:29:a9:12:72 [ether]  on lan
? (192.168.1.172) at * PERM PUP on lan
? (192.168.1.201) at * PERM PUP on lan
? (192.168.1.171) at * PERM PUP on lan
? (192.168.1.170) at * PERM PUP on lan
#

4. Die VPN-Konfiguration von A fehlt auch noch.

Code:
 {
                enabled = yes;
                editable = yes;
                conn_type = conntype_lan;
                name = "www.standort.b";
                boxuser_id = 0;
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
                remotehostname = "www.standort.b";
                keepalive_ip = 192.168.6.1;
                remoteid {
                        fqdn = "passwort";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "passwort";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.1.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.6.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.6.0 255.255.255.0";
        }

Am Standort A ist eine 7360 (m-net) im Einsatz. Internetzugang ist über LAN 1, wobei ein spezielles Profil installiert ist. Über LAN 1 geht es zu einem Glasfaser/Kupferwandler.
Ebenso an der Fritzbox am Standort A hängt ein weiterer Router mit der LAN IP 192.168.1.101 und WAN IP 192.168.3.105

Auch bringt nur ein Test von einem Gerät in 192.168.3.0/24 dann auch Aufschluß, ob dort abgesandte Pakete an 192.168.6.0/24 überhaupt an die 192.168.1.1 zur Weiterleitung durch den VPN-Tunnel geroutet werden oder ob die dort an ein falsches Gateway gesendet werden.

Wie soll ich das genau machen? Der 192.168.1.101 Router macht NAT. Dort sind Portfreigaben aktiv. Wenn ich z.B im 192.168.3.0er Netz auf 192.168.3.105:8080 gehe, dann komme ich korrekterweise auf meinen Webserver am Standort A.

Ich habe es auch schon versucht, den NanoBeam als Bridge laufen zu lassen und eine separate 7390 als Router dafür. Es kommt aber zum selben Problem, dass das 192.168.3.0er Netz nur vom Standort A erreichbar war.


Vielen Dank

Grüße
Stephan
 
Zuletzt bearbeitet:
Jo, so sieht das schon besser aus.

mit der LAN IP 192.168.1.101 und WAN IP 192.168.3.105
Also NAT genau in der anderen Richtung, als bei mir.
Was für Portfreigaben sind da eingetragen?
Ist das 192.168.6.0 Netz mit freigegeben?
 
Zuletzt bearbeitet:
Was kann ich machen, wenn ich die Richtung so belassen möchte? Brauche in dann zusätzliche Einträge in der Access List am Standort A?
 
EDIT: Ok, ich musste kurz etwas anderes machen, ihr seid schon weiter ... erst mal ignorieren, ich lese die neuen Sachen mal schnell.
EDIT2: Ne, habe ich offenbar mit meinem Unverständnis tatsächlich das Problem getroffen. Dann mal in einem neuen Beitrag weiter, bitte mal einen dazwischen setzen, damit ich nicht hintereinander schreiben muß. :)

Wenn der Ubiquitti Nano Beam aber wirklich NAT macht, und in die richtige Richtung, dann werden eigentlich keine zusätzlichen Routen und auch kein zusätzlicher Eintrag in der accesslist gebraucht.
Ja, allerdings plagt mich die Frage, wie dieser Richtfunk-Router nun wirklich konfiguriert ist bzw. was da an Netzen so läuft. Wenn der Ubi-Dingsda irgendwelches NAT macht, woher und wohin denn dann eigentlich ?

Hat der nun auf der FRITZ!Box-Seite tatsächlich die 192.168.3.0/24 ? Wenn ja, kann aktuelle Firmware m.W. keine Route einrichten, weil dann das Gateway nicht lokal zu "dev lan" ist.

Wenn der die 192.168.3.0/24 auf seiner LAN-Seite einsetzt und auf der FRITZ!Box-Seite eine Adresse aus 192.168.1.0/24, dann kann der zwar NAT zwischen den Netzen machen, dann "redet" das Netz bei .6 aber keinesfalls mit dem bei .3, da ja alles von dort bei .6 immer als "masquerading" über die .1-Adresse ankäme.

Irgendwie verstehe ich die Konstellation so überhaupt nicht, wenn das in etwa so aussieht:
Code:
NetworkC(192.168.3.0/24) <-Ubiquitti mit NAT-> NetworkA(192.168.1.0/24) <-AVM-VPN-> NetworkB(192.168.6.0/24)
Da funktioniert der Kontakt von NetworkB zu NetworkC dann nur über ein Reverse-NAT (aka Portweiterleitungen) im Ubiquitti-Router (und dann auch zur Adresse des Ubiquitti in NetworkA) ... oder wo liegt mein Denkfehler ?

Das funktioniert doch nur so:
Code:
NetworkC(192.168.3.0/24) <-Ubiquitti [B]ohne[/B] NAT-> NetworkA(192.168.1.0/24) <-AVM-VPN-> NetworkB(192.168.6.0/24)
Die 6360 würde zwar - wenn die Standardroute auf "dev dsl" zeigt - den Verkehr zu 192.168.3.0/24 auch über die Verbindung zur 192.168.1.0/24 senden (am Ende entscheidet die "accesslist" darüber, ob der Verkehr durch den Tunnel geht oder nicht) und die 192.168.1.1 leitet den dann an die 192.168.3.1 weiter, wenn dort die Route passt ... aber wo zum Teufel ist da irgendein NAT im Spiel ? Wenn die FB A den Traffic an eine 192.168.1.0/24-Adresse des Ubiquitti weiterleiten würde (die hätte er nach meinem Verständnis bei NAT), dann müßte der erst einmal durch die (bei NAT mit Connection-Tracking immanente) Firewall ins 192.168.3.0/24-Netz gelangen.

Entweder ich stelle mich wirklich zu blöd an oder ich habe hier etwas vollkommen falsch verstanden. Wenn da tatsächlich ein NAT mit CT zwischen 192.168.1.0/24 und 192.168.3.0/24 sitzt, verstehe ich nicht, wie das mit dem iPhone (das dann sicherlich eines von den Geräten 170-172 oder 201 ist) funktionieren kann - mit der 6360 funktioniert es ja offenbar nicht, was ich dann wieder sehr beruhigend finde.
 
Zuletzt bearbeitet:
Brauche in dann zusätzliche Einträge in der Access List am Standort A?
Nein, wie ich schon in #4 schrieb: VPN ist so alles OK.
Probleme macht das falschrumme NAT im anderen Router.
Bitte nochmal #11 (wurde geändert) lesen und beantworten.
 
Zuletzt bearbeitet:
Hat der nun auf der FRITZ!Box-Seite tatsächlich die 192.168.3.0/24 ? Wenn ja, kann aktuelle Firmware m.W. keine Route einrichten, weil dann das Gateway nicht lokal zu "dev lan" ist.

Fritzbox seitig hat der Ubiquitti 192.168.1.101.

Bildschirmfoto 2015-01-10 um 14.12.06.png

rgendwie verstehe ich die Konstellation so überhaupt nicht, wenn das in etwa so aussieht:
Code:
NetworkC(192.168.3.0/24) <-Ubiquitti mit NAT-> NetworkA(192.168.1.0/24) <-AVM-VPN-> NetworkB(192.168.6.0/24)

Genau so ist die Konstellation


Was für Portfreigaben sind da eingetragen?
Ist das 192.168.6.0 Netz mit freigegeben?
Siehe Grafik
Bildschirmfoto 2015-01-10 um 14.17.00.png

Wie soll ich das 6er Netz freigeben?
 
Zuletzt bearbeitet:
Ich sehe ehrlich gesagt die Notwendigkeit des NAT am Ubiquitti-Router nicht. Wohin geht denn dessen WAN-Verbindung, wenn dahinter noch ein privates Netz hängt ?

Eigentlich müßte nur das Standard-Gateway im 192.168.3.0/24-Netz per Routing-Table "wissen", daß die Daten an 192.168.1.0/24+192.168.6.0/24 (vermutlich noch weitere Netze, wenn ich mir die vpnroutes so ansehe) an das Gateway mit der WAN-Adresse des Ubiquitti gesendet werden müssen. Wofür wird da ein NAT benötigt ?

Vielleicht kannst Du ja noch etwas zum Zweck und den notwendigen Diensten/Verbindungen jenseits der Richtfunkstrecke sagen. Ist die 7360 für das 192.168.3.0/24-Netz das Standard-Gateway und wenn nicht, hat deren Standard-Gateway eine Ahnung, daß Pakete an 192.168.6.0/24 via 192.168.3.irgendwas (keine Ahnung, was der NanoBeam da für eine Adresse hat) zu routen wären ?

Ich komme eigentlich immer mehr zu dem Verdacht, daß tatsächlich "nur" der Rückweg aus 192.168.3.0/24 nach 192.168.6.0/24 unklar ist.

stephensworld schrieb:
Wie soll ich das 6er Netz freigeben?
Du kannst kein komplettes Netz mit einer Portfreigabe behandeln.
 
Am besten, du erklärst uns erst einmal was, warum und wie diese ganze Konstruktion arbeiten und wirken soll.
 
Ich sehe ehrlich gesagt die Notwendigkeit des NAT am Ubiquitti-Router nicht. Wohin geht denn dessen WAN-Verbindung, wenn dahinter noch ein privates Netz hängt ?
Wir haben in der Gegend ein halboffenes Wlan Netz. Also ganz privat ist es nicht und es soll nur der Zugriff auf ein paar Dienste am Standort A freigegeben sein. Deshalb die Portweiterleitung etc.
Das funktioniert ja schon alles. Es geht mir nur darum, dass ich von meinem Standort B aus auch auf manche Dienste im WLan Netz zugreifen kann.
 
Ok, das ist mir aber immer noch zu schwammig, sorry.

Damit ist dann das LAN 192.168.1.0/24 am NanoBeam die private Seite und dort stehen auch die Dienste, auf die aus 192.168.3.0/24 zugegriffen werden soll ?

Wie weiß denn jetzt ein Gerät im 192.168.3.0/24-Netz, daß es da 192.168.6.0/24-Netz überhaupt gibt und wie man dorthin gelangt ? Der Nanobeam kann ja wohl kaum das Default-Gateway im 192.168.3.0/24-Netz sein, wenn er nur NAT dahin macht. Dann nimmt er ja den Verkehr aus 192.168.3.0/24 nur dann entgegen, wenn es entweder eine Antwort auf einen Request aus 192.168.1.0/24 oder dahinter ist oder der Verkehr an einen freigegebenen Port geht.

Wenn Du schreibst
stephensworld schrieb:
Der 192.168.1.101 Router macht NAT. Dort sind Portfreigaben aktiv. Wenn ich z.B im 192.168.3.0er Netz auf 192.168.3.105:8080 gehe, dann komme ich korrekterweise auf meinen Webserver am Standort A.
dann läßt das eigentlich nur die Schlußfolgerung zu, daß der Nanobeam auf der WAN-Seite die 192.168.3.105 hat. Wer ist denn dann bitte die 192.168.3.1 aus dem traceroute in #3 ? Da müßten dann ja gleich zwei Hops (192.168.1.1 und 192.168.1.101/192.168.3.105 - je nachdem, welche Seite des Nanobeam man erwartet) fehlen ?

Das verwirrt mich zugegebenermaßen alles unendlich ... aber am Ende bleibt noch die Frage übrig, ob der Nanobeam denn auch weiß, daß er Pakete an die 192.168.6.0/24 (so die wirklich auf seiner LAN-Seite ohne irgendwelche Adressänderungen ankommen), die sich nach der "Rückübersetzung" durch das CT bei ihm finden, über die 192.168.1.1 schicken muß. Wenn er das nicht weiß und die an sein WAN-Interface zurücksendet, werden sie auch nie bei der 6360 ankommen.

Ich weiß, daß man nicht alles über sein Netz preisgeben soll, aber - nimm's mir übel oder nicht - während Du recht "maulfaul" mit konkreten Details oder Zielen bist, kriegst Du immer umfangreiche und begründete Antworten - einfach damit Du den Sinn einer Nachfrage auch verstehst und das nicht als "Beschäftigungstherapie" und reine Neugierde (von Leuten, die am Ende doch keine Ahnung haben) abhakst. Dann darfst Du aber auch mal etwas ausführlicher antworten, weil die ausschließliche Kommunikation in Stichworten bei sehr unterschiedlichem Know-How und Wissen um die konkreten Bedingungen zu mehr Konfusion und weniger Lösungen führt.
 
Frage übrig, ob der Nanobeam denn auch weiß, daß er Pakete an die 192.168.6.0/24 (so die wirklich auf seiner LAN-Seite ohne irgendwelche Adressänderungen ankommen), die sich nach der "Rückübersetzung" durch das CT bei ihm finden, über die 192.168.1.1 schicken muß.
Richtig, da muß auch noch eine Route rein, so ähnlich wie bei der FB, dann sollte es gehen.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.