Intermitentní problémy s VPN vzdáleného přístupu a duální WAN

VPN
1

Ahoj, mám ISR4000 nakonfigurované s IKEv1 přes dynamickou kryptomapu pro VPN vzdáleného přístupu. Fungovalo to dobře, dokud jsem neaktivoval druhou WAN linku. Obě cesty mají výchozí směrování, stejné metriky. Všichni klienti jsou nastaveni tak, aby ukazovali na stejnou (jedinou) WAN rozhraní (nastavené s kryptomapou).

Vyvažování zátěže, PAT apod. fungují dobře, až na to, že VPN nyní občas selhává. Klienti jsou všichni Macové používající nativního klienta OS.

V protokolech ISAKMP vidím toto:

6. října 17:08:13.779: ISAKMP-PAK: (1120): přijatý paket od X.X.X.X na dport 500 sport 54881 Globální (R) AG_INIT_EXCH
6. října 17:08:13.779: ISAKMP: (1120): Phase 1 paket je duplicitou předchozího paketu.
6. října 17:08:13.779: ISAKMP: (1120): opětovné odeslání kvůli opětovnému přenosu fáze 1
6. října 17:08:14.280: ISAKMP: (1120): opětovné odeslání fáze 1 AG_INIT_EXCH...

To se opakuje několikrát, až do:

6. října 17:08:50.562: ISAKMP-ERROR: (1120): mazání SA kvůli příčině "Death by retransmission P1" stav (R) AG_INIT_EXCH (peer X.X.X.X)
6. října 17:08:50.562: ISAKMP-ERROR: (1120): mazání SA kvůli příčině "Death by retransmission P1" stav (R) AG_INIT_EXCH (peer X.X.X.X)

Jak jsem řekl, toto je občasné, a často se mi podaří spojení navázat změnou internetového připojení (a zdrojové IP) pro mého klienta. Zajímalo by mě, jestli nějakým způsobem vyvažování zátěže neposílá některé pakety ISAKMP nesprávným (ne kryptomapu) rozhraním? Ačkoliv pokud ISAKMP dialog používá stejnou IP/port, nevím proč by to tak být mělo, protože algoritmus vyvážení by měl dávat všechny pakety na stejné rozhraní.

Máte nějaké návrhy?

2

Myslím, že máte pravdu, že za to může vyvažování zátěže. IKE používá UDP, takže je pravděpodobné, že je rozděleno přes obě rozhraní, protože je bezestavové (pokud není konkrétně specifikováno, že IKE používá jedno rozhraní).

Zkuste přidat statickou trasu k jednomu z hostitelů dočasně, abyste zjistili, jestli to problém vyřeší.

3

Vyvažování zátěže používá výchozí algoritmus. Rychle jsem zkoušel PBR, ale nezdálo se, že by pomohlo – shodovalo se na ISAKMP a ESP.

4

Statická trasa mi umožnila připojit se z jinak nefungujícího zdrojového IP. Je zřejmé, že to není možné dělat u všech klientů s neznámým zdrojovým IP.

Existuje nějaký jiný způsob, jak nasměrovat veškerý VPN provoz na jedno rozhraní?

5

Nejvhodnějším řešením je pravděpodobně použití konfigurace ve stylu FlexVPN, aby měl váš router správné logické rozhraní pro každý vzdálený přístupový tunel. Pak není otázkou vyvažování zátěže, protože zdrojové rozhraní tunelu může být explicitně definováno. Jaký klient IPSec používají vaše koncové hosty? Podporuje IKEv2, a nebylo by rozumné migrovat na klienta IKEv2?

Uprava: Řekl jste, že používají nativního klienta OS. Podporuje IKEv2. Takže pokud je rozumné migrovat na IKEv2, rozhodně to doporučuji.

6

Jak vyvažujete provoz? Můžete shodovat na UDP:500 nebo IKE? To by byl začátek, než přistoupíte k přepracování VPN nastavení.

7

Ano, s IKEv2 a DVTI jsem se o to pokoušel dříve, ale nešlo mi to. Strávil jsem u toho dny bez úspěchu. Myslíte, že je to jediným řešením? Pokud ano, máte nějaké dobré odkazy na dokumentaci? Nemohu použít AnyConnect nebo certifikáty (nejsem můj první). Musím si představit, že to již někdo dělal.

8

Nemohu říct, že jsem to zkoušel s něčím jiným než s AnyConnect, takže nemohu dát žádné záruky. Ale tento průvodce je místem, od kterého bych začal. Bude ho třeba trochu upravit podle vašich potřeb. Nejsem si jistý, co by OSX klient od IOS headend očekával, takže nemohu poradit víc.

Další možností by bylo použít PBR. To je asi nejjednodušší – i když obecně je PBR spíš krajní řešení. Zde je rychlý průvodce lokálním směrováním přes politiku, který byste mohl upravit tak, aby odpovídal IKE (UDP port 500) a ESP (IP protokol 50) místo telnetu, jak je v jejich příkladu.