Load balancing van Site2Site IPSEC tunnels met 3rd parties

[pablo_p]

Een vraag waar ik al een tijd mee zit en die nu erg actueel is:
Hoe kan je site-2-site VPN connecties 'cross-platform' geloadbalanced afhandelen, liefst met site redundancy. *edit Hierbij geldt dat de andere kant een groot aantal 3rd parties zijn, die door andere partijen beheerd worden

Deze vraag speelt bij een aantal van onze grote klanten (>50.000 werknemers). Het is een punt waar ik al geruime tijd over ana het nadenken ben

Het probleem is de inflexibiliteit van IPSEC op de volgende punten:
1. End-point is meestal statisch (fixed IP adres of een naam die fixed gekoppeld is aan een IP adres)
2. IPSEC heeft moeite met NAT. NAT-T hoort hier een oplossing voor te zijn, maar werkt niet cross-platform. Na problemen met een IPSEC tunnel met dubbele NAT tussen een Juniper ScreenOS en Cisco ASA, was het officiele antwoord van Juniper op een case hierover: "Juniper ondersteund geen NAT-T met andere partijen. Het wordt 'finger-pointing' en werking wordt niet gegarandeerd."

Gewenste situatie:

Internet <-> Load balancer <-> VPN terminators <-> Interne netwerk

Internet kan een dubbele connectie zijn (dual ISP), met verschillende subnets per ISP. Niet al onze klanten kunnen zelf BGP gaan draaien om een 'floating' geregisteerd IP subnet te hebben.

Voorkeur is een VPN naar een FQDN, waarbij deze beantwoord wordt door de DNS server in de link controller die een high-availability adres teruggeeft, behorend bij de loadbalancing Virtual server. Helaas ondersteunen de meeste endpoints dit niet

Scenario's

1. geloadbalancede VPN naar loopback interfaces op VPN gateways (1 ISP only)
Indien je een forwarding virtual server aanmaakt die load balanced over VPN Gateways in een directly connected subnet, kan je forwarden zonder het destination IP adres aan te passen, maar alleen het destination MAC adres. Indien je op alle VPN Gateways een loopback interface aanmaakt met het 1e extern bekende IP adres, kan je de tunnels termineren zonder NAT. Door op de Virtual server persistancy te configuren op basis van source IP adres (/32), gaat LB altijd goed.
Punt is dan nog wel hoe de routing informatie tussen de VPN Gateways wordt uitgewisseld. Hoe weet het netwerk welke tunnel op welk IP adres getermineerd is. Op alle Gateways staat het remote netwerk fixed geconfigureerd (anders kan geen uitgaande VPN geconfigureerd worden). Dan moet er vervolgens een dynamisch routing protocol overheen (OSPF) om te zorgen dat dat goede VPN Gateway vanuit het interne netwerk benaderd wordt voor verkeer riching een remote VPN subnet.

Ik heb meer ideeen, maar moet die nog scherper definieren. Ik zou graag een disucssie hierover starten om meer kennis op te bouwen en te delen en dan de startpost wat uit te breiden.

Mijn idee op dit moment is dat je die VPN connecties niet moet load balancen, maar gewoon een zwaardere VPN doos neetzetten. HW VPN schaalt tot 15 GBit, pas daarboven is load balancing echt noodzakelijk. Dan staat wel een van de VPN Gateways uit z'n neus te peuteren, maar dat is dan niet anders.

In ieder houd je de volgende uitdaging: Hoe kan je je eigen VPN endpoint goed bereikbaar maken via 2 ISP's zonder dat je de andere kant controleert (lees: moet multi-platform, multi company zijn), anders dan met BGP. Is daar ervaring mee?

P.S. Met een load balancer heeft vanuit ons bedrijf een voorkeur. Het is geen probleem als de beste oplossing zonder LB is, maar dan moet dat wel helemaal zeker en duidelijk zijn, zodat we dat ook aan klanten kunnen utleggen en bv aanbiedingen van concullega's kunnen 'afkraken'

[JackBol]

Waarom niet gewoon een ethernet vpn van KPN of een ethernet vpn van Versatel?
Bandbreedte tussen de 128kb/s en 1 Gb/s.

Dan krijg je er mooi een gemanagde CPE bij, performance en fault management en usage statistieken. Je kan kiezen tussen 99,98, 99,99 en 99,999%. Afhankelijk van je behoefte. KPN of Versatel verzorgt dan de redundancy helemaal voor je.

[ Voor 20% gewijzigd door JackBol op 01-12-2006 17:56 ]

[pablo_p]

_DH schreef op vrijdag 01 december 2006 @ 17:47:
Waarom niet gewoon een ethernet vpn van KPN of een ethernet vpn van Versatel?
Bandbreedte tussen de 128kb/s en 1 Gb/s.

