XG115 hinter Fritzbox 7590 - Kein Site to Site zum Branch Office

agnostiker

Cadet 1st Year
Registriert
Juli 2020
Beiträge
8
Hallo Gemeinde:

Die XG115 haengt mit ihrem WAN port ( 192.168.0.2 ) an dem Lan2 Port der Fritzbox ( 192.168.0.1 ), der Lan1 Port der Fritzbox ist mit unserem Switch verbunden. Die XG115 haengt mit ihrem LAN Port ( 172.16.0.1 ) ebenfalls am Switch.

Es geht um einen IPSEC Site2Site Tnnel, auf der Fritzbox sind keine User eingetragen und auch keine VPN Dienste aktiviert.
Es wurde der WAN Port der UTM ( 192.168.0.2 ) als Exposed Host definiert - kein erfolg.
Es wurden folgende Ports manuell geforwarded an 192.168.0.2:

TCP10000
UDP500
UDP4500
TCP50
ESP

Auch keinerlei Erfolg.

Es wurde so konfiguriert das diese Aussenstelle die Verbindung initiiert, aber leider sieht man weder in der GUI noch sonstwo den Fehler, ausser ein "Verbindung konnte nicht erstellt werden" sieht man leider nichts.
 
Wichtigste Frage: Ist es in irgendeiner Art und Weise möglich dass wenigstens die XG in der "Zentrale" eine öffentliche IP bekommen kann statt einer geNATtetten, und sei es durch Vertragsumstellung?

Fritzbox/Exposed Host mit IPSec ist ein absoluter Krampf ohne öffentliche IPs.

Und warum hängen Sophos & Fritzbox mit ihren LAN-Buchsen am selben Switch? Irgendwas mit VLANs getrennt?
 
  • Gefällt mir
Reaktionen: agnostiker
Und wenn die XG an LAN1 ist, gehts dann? Soll der Switch gesondert laufen? Normal wäre der Aufbau FB - XG - Switch, die FB spielt dann quasi nur Modem mit Transfernetz zur eigentlichen Firewall.
Hab mit der Kombo aber generell bei IPsec (mit Cisco ASA dahinter) keine guten Erfahrungen gemacht.
 
  • Gefällt mir
Reaktionen: agnostiker und neo243
t-6 schrieb:
Wichtigste Frage: Ist es in irgendeiner Art und Weise möglich dass wenigstens die XG in der "Zentrale" eine öffentliche IP bekommen kann statt einer geNATtetten, und sei es durch Vertragsumstellung?

Die XG in der Zentralle hat eine Feste Public IP.

Fritzbox/Exposed Host mit IPSec ist ein absoluter Krampf ohne öffentliche IPs.

Beide XGs haben eine Public IP.

Und warum hängen Sophos & Fritzbox mit ihren LAN-Buchsen am selben Switch? Irgendwas mit VLANs getrennt?
Öhm, das hat keinerlei gesonderten Grund, was sollte denn geaendert werden ?
Ergänzung ()

corvus schrieb:
Und wenn die XG an LAN1 ist, gehts dann? Soll der Switch gesondert laufen? Normal wäre der Aufbau FB - XG - Switch, die FB spielt dann quasi nur Modem mit Transfernetz zur eigentlichen Firewall.

genau so habe ich mir das gedacht und auf dein "anraten" hin gemacht, also aufbau ist jetzt:

Tae -> Fritzbox -> Lan1 -> Wan Port Sophos. NUR der Lanport Sophos ist jetzt am Switch.

Lan1: 192.168.0.1
WanPort Sophos: 192.168.0.2
LanPort Sophos: 172.16.0.1 ( gibt DHCP )
 
Zuletzt bearbeitet:
Jo das ist der eigentlich korrekte Aufbau. Funktioniert der Tunnel? Falls nein, muss es überhaupt IPsec sein?
 
corvus schrieb:
Jo das ist der eigentlich korrekte Aufbau. Funktioniert der Tunnel? Falls nein, muss es überhaupt IPsec sein?

