Bij WatchGuard-apparaten kun je kiezen tussen BOVPN en BOVPN Virtual Interface. Ik snap het niet helemaal, welke optie is policy-based en welke route-based? Kan iemand het verschil uitleggen tussen deze twee types en ze koppelen aan de tunnels van WatchGuard?
Ik weet niet veel van WatchGuard, maar ze hebben wel vrij uitgebreide documentatie.
Het verschil tussen policy-based en route-based S2S VPNs is dat policy-based VPNs een mechanisme vereisen om verkeer te identificeren dat versleuteld moet worden en via de VPN naar de remote VPN-peer moet worden gestuurd. In de meeste gevallen is dit een ACL (ook wel ‘interesting traffic’ ACL of ‘proxy ID’ genoemd, onder andere vendor-specifieke termen) die entries bevat voor source en destination IP-subnetten die in aanmerking komen voor VPN-versleuteling. Als verkeer op de aangegeven VPN-interface aankomt en overeenkomt met deze ACL, wordt het versleuteld volgens jouw VPN-configuratie en doorgestuurd via de tunnel. Andere leveranciers verwijzen mogelijk naar dit type VPN als crypto-map gebaseerde VPNs, vanwege het gebruik van een crypto-map om jouw VPN-configuratie aan een interface te koppelen.
Route-based VPNs gebruiken geen ACL om verkeer te identificeren dat via de VPN moet, maar maken gebruik van de routingtabel op het apparaat zelf. Als een doel netwerk wordt gevonden aan de andere kant van een VPN-tunnel achter het S2S-peer apparaat in jouw netwerk topologie, moet de lokale router een entry hebben die jouw lokale virtual interface gebruikt als uitgangsinterface voor dat verkeer, en/of een next-hop IP die overeenkomt met de virtual interface IP van de remote VPN, afhankelijk van de vendor implementatie en onderliggende technologieën. Dit zal meestal een private IP zijn die behoort tot een bijbehorende virtual interface met een eigen subnet. Bijvoorbeeld, jouw lokale virtual interface kan 192.168.254.1/30 hebben en de remote virtual interface 192.168.254.2/30. Let op dat dit private IP’s zijn, geen publieke.
Andere leveranciers kunnen dit type VPN aanduiden als een Static VTI of een GRE over IPsec met Tunnel Protection VPN, wat je kunt zien als route-based. Het hangt er gewoon van af hoe ze de technologie hebben geïmplementeerd.
Hieruit kun je afleiden dat route-based VPNs een virtual interface en virtual network vereisen om de route-based VPN-topologie te vormen. Policy-based VPNs gebruiken een bestaande VPN-interface voor VPN-verbinding, meestal een internet-facing interface op je firewall.
Persoonlijk raad ik aan om route-based VPNs te gebruiken vanwege deze voordelen:
- Static VTI VPNs (SVTIs) zijn ontwikkeld om de beperkingen en inefficiënties van oude S2S VPN-technologieën te overwinnen, zoals crypto-maps, GRE over IPsec, en tunnelprotectie.
- Multicast wordt ondersteund, en dus ook protocollen die multicast gebruiken, zoals EIGRP en OSPF.
- Geen zorgen over NONAT-configuraties als je VPN-apparaat ook dynamische NAT/PAT naar het internet doet voor je interne of DMZ-netwerken.
- De totale packet size van SVTIs is kleiner dan bij GRE-tunnels, wat ze efficiënter maakt. SVTIs met Tunnel Protection gebruiken IP, niet GRE.
- SVTIs zijn schaalbaar omdat ze geen crypto-map configuraties nodig hebben, maar ‘tunnel protection’ toepassen op de virtuele tunnel interface.
- Troubleshooting is eenvoudiger, gewoon kijken naar de IKE/IPsec VPN-status en je routing tabel.
- Geen proxy-ID foutmeldingen (toont (0/0) bij CLI inspectie).
- Beter vendor support – bijvoorbeeld, MS Azure Gateways geven de voorkeur aan route-based VPNs.
Hopelijk helpt dit. Andere kunnen hier meer context aan toevoegen.
Policy gebaseerd is de traditionele manier, en gebruikt een aparte policy-tabel die de routing tabel overschrijft. Policy laat je matchen op source en destination IPs, en houdt alle ipsec policies uit je route tabel.
Route gebaseerd is een nieuwere methode die een virtual interface toevoegt, en een traditionele route gebruikt om verkeer door te sturen. Dit betekent dat het alleen op destination IP kan matchen.
Naar mijn mening zijn route-based VPNs makkelijker om te troubleshoot en te debuggen, dus gebruik ze als je kunt.
Dank voor de uitgebreide uitleg. Er is één ding waar ik niet helemaal uitkom. Als ik een policy-based VPN configureer, moet ik nog steeds de routes naar de netwerken aan de andere kant toevoegen, net als bij een route-based VPN. En in beide gevallen moet ik ACL’s met de juiste permissies instellen. Dit is wat ik ervaar bij WatchGuard, ik heb geen ervaring met andere vendors.
Al je normale routinggedrag blijft van toepassing. Het enige verschil met betrekking tot het routeren van verkeer via de VPN is de mechanisme dat wordt gebruikt om verkeer over de tunnel te sturen. Policy-based is meestal een ACL die IP’s/subnets matcht. Route-based is meestal een specifieke route die wijst naar een virtual tunnel interface om een remote VPN subnet te bereiken.
Over het algemeen blijven routers, multilayer switches en firewalls hun routing tabel raadplegen om te bepalen welke interface gebruikt moet worden om het verkeer naar het remote netwerk te krijgen en wat het volgende hop IP moet zijn. Dit is eigenlijk heel normaal en standaard routing gedrag.
ACLs zijn nodig voor beveiligingsapparaten zoals firewalls omdat deze verantwoordelijk zijn voor de handhaving van beveiligingsbeleid, inclusief L3/L4 firewall services in de vorm van een access control policy, die ACL’s schrijft om specifiek verkeer toestemming te geven of te weigeren.
Netwerkverkeer dat door een firewall moet, gaat meestal door een serie inspecties afhankelijk van de capaciteiten en functies van de firewall (zoals access control, intrusion protection, malware checks, L7 firewall, QoS). Ondanks dat je VPN-configuratie goed lijkt, moet je expliciet toestaan dat verkeer tussen de lokale en remote subnetten mag via je access control policy. Anders wordt het verkeer gedropped.
Kortom, door hun aard en gebruik wordt verkeer niet standaard toegestaan door firewalls. Je moet expliciet de gewenste verkeerstoestemmingen configureren, bij voorkeur zo specifiek mogelijk, om aan de zakelijke behoeften te voldoen. Dat is waarvoor je ACL’s dienen, onder andere.