Dit is een andere oplossing. Als je als groot bedrijf VPN koppelingen hebt naar 3e partijen via Internet, dan is dat een eenvoudig schaalbare oplossing die in principe makkelijk te implementeren is, ook voor de andere kant. Indien je naar alle 3e partijen waar je mee werkt (dat kunnen er zo 100 zijn) een koppeling maakt via Ethernet VPN, dan heb je te maken met de volgende punten (met tussen haakjes het voordeel van Internet IPSEC VPN):
- wie gaat de lijn betalen? (bij IPSEC is iedere partij verantwoordelijk voor zijn eigen kant)
- hoeveelheid providers. Gaat iedere 3e partij een KPN router binnen krijgen? dan moet je zelf ook Versatel/BT/BBNed/Verizon/etc accepteren onder het motto: behandel een ander zoals je zelf wil worden behandeld. Krijg je een berg losse routers van andere partijen erbij (bij IPSEC VPN een goede koppeling met Internet)
- wat is de oplevertijd en tijd benodigd voor upgrade per lijn (met IPSEC heb je dat in eigen hand, een dikke Internet pijp met QoS per VPN. QoS parameters zijn makkelijk zelf aan te passen in je VPN Gateway)
- wat zijn de kosten voor VPN's naar verre landen, zoals India en Brazilie (IPSEC VPN: afstand maakt niets uit)

Oftewel, er zijn goede redenen voor IPSEC VPN te gaan ipv Managed VPN/IP-VPN/MPLS. Die discussie wil ik niet voeren. Met bovenstaande argumenten wil ik duidelijk maken dat er veel te zeggen is voor een IPSEC VPN. Als door klanten strategisch gekozen is voor een IPSEC VPN oplossing voor koppelingen naar 3e partijen, dan is het onze uitdaging dat zo goed mogelijk in te richten.

Ik wil graag daarom dit on-topic houden, wat zijn de oplossingen voor IPSEC VPN redundantie over verschillende ISP en voor LB.

[JackBol]

Okay, zeg dat dan. Dat maar ik nl. uit je TS niet op. Daar geef je aan dat je een VPN tussen 2 locaties wilt met hoge betrouwbaarheid...

[pablo_p]

_DH schreef op zaterdag 02 december 2006 @ 01:58:
Okay, zeg dat dan. Dat maar ik nl. uit je TS niet op. Daar geef je aan dat je een VPN tussen 2 locaties wilt met hoge betrouwbaarheid...

Excuses. Is aan gepast. Stond inderdaad alleen in de titel zelf en in de laatste regels, niet heel duidelijk.

[Bl@ckbird]

pablo_p schreef op vrijdag 01 december 2006 @ 16:00:

[...]

IPSEC heeft moeite met NAT. NAT-T hoort hier een oplossing voor te zijn, maar werkt niet cross-platform. Na problemen met een IPSEC tunnel met dubbele NAT tussen een Juniper ScreenOS en Cisco ASA, was het officiele antwoord van Juniper op een case hierover: "Juniper ondersteund geen NAT-T met andere partijen. Het wordt 'finger-pointing' en werking wordt niet gegarandeerd."

Site-to-site IPSec VPN met verschillende fabrikanten is leuk, maar bij problemen zullen ze elkaar de schuld proberen toe te schuiven, of gewoon geen ondersteuning willen bieden. Bij een site-to-site VPN tussen een Juniper en een Cisco doos, zal Cisco hetzelfde reageren als Juniper: "Geen ondersteuning."

Waar je naar kan kijken is Dynamic Multipoint VPN. ( DMVPN )
Je kunt hiermee dynamisch tunnels opzetten tussen verschillende vestigingen.
Het grootste probleem is dat het een "Cisco only" feature is.
- Het gebruikt EIGRP voor de routering van verkeer door de tunnels.
- Alleen beschikbaar voor routers. (En dan met name de ISR reeks: 870, 1800, 2800, 3800, of hoger.)
- Omdat je DMVPN op routers kunt gebruiken, heb je de beschikking over de rijke QoS featureset.
( Waar deze routers over beschikken.)

Kijk voor een voorbeeld naar deze presentatie / PDF:
http://www.cisco.com/appl...cont_0900aecd80313ca6.pdf
( Dual DMVPN Dual Hub (DD-DH), op Pagina 18 )

Voor de hoofdlokatie kun je twee zware routers neerzetten, die elk een ISP uplink bedienen.
(Evt. voorzien van extra VPN acceleratie hardware.)

Het is een aardige MKB oplossing voor low latency VoIP omgevingen.
Het schijnt aardig schaalbaar te zijn, maar ik durf daar geen harde uitspraken over te doen.

DMVPN Overview:
http://www.cisco.com/en/U...protocol_option_home.html

VPN performance op Cisco routers:
http://www.cisco.com/en/U...etbr09186a00801f0a72.html

[joopv]

Ik weet dat Verizon managed redundante internet verbindingen kan leveren. Je krijgt dan 2 cisco 2800 dozen die via hsrp een redundante internet pijp aanbiedt aan wat je er dan ook achter zet, b.v. een vpn concentrator of een asa. Die kan dan op zich ook weer redundant zijn uitgevoerd.