Es muss kein IPSEC sein, es muss nur moeglich sein das die Geräte hier ( in dem Fall IP Telefone ) einen Server erreichen welcher in der Zentrale steht.
 
t-6 schrieb:
192.168.0.1 hat die Fritzbox, 192.168.0.2 dann eben das Lan interface der Sophos ? Dann sag doch mal wie es richtig geht....
Ergänzung ()

h00bi schrieb:
Was genau macht die FB in diesem Setup?
Wird die nur als DSL Modem missbraucht? Kann die Sophos kein PPPoE?

Die FB habe ich hier nur weil sie von der Telekom vorgeschrieben war, vorher gabs keine Sophos. Die Sophos ist soweit ich weiss PPPoE fähig, vielleicht kann das einer der Profis hier bestätigen. Ich habe die zugangsdaten natuerlich hier, falls ich mir damit arbeit erspare dann wuerde ich auch denn pppoe weg gehen, ist das denn einfacher ?
 
Zuletzt bearbeitet:
Ist denn VPN in der FB aktiv?
Nichts im Log des XG deutet ja darauf hin, dass dort erst gar nichts ankommt.
Wenn die FB auf demselben Port einen Service hostet geht Weiterleiten nicht mehr wirklich, auch wenn die FB die Config so frisst.
Ob User für VPN angelegt sind ist erstmal latte, aber der Service muss aus sein.
*edit: Die Topologie passt in deinem Fall, ist halt doppeltes NAT. TAE => FB(WAN) / FB(LAN) => XG(WAN) / XG(LAN) => Switch.

*edit2: Auslesbar in der FB unter Diagnose => Sicherheit => FB eigene Dienste.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: agnostiker
Merle schrieb:
Ist denn VPN in der FB aktiv?

Keiner User angelegt und auch nichts aktiv.

Nichts im Log des XG deutet ja darauf hin, dass dort erst gar nichts ankommt.
Wenn die FB auf demselben Port einen Service hostet geht Weiterleiten nicht mehr wirklich, auch wenn die FB die Config so frisst.

Das ist es ja, es passiert einfach nichts...

Ob User für VPN angelegt sind ist erstmal latte, aber der Service muss aus sein.
*edit: Die Topologie passt in deinem Fall, ist halt doppeltes NAT. TAE => FB(WAN) / FB(LAN) => XG(WAN) / XG(LAN) => Switch.

Was haellst Du denn von der Idee die Zugangsdaten direkt auf der Sophos zu nutzen und die FB rauszuwerfen...
 
Wenn die FB rausfliegt (bzw. nur noch als Modem dient) kann sie keine Services mehr hosten und das XG ist komplett nach außen exponiert und hat direkt die public IP. Ist wartungsfreundlicher, einfacher zu verstehen, aber das Regelwerk muss dann auch passen! Im Fall der FB als Router (nicht als Modem) ist es immerhin sowas wie ein zweistufiges FW System, bei welchem die Außenseite für Consumer schon geschützt wird. Ich denke du kannst es versuchen, ich habs lieber zweistufig wenn die FB schon Strom frisst.
 
Merle schrieb:
Wenn die FB rausfliegt (bzw. nur noch als Modem dient) kann sie keine Services mehr hosten und das XG ist komplett nach außen exponiert und hat direkt die public IP. Ist wartungsfreundlicher, einfacher zu verstehen, aber das Regelwerk muss dann auch passen! Im Fall der FB als Router (nicht als Modem) ist es immerhin sowas wie ein zweistufiges FW System, bei welchem die Außenseite für Consumer schon geschützt wird. Ich denke du kannst es versuchen, ich habs lieber zweistufig wenn die FB schon Strom frisst.

Ich meinte mit raus, komplett raus. Das bedeutet die Sophos haengt an der TAE und die FB liegt im Schrank...
 
