Zyxel Firewall [VPN Routing] - Verkeer omleiden van VPN-tunnel naar een andere VPN-site [VPN Routing].

In dit artikel wordt uitgelegd hoe je verkeer van een site-to-site tunnel naar een andere tunnel kunt routeren om apparaten achter een site-to-site verbinding te bereiken. Het legt uit hoe je verkeer van site A naar site B routeert via HQ firewall / gateway (route site-to-site door site-to-site tunnel), problemen oplost, routeringsregels als je wilt dat je client VPN's een server bereiken die zich op een andere site bevindt (client-to-site door site-to-site), SecuExtender IPSec configuratie.

Alternatief 1: Verkeer routeren van Remote VPN tunnel naar een andere site-to-site VPN

1) VPN-tunnels opzetten

Voorwaarde: Er moet al een site-to-site verbinding zijn tussen de locaties.

Zodra de tunnel is opgezet, zullen we deze verbinden met behulp van L2TP over IPSec.

Voor instructies over het opzetten van een VPN, zie:

VPN - IPSec site-to-site VPN configureren

Hier vindt u informatie over L2TP over IPSec:

VPN - L2TP over IPSec VPN met PSK configureren [Stand-alone modus].

Om het proces te vereenvoudigen, kunt u de wizard gebruiken voor het maken van een VPN-tunnel en L2TP over IPSec.

2) Routingbeleid configureren

Om verkeer tussen het hoofdkantoor (HQ) en site B mogelijk te maken, moet je beleid en routes instellen voor de VPN-tunnel.

Op de HQ firewall:

1. Maak een beleidsroute aan die inkomende verzoeken van de L2TP-tunnel naar de Site B-tunnel routeert. Dit is het routeren van inkomende verzoeken van de L2TP-tunnel door de HQ Firewall naar de Site B-tunnel

   • Bron: L2TP cliënt subnet
   • Bestemming: Subnet Site B
   • Next-hop: VPN-tunnel "Site B tunnel".

Merk op dat het bestemmingsadres het adres van onze client is.

2. Maak een beleid aan dat reacties van Site B toestaat en routeer ze in de tunnel naar Site B. Dit is cruciaal voor het verkeer dat terugkeert van Site B naar HQ.

• • Bron: Elke
  • Bestemming: L2TP-tunnel
  • Next-hop: VPN-tunnel "L2TP-tunnel

Op locatie B:

1. Maak ook een beleidsroute die inkomende verzoeken van HQ toestaat en deze doorstuurt in de tunnel naar Site B. Maak dus ook een beleidsroute die antwoorden van HQ toestaat en deze doorstuurt in de tunnel naar Site B:

Zorg ervoor dat Asymmetric Routing is ingeschakeld voor naadloze connectiviteit. Je vindt deze optie hier:

Configuratie > Beveiligingsbeleid > Beleidscontrole

Als je deze functie inschakelt, wordt de "driehoekige" route geactiveerd, waardoor de firewall een asymmetrische routetopologie in het netwerk kan gebruiken en verbindingsresets kan voorkomen wanneer er antwoorden terugkomen.

Door deze stappen te volgen, kun je effectief verkeer routeren tussen je VPN-tunnels en een soepele en veilige verbinding onderhouden tussen HQ en Locatie B.

Alternatief 2: Routering van VPN-tunnel naar een andere VPN-site

1) Routeer verkeer van Site A naar Site B via HQ Site

Als je wilt dat site A site B bereikt en vice versa, dan moet je beleidsroutes maken op elke firewall om de HQ firewall te laten weten waar de verzoeken naartoe gestuurd moeten worden die binnenkomen, en waar ook de antwoorden naartoe gestuurd moeten worden.

1.1 Beleidsroutes - HQ firewall

Op de HQ firewall moet je eerst een regel configureren die verzoeken toestaat die van Site A komen en naar Site B gaan. Deze moeten in de tunnel naar Site B worden gerouteerd, en dit is belangrijk voor zowel ICMP verzoeken (die van Site A komen), maar ook voor ICMP antwoorden (die van Site B komen en nu weer teruggaan naar Site B).