Die hsrp oplossing op 2 verschillende locaties is dan weer lastig.

[pablo_p]

Ik denk dat dual ISP VPN zonder de remote kant te beheren, niet mogelijk is. Dan heeft het ook geen zin daar specifiek tijd in te steken. Dan maar dual ISP VPN met beheer van remote kant (je moet toch wat hebben om over na te denken, toch?)

Bl@ckbird schreef op zaterdag 02 december 2006 @ 02:20:
...
Waar je naar kan kijken is Dynamic Multipoint VPN. ( DMVPN )
...

De DMVPN oplossing vind ik wel duidelijk de interessantste. Het basis principe is transparante VPN tunnels met een dynamisch routing protocol er overheen. Wel beide eindpunten onder beheer.

Ik snap hier toch Cisco's strategie ten aanzien van VPN/firewalling niet helemaal... Waarom kan een ASA niet meedraaien in een DMVPN oplossing. PixOS is standaard beter gehardend en beter te beheren door een andere manier van omgaan met ACL's

Helaas voert het bedrijf waar ik werk eigenlijk geen Cisco. Juniper heeft met firewalls toch dual ISP VPN load balancing mogelijkheden, maar dan moeten er meerdere VRF's mogelijk zijn, mogelijk in verschillende zone's. Ik ben helaas niet genoeg thuis in Juniper.

Ik had een vermoeden in welke richting ik moest zoeken, nav de DMVPN weet ik zeker in welke richting ik ga kijken. Bedankt!

joopv schreef op zaterdag 02 december 2006 @ 17:51:
Ik weet dat Verizon managed redundante internet verbindingen kan leveren. Je krijgt dan 2 cisco 2800 dozen die via hsrp een redundante internet pijp aanbiedt aan wat je er dan ook achter zet, b.v. een vpn concentrator of een asa. Die kan dan op zich ook weer redundant zijn uitgevoerd.

Die hsrp oplossing op 2 verschillende locaties is dan weer lastig.

HSRP op twee lokaties is steeds minder spannend. Ik ken een aantal klanten die 1G of 10G koppelingen hebben tussen redundante DC. Een extra VLAN'netje is zo erbij geplaatst.

P.S. Single provider redundante oplossing is een filosofie. Je houdt dan dat je een SPOF hebt bij die provider. Als die provider een verkeerde configuratie push doet, hang je... Ikzelf vind dat wel een acceptabel risico, maar niet alle klanten. Het is een filosofie....
Het is oa de taak van mijn bedrijf om de filosofie van de klant te ondersteunen, alsmede kritisch te bekijken. Maar uiteindelijk bepaalt de klant wat hij wil.

[ Voor 6% gewijzigd door pablo_p op 10-12-2006 22:16 ]

[Bl@ckbird]

pablo_p schreef op zondag 10 december 2006 @ 22:12:

[...]

Ik snap hier toch Cisco's strategie ten aanzien van VPN/firewalling niet helemaal... Waarom kan een ASA niet meedraaien in een DMVPN oplossing. PixOS is standaard beter gehardend en beter te beheren door een andere manier van omgaan met ACL's

DMVPN is een feature wat ik ook graag in de ASA had gezien.

Cisco is bezig om zoveel mogelijk losse security doosjes uit de markt te halen.
Dan heb ik het over de VPN Concentrator, PIX en de 4200 IDS / IPS.
Dit wordt allemaal vervangen door de ASA5500. (Met eventuele extra modules.)

Aan de andere kan worden de nieuwere routers voorzien van security.
( IOS Firewall / IPS / VPN evt. met extra hardware acceleratie.)

Er zijn dus twee security lijnen: De ASA en de ( ISR ) Routers.

Cisco doet ook in VoIP. CallManager handeld dan de call processing af en de router doet dienst als Voice Gateway. ( Het omzetten van VoIP / IP verkeer, naar PSTN / ISDN BRI-PRI )

Bij VoIP wil je zo min mogelijk latency hebben. Hier komt DMVPN bij kijken.
Het VoIP verkeer wordt initieel eerst naar de hoofdlokatie gerouteerd. (Waar de callprocessing plaats vindt.) Is het een gesprek tussen twee bijlokaties, dan wordt het VoIP verkeer over de DMVPN gerouteerd, die beide bijlokaties verbindt.

Je belt dus direct tussen de bijlokaties, zonder dat dit via de hoofdlokatie loopt.
( Behalve dan de lookup in het telefoon/adresboek.)
Vandaar ook mijn eerdere opmerking over de rijke QoS featureset, die je op routers aantreft.

Edit / Disclaimer:
_{Beroepshalve hou ik me vooral met Cisco bezig, dus als je denkt dan het anders kan, dan moet je dat vooral doen.}

[ Voor 4% gewijzigd door Bl@ckbird op 10-12-2006 23:55 ]