Ik heb een klein probleempje. Ik heb 2 sites. HQ en Branch zijn beide verbonden via een site-naar-site VPN (IPsec).
HQ .: 192.168.10.x/24 Branch .: 192.168.25.x/24
Als ik in het hoofdkantoor en in het 192.168.10.x/24 netwerk ben, kan ik zonder problemen toegang krijgen tot het 192.168.25.x/24 netwerk.
Als ik thuis ben en via de FortiGate VPN IPsec-client verbinding maak met het hoofdkantoor, heb ik toegang tot het 192.168.10.x/24 -netwerk, maar ik kan het 192.168.25.x/24 netwerk.
Wat ik tot dusver heb geprobeerd:
- Firewallbeleid om verkeer van clientvpn-netwerk (
10.10.10.x/24) naar het192.168.25.x/24-netwerk en omgekeerd. - Een statische route toevoegen aan mijn pc, zodat de pc zal proberen toegang te krijgen tot het
192.168.25.x/24netwerk via10.10.10.1(FortiGate).
Traceroute wordt weergegeven op ly * * * over het proces om het 192.168.25.x/24 netwerk te bereiken.
Enig idee?
Ik heb geprobeerd de zoekopdracht te gebruiken, maar ik kon niets soortgelijks vinden.
Opmerkingen
- Bedankt. Niet gedaan. ' weet het niet, ik dacht dat het oké zou zijn om het hier te vragen.
- Heeft een antwoord je geholpen? Zo ja, dan moet je het antwoord accepteren zodat de vraag ' niet voor altijd opduiken, op zoek naar een antwoord. Je kunt ook je eigen antwoord geven en het accepteren.
Answer
Je zou een eenvoudige oplossing kunnen proberen: wanneer je verbonden bent via FortiClient, NAT je bron-IP-adres naar het bereik van het HQ-netwerk. Schakel hiervoor “NAT” in het beleid van clienttunnel naar HQ_LAN in. Vanaf dit punt wordt uw cliënt behandeld als elke host op het hoofdkantoornetwerk, inclusief routering en controle naar het filiaalnetwerk.
Als alternatief zou je een tweede fase2 kunnen bouwen alleen voor het 10.10.10.x-netwerk, aan beide zijden van de HQ-BR-tunnel, dit netwerk toevoegen aan het tunnelbeleid aan beide kanten, en routes in Branch en op de client-pc. Die laatste vereiste rechtvaardigt in plaats daarvan bijna altijd NATting.
Answer
Er kunnen verschillende problemen zijn, verwijder eerst de statische route op de VPN-client, als de route er niet is, ligt het probleem ergens anders. Post routeringstabel terwijl u verbonden bent met VPN (route PRINT).
Ik neem aan dat u “geen split-tunneling gebruikt voor de client-VPN en adverteert een standaardroute, toch? Deze zou in de routeringstabel moeten staan wanneer u verbinding maakt.
Controleer vervolgens of u netwerk 10.10.10.x / 24 in fase 2 van de HQ-Branch VPN aan beide zijden hebt gedefinieerd, zodat het direct kan communiceren (zonder NAT), het is MOET aanwezig zijn.
1.) Controleer voor beleidsregels of je de juiste bron- en bestemmingsinterfaces hebt – de bron moet ssl zijn. root (of equivalent) en IPSec VPN-interface van de bestemmingstak