Inkomend: elk - Bron: "Site A subnet" -> Bestemming: "Site B subnet" - Next-hop Tunnel - "Site B VPN-tunnel".

Ten tweede moet je een regel configureren die antwoorden toestaat van Site B die naar Site A gaan (wanneer je een verzoek hebt verzonden vanaf Site A) en die moeten worden omgeleid naar de Site A tunnel. Dit is belangrijk voor zowel ICMP verzoeken (afkomstig van Site B), maar ook voor ICMP antwoorden (afkomstig van Site B en nu weer terug naar Site A).

Inkomend: elk - Bron: "Site B subnet" -> Bestemming: "Site A subnet" - Next-hop Tunnel - "Site A VPN-tunnel".

1.2 Policy Routes - Site A Firewall

Vervolgens moet je een regel configureren die verzoeken toestaat die van Site B komen en naar Site A gaan (wanneer je een verzoek hebt verstuurd vanaf Site B). Deze moeten"terug" worden geleid in de tunnel van Site A, en dit is belangrijk voor zowel ICMP verzoeken (afkomstig van Site B), maar ook voor ICMP antwoorden (afkomstig van Site B en nu weer terug naar Site B).

Inkomend: elk - Bron: "Site B subnet" -> Bestemming: "Site A subnet" - Next-hop "Site A VPN-tunnel".

1.3 Beleidsroutes - Site B Firewall

Vervolgens moet je een regel configureren die verzoeken toestaat die van Site A komen en naar Site B gaan (wanneer je een verzoek hebt verstuurd vanaf Site A). Deze moeten"terug" gerouteerd worden naar de Site B tunnel, en dit is belangrijk voor zowel ICMP verzoeken (afkomstig van Site A), maar ook voor ICMP antwoorden (afkomstig van Site A en nu weer terug naar Site A).

Inkomend: elk - Bron: "Site A subnet" -> Bestemming: "Site B subnet" - Next-hop "Site B VPN-tunnel".

2) Verificatie / probleemoplossing

Wanneer je alle beleidsroutes hebt geconfigureerd, is het belangrijk om te controleren of de routering echt werkt. Misschien heb je conflicterende routes in je firewall regels (subnet overlappingen, bestaande beleid/statische routes etc.) of is er iets anders mis.

Merk op dat dit erg verwarrend kan zijn omdat er veel routes zijn die je moet controleren. De eenvoudigste manier om dit te doen is om handmatig alle pakketstromen in kaart te brengen op papier (PC -> Gateway A - gateway moet naar HQ routeren, HQ moet naar Site B routeren - Site B moet het antwoord weer terug routeren naar HQ ... etc.), vraag jezelf af - "wie is verantwoordelijk voor de routering, en is de routering op zijn plaats?".

Hieronder vind je twee scenario's waarbij je mogelijk configuraties moet wijzigen om de routering te laten werken.

2.1 Test door de firewall te pingen

Het eerste is testen door te pingen vanaf een pc op locatie A naar een server of pc op locatie B:

Rode pijl - ICMP [ping] Verzoek

Groene pijl - ICMP [ping] Antwoord

2.2mBeleid Routes - Site A Firewall

Als je de Site B Gateway pingt vanaf de Site A Gateway (ingebouwde ICMP tool), zal de policy routing op Site A niet van toepassing zijn op de antwoorden terug van de Site B, als Site B de Site A Gateway probeert te pingen.

Daarom hebben we een beleidsroute nodig die er als volgt uitziet:

Inkomend: ZyWall- Bron: "Site B subnet" -> Bestemming: "Site A subnet" - Next-hop "Site A VPN tunnel".

2.3 Policy Routes - Site B Firewall

De eerste test die je kunt doen is de firewall pingen, echter, omdat de routering die je nu hebt aangemaakt ALLEEN voor Inkomende is (met uitzondering van Zywall), betekent dit dat de routering niet van toepassing is als de ping van Site A komt, de Site B Firewall bereikt en de Firewall vervolgens verantwoordelijk is voor het reageren op dat verzoek. Het ICMP-antwoord ziet er dan als volgt uit:

ICMP Verzoek

