Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 1 subscriber
  • Views 6478 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Site-to-Site VPN Routing Problem?

NvA
Hallo,
nach Aufbau einer Site-to-Site VPN (IPSec PSK) Verbindung zu einem entfernten Standort (mit einer FortiGate) kann ich vom lokalen Netz das remote Netz nicht erreichen (pingen). Der Tunnel steht, von der Astaro (ASG320) kann ich remote Rechner pingen.
Ich vermute ein Routing Problem, da wir ein recht komplexes System mit zwei WAN und Policy Based Routen haben, was ich mal zu skizieren versuche:

lokal LAN1 (192.168.1.0/24) eth0
lokal LAN2 (192.168.5.0/24) eth1
lokal WAN1 (100.100.100.100) eth5
lokal WAN2 (100.100.100.200) eth6

remote LAN 192.168.2.0/24
remote WAN 100.100.200.100

lokal Default Gateway ist WAN1.
lokal LAN1 routet über lokal WAN1 ins Internet
lokal LAN2 routet über lokal WAN2 ins Internet
Der Tunnel ist zwischen lokal WAN1 und remote WAN aufgebaut und soll lokal LAN2 und remote LAN verbinden.

Ein Ping von lokal LAN2 nach remote LAN wird über lokal WAN2 geführt, was ein Traceroute zeigt.

Leider kann keine Policy Based Route über das Interface IPSec definiert werden.

Hat jemand eine Idee?

Vielen Dank und Gruß,
Nathan


This thread was automatically locked due to age.
  • 0
    So, nach ein bisschen rumtesten geht so einiges [:)]

    Also:
    Du legst dir eine neue Policy Route der Marke: "Gateway Route" an.
    Wichtig: Diese sollte sehr weit oben stehen (nach Möglichkeit die erste Route bei den Policy Based).
    Danach legst du folgendes in der Richtline fest:
    Route Type: Gateway Route
    Source Interface: Any
    Source Network: LAN2
    Service: any
    Destination Network: remote LAN
    Gateway: remote WAN (die gleiche remote Adresse verwenden, wie sie bei site2site verwendet wird, also quasi die externe Gegenstelle).

    Danach sollte er kapieren, dass das remote LAN nicht über dein normales Policy Routing (sprich raus ins Internet) sondern über die an erster Stelle gelistete Policy Route mit dem Gateway in Form der entfernten IP-Adresse zu erreichen ist.
    Ist aber Anfang nen bissl Strange zu kapieren, aber je länger ich gerad drüber nachdenke, je mehr Sinn macht es. Problematisch wirds nur, wenn auf der externen IP der Gegenstelle ein HTTP Service läuft, den kannst du dann natürlich nicht mehr erreichen, da alles, was quasi auf die externe IP der Gegenstelle zeigt, automatisch über das VPN geleitet wird (macht man eh selten, sogenannter Orchideenfall)

    Grüße

    der Schroeder
  • 0 in reply to Schroeder
    Heureka! Das war's!
    Gateway: remote WAN hat's gebracht! 
    Ich hatte es vormals mit WAN1 getestet, was natürlich (wenn man richtig nachdenkt) ein Stück zu 'kurz' ist.
    Source Interface: LAN2 reicht schon.
    Platziert werden muss die Regel oberhalb der Regel, die (dann den Rest) Netzwerkverkehr über WAN2 schickt.

    Der Orchideen Server lässt sich dennoch erreichen (ist hier ein FTP [:)] )
    Es wird ja nur von lokal LAN2 nach remote LAN geroutet. Die remote WAN Adresse ist ja nicht in remote LAN.

    Sicherheitshalber werde ich aber noch Source Network und Services einschränken, denn die Site-to-Site Verbindung wird nur für einige Maschinen und Dienste benötigt.

    Vielen Herzlichen Dank,
    Nathan
  • 0
    Hi,

    nur so eine Idee zum PING - Leitet die FW PINGS weiter? 

    tov