So ist es vermutlich bei euch:
Die Fritzbox hat die "echte" öffentliche IPv4 an ihrem WAN-Anschluss (Kabel oder DSL - gerade egal).
Nach "innen" hat die Fritzbox die LAN-IP 192.168.0.1
Der WAN-Port der Sophos hat die IP 192.168.0.2
(Das LAN-Interface der Sophos hat 172.16.0.1)

Heißt: Nicht die Sophos selber hat die öffentliche IP, sondern eben die Fritzbox, egal ob die Sophos "Exposed Host" ist oder nicht.
Die Fritzbox muss zunächst immer alle eingehenden Ports übersetzen/NATten - womit IPSec so gerne seine vielen Probleme mit hat.

Um das zu lösen, muss die Sophos die öffentliche IP des Anschlusses bekommen. Wie genau das umgesetzt wird, hängt ein wenig von der Anschlussart ab und hat ein paar Konsequenzen.

Im Fall der FB als Router (nicht als Modem) ist es immerhin sowas wie ein zweistufiges FW System, bei welchem die Außenseite für Consumer schon geschützt wird.
...was durch Exposed Host direkt wieder ausgehebelt wird.

Es gibt in der Konstellation keinen sinnvollen Grund warum die Firewall noch mal geNATted werden müsste und eher nur Probleme.

Ich meinte mit raus, komplett raus. Das bedeutet die Sophos haengt an der TAE und die FB liegt im Schrank...
Mh, jein. Die Sophos braucht halt immer ein vorgeschaltetes Modem*, es gibt aber SFP-Module für XGs die bereits ein VDSL-Modem integriert haben. Afaik aber nicht mit Vectoring.
 
  • Gefällt mir
Reaktionen: agnostiker
t-6 schrieb:
So ist es vermutlich bei euch:
Die Fritzbox hat die "echte" öffentliche IPv4 an ihrem WAN-Anschluss (Kabel oder DSL - gerade egal).
Nach "innen" hat die Fritzbox die LAN-IP 192.168.0.1
Der WAN-Port der Sophos hat die IP 192.168.0.2
(Das LAN-Interface der Sophos hat 172.16.0.1)

Exakt so ist es!!!

Heißt: Nicht die Sophos selber hat die öffentliche IP, sondern eben die Fritzbox, egal ob die Sophos "Exposed Host" ist oder nicht.
Die Fritzbox muss zunächst immer alle eingehenden Ports übersetzen/NATten - womit IPSec so gerne seine vielen Probleme mit hat.

Ich merks gerade wieder .....

Um das zu lösen, muss die Sophos die öffentliche IP des Anschlusses bekommen. Wie genau das umgesetzt wird, hängt ein wenig von der Anschlussart ab und hat ein paar Konsequenzen.

Hast Du einen Vorschlag ?
 
agnostiker schrieb:
Es wurde so konfiguriert das diese Aussenstelle die Verbindung initiiert, aber leider sieht man weder in der GUI noch sonstwo den Fehler, ausser ein "Verbindung konnte nicht erstellt werden" sieht man leider nichts.
Was zeigt denn das Log in der Hauptstelle an?
Damit die Außenstelle eine Verbindung zur Hauptstelle aufbaut sind normalerweise weder eine feste IP noch irgendwelche Portweiterleitungen in der Außenstelle notwendig.
Du kannst hier zwar jetzt los rennen und die Fritzbox rauswerfen und ein reines VDSL Modem anschaffen, das hat meiner Meinung nach jedoch nichts mit dem eigentlichen VPN Problem zu tun.
 
Hast Du einen Vorschlag ?
Wie schon erwähnt wurde: Waschechtes Modem* vor die Sophos. WAN-Schnittstelle der Sophos auf PPPoE umkonfigurieren. Fertig.
(Bei einem Telekom VDSL-Anschluss noch drauf achten, dass VLAN Tag 7 gesetzt wird)

edit, nicht vergessen: Wenn die Fritzbox bei euch Telefonie macht, fällt das zunächst weg.

