Velen van ons in de zakenwereld gebruiken een apparaat om VPN-tunnels op te zetten en hebben mogelijk meer dan 100 IKE-peers. Vroeger was dat waarschijnlijk een ASA, maar we bevinden ons in een post-ASA wereld. Ik ben bezig met een project om de tunnels van een ASA naar Palo over te zetten en begin opnieuw na te denken of het überhaupt de moeite waard is, gezien hoe Palo beleidsgebaseerde tunnels behandelt, wat de meeste van mijn verbindingen zijn.
Als iemand iets anders gebruikt dan een Palo of een ASA - wat is het en bevalt het je?
Neem de gelegenheid te baat om ze te moderniseren en om te bouwen tot route-gebaseerd, of als ze allemaal onder jouw beheer zijn, een SDWAN-oplossing om wat administratieve overhead weg te nemen (hint - ze gebruiken bijna allemaal DMVPN en bouwen route-gebaseerde tunnels). Anderen kunnen spreken over hun voorkeursleverancier, maar misschien is het voor jou het beste om andere firewall-functies te bekijken om te bepalen wat het beste bij jouw behoeften past.
Je kunt nog steeds een firewall in ASA-modus gebruiken en het is perfect geschikt als VPN-concentrator/remote access VPN-hub. In feite gebruiken wij het daarvoor. (Hoewel de meeste van onze tunnels route-gebaseerd zijn, gelukkig)
Er zijn slechts 2 van de 3rd party partners die weigeren route-gebaseerd te doen, vanwege… redenen.
Een deel van de truc is dat we geen idee hebben hoeveel van onze vendors route-gebaseerde tunnels kunnen ondersteunen. Dus als we voor Palo gaan en tunnels hebben met honderden individuele hosts, wordt het snel een nachtmerrie op basis van wat wij zien. Het laden van 150 proxy-IDs via GUI is krankzinnig, en hoewel ik het vanaf de Palo CLI zou kunnen laden, is die expertise niet precies overvloedig in ons team.
Ik herinner me dat toen DMVPN voor het eerst uitkwam, er pagina’s vol configuratie waren van Cisco. En nu wordt het gewoon magisch gedaan onder de motorkap met een paar klikken.
Een deel van de truc is dat we geen idee hebben hoeveel van onze vendors route-gebaseerde tunnels kunnen ondersteunen.
Allemaal. Zeker 95%. We zijn net bezig geweest met de migratie van ASA/Firepower naar Fortigate. Blijkt dat de meeste van onze partners/venders/klanten voor wie we policy-gebaseerde tunnels hadden, vast hielden aan oude hardware omdat ze dachten WIJ konden geen route-gebaseerde ondersteunen. Nu zijn ze niet alleen allemaal route-gebaseerd, maar de meeste zijn redundant op dubbele ISP’s met BGP.
We zijn vendor voor vendor doorgegaan en hebben het gevraagd, then coordinate specs, een tijd gepland voor een onderhoudsvenster, instellingen ingesteld en getest.
Palo ondersteunt standaard geen policy-based aan de ene kant en route-based aan de andere kant?
Ik heb verschillende merken beheerd en had geen probleem om route-gebaseerd te koppelen aan de ene kant en policy-gebaseerd aan de andere.
Zoals ik het begrijp, heeft het te maken met de manier waarop de tunnel tot stand komt.
Als de leverancier alleen naar mij toe bouwt en mijn zijde route-gebaseerd is (versleutelingdomein 0.0.0.0/0), zou de tunnel worden opgebouwd omdat hun zijde specifieker is dan die van mij. Als dat verkeer de andere kant op gaat, van mij naar de leverancier, en zij hebben netwerken gespecificeerd aan hun zijde, zou mijn netwerk minder specifiek zijn en zou Fase 2 dus mislukken.
Dit is Reddit, dus ik hoop dat iemand komt en me vertelt of ik het mis heb.
Ik zou proberen een demo/POC te krijgen - de enige echte manier om het te weten, of je zou kunnen xposten naar /r/paloaltonetworks/.
Wij zijn een Palo-shop en hebben er een in ons lab. Mijn VPN-man heeft some bedenkingen bij de overstap naar Palo, dus ik was wat feelers aan het uitzetten.