PC (ICMP Verzoek) -> Site A Gateway -> VPN tunnel naar HQ -> HQ Gateway stuurt verkeer naar Site B Gateway

ICMP Antwoord

Site B Gateway (ICMP-antwoord) -> Site B Gateway -> VPN-tunnel naar HQ -> HQ Gateway stuurt verkeer naar Site A Gateway -> Site A Gateway stuurt pakketten terug naar PC

Daarom is deze beleidsroute nodig:

Inkomend: ZyWall- Bron: "Site A subnet" -> Bestemming: "Site B subnet" - Next-hop "Site B VPN tunnel".

2.4 Test door een server / PC te pingen

Omdat de PC zich op het 192.168.20.0/24 netwerk bevindt en de server zich op het 192.168.30.0/24 netwerk bevindt, herkent de server het 192.168.20.0/24 netwerk niet en daarom zal de server zeer waarschijnlijk ICMP pakketten blokkeren die van onbekende subnetten komen. Daarom moet bij het uitvoeren van tests altijd:

• Schakel elke ingebouwde firewall uit (bijv. Windows Defender / Firewall)
• Schakel andere antivirus- en eindpuntbeveiligingssoftware die op de server / pc is geïnstalleerd uit.

Routeer verkeer van klant naar site via een site-naar-site tunnel

Let op: Dit werkte niet met Dynamic VPN! Selecteer alleen Site2Site VPN!

1) Configureer SecuExtender IPSec VPN

Om IPSec VPN-clients naar een andere tunnel te leiden, moeten ze vaste IP-adressen gebruiken.

Als het nodig is om veel verschillende clients te routeren, is het aan te raden om IP's te gebruiken die dicht bij elkaar liggen, zodat een bereik kan worden gecreëerd. Dit vermindert het aantal benodigde routes.

Het subnet waarin de IP-adressen zich bevinden hoeft niet aanwezig te zijn op de firewall.

Voer het vaste IP-adres in op de IPSec VPN-client

2) Firewall routering configureren

Navigeer op de firewall naar

Configuration > Object > Address

en klik op

Add

om het bereik aan te maken voor de IP-adressen van de IPSec VPN-client.

Nu kunnen we de benodigde routes toevoegen onder

Configuration > Network > Routing

met een klik op de

Add

2.1 Firewall op locatie

We moeten twee routes aanmaken:

• Eén voor het uitgaande verkeer, dus van de dynamische VPN-client tunnel naar het remote subnet over de site-to-site tunnel.

• Eén voor het inkomende verkeer, dus van het remote subnet over de site-to-site tunnel naar de VPN-client tunnel.

De nieuwe routes zouden er ongeveer zo uit moeten zien:

Een andere manier om het inkomende verkeer van het externe subnet over de externe VPN-tunnel te laten gaan, is door "asymmetrische route" in te schakelen:

Dit zal de "driehoek" route inschakelen waardoor de firewall het gebruik van asymmetrische routetopologie in het netwerk toestaat en de verbinding niet reset wanneer het antwoord terugkomt.

2.2 Firewall op locatie B

Op de externe locatie kan het nodig zijn om gelijkaardige routes aan te maken zodat het apparaat op de hoofdlocatie weet hoe het het verkeer van de VPN-klanten die van de bijkantoren komen, moet behandelen.

Op de hoofdlocatie maken we de IP-range aan voor de VPN-cliënten op afstand, zodat we die kunnen gebruiken om het verkeer te routeren.

Nu maken we ook de corresponderende routes aan op de HQ site.

Eén uitgaande route, dus van het HQ subnet over de site-to-site tunnel naar de remote VPN-clients.

En één inkomende route, dus vanuit het bereik van de remote VPN-klanten over de site-to-site tunnel naar het lokale LAN van HQ. Als verkeer wordt gerouteerd naar een lokaal subnet selecteren we "Auto" als next-hop, de USG beheert dit automatisch.

De routes zouden er ongeveer zo uit moeten zien:

+++ U kunt licenties kopen voor uw Zyxel VPN-clients (SSL VPN, IPsec) met onmiddellijke levering door 1-click: Zyxel Webstore +++