*bzw. ein Modemrouter, der als PPPoE-Device/Bridge genutzt werden kann; bei Fritzboxen ist das seit ein paar Jahren nicht mehr möglich.
 
agnostiker schrieb:
Die XG115 haengt mit ihrem WAN port ( 192.168.0.2 ) an dem Lan2 Port der Fritzbox ( 192.168.0.1 ), der Lan1 Port der Fritzbox ist mit unserem Switch verbunden. Die XG115 haengt mit ihrem LAN Port ( 172.16.0.1 ) ebenfalls am Switch.
Wie schon geschrieben wurde ist das wenig sinnvoll und stellt eine weitere Fehlerquelle dar. Eine Firewall trennt die Netze WAN und LAN, aber wenn man das LAN hintenrum dann wieder an den Switch anklemmt, an dem auch das WAN hängt, ist die Trennung hinfällig.


agnostiker schrieb:
Es wurde der WAN Port der UTM ( 192.168.0.2 ) als Exposed Host definiert - kein erfolg.
Es wurden folgende Ports manuell geforwarded an 192.168.0.2: [..] Auch keinerlei Erfolg.
Ich würde sagen man muss jetzt mal Schritt für Schritt vorgehen. Wenn die Fehlermeldungen keinerlei Aufschluss geben, muss man eben ein Szenario bauen, in welchem man das Fehlerergebnis besser bewerten kann. Wenn man jetzt zB einen PC* mit WireShark/tcpdump an die Fritzbox hängt und die Portweiterleitungen auf diesen PC zeigen lässt, kann man zumindest mal sehen ob die Portweiterleitungen funktionieren oder ob am Ende gar die Firewall der Außenstelle die Ports ausgehend blockiert. Wenn sichergestellt ist, dass die Verbindung von der Außenstelle korrekt bei der Hauptstelle ankommt und sauber weitergeleitet wird, kann man sich anschauen warum denn trotzdem keine Verbindung zur XG115 hergestellt werden kann. Ansonsten bastelt man hier wie doof an der Fritzbox rum und am Ende sitzt die Ursache im Netzwerk der Außenstelle...........


* natürlich kann man jetzt argumentieren, dass man auch am XG115 nach eingehenden Paketen suchen kann, aber die XG115 ist unter Umständen Teil des Problems und dann ist es fraglich ob man sich auf einen Test mit dem potentiell fehlerbehafteten System verlassen kann.
 
Myron schrieb:
Was zeigt denn das Log in der Hauptstelle an?

Weder das Log hier NOCH das in der Haupstelle zeigt irgendwas an. Ich sehe hier nicht ob/das was raus geht und dort nicht ob/das was rein kommt.

Damit die Außenstelle eine Verbindung zur Hauptstelle aufbaut sind normalerweise weder eine feste IP noch irgendwelche Portweiterleitungen in der Außenstelle notwendig.

Ich dachte auch da die Verbindung von hier initiiert wird sollte forwarding etc erstmal keine rolle spielen....
 
agnostiker schrieb:
Hast Du einen Vorschlag ?
Also bei uns läuft das über IPoE.
Der Provider stellt als Router einen vorkonfigurierten OneAccess One 531 und belegt eine öffentliche IP.
Die Firewall dahinter schnappt sich per IPoE die restlichen 5 IP öffentlichen Adressen des 8er Netz.

Habt ihr auf dem Anschluss mehrere public IPs oder nur eine?
Wenn ja wäre das einfachste auf ein SVVDSL fähiges Modem umzusteigen. Gibt was von Zyxel, Draytek und ein Speedport Smart 2 oder 3 im Modem Modus wäre auch eine Option.

Zur Diagnose könntest du einen mirror fähigen Switch zwischen FB und XG hängen und dann mal mit Wireshark beobachten was sich da tut.
Ansonsten würde ich erstmal testen ob du mit einem direkt an der FB angeschlossenen Client auf die XG über den WAN Anschluss zugreifen kannst. Evtl. liegt da schon das Problem.
 
Zurück
Oben