IPSEC Routing bij dubbele route

[DennusB]

Hoi Tweakers,

Ik loop tegen een wat ingewikkeld probleem aan en probeer dat op te lossen, maar ik kom er niet uit. Dus ik hoop dat jullie handige tips hebben!

Situatie is als volgt :

2 netwerken, 1 in Azure & 1 in AWS, gekoppeld met een DirectConnect voor intern verkeer. Ze kunnen dus beide intern verkeer routeren over de DirectConnect.
Om wat grote bakken data heen en weer te schuiven tussen de clouds willen we de DirectConnect niet gebruiken omdat we die gebruiken voor cruciale backend communicatie, en als we de DirectConnect klem trekken met die datastromen dat wel eens problemen kan geven.
Dus idee was om er een IPSEC tunnel (over internet) naast te leggen.

Daar ben ik nu : De tunnel is er. Maar de routing is dus echt een enorme uitdaging. De routes zijn aangemaakt, maar toch prefereren beide machines het verkeer via de default gateway te laten lopen, terwijl het juist de IPSEC tunnel ingeschopt moet worden.
Ik heb dus al wat lopen stoeien met ip xfrm policies, maar ook daar kom ik niet echt verder; Als in : Het verkeer gaat dan niet meer via de DirectConnect, maar ik zie het ook niet aan de andere kant van de IPSEC tunnel langskomen.

code:

ip xfrm policy add dir out src <ip VPN node AWS> dst <ip VPN node Azure> ptype main action allow priority 2080 tmpl src <ip VPN node AWS> dst <ip VPN node Azure>proto esp reqid 16386 mode transport

Als ik die regel er in zet loopt het verkeer niet meer via z'n default gateway, maar het komt ook niet aan door de IPSEC tunnel.

Ik ben gewend dat je aan beide kanten 2 los te routeren subnetten hebt, en dat is een stuk makkelijker haha. Iemand tips hoe dit aan elkaar te knopen?

Alvast enorm bedankt!

[Sandor_Clegane]

DennusB schreef op donderdag 18 oktober 2018 @ 11:05:
Hoi Tweakers,

Ik loop tegen een wat ingewikkeld probleem aan en probeer dat op te lossen, maar ik kom er niet uit. Dus ik hoop dat jullie handige tips hebben!

Situatie is als volgt :

2 netwerken, 1 in Azure & 1 in AWS, gekoppeld met een DirectConnect voor intern verkeer. Ze kunnen dus beide intern verkeer routeren over de DirectConnect.
Om wat grote bakken data heen en weer te schuiven tussen de clouds willen we de DirectConnect niet gebruiken omdat we die gebruiken voor cruciale backend communicatie, en als we de DirectConnect klem trekken met die datastromen dat wel eens problemen kan geven.
Dus idee was om er een IPSEC tunnel (over internet) naast te leggen.

Daar ben ik nu : De tunnel is er. Maar de routing is dus echt een enorme uitdaging. De routes zijn aangemaakt, maar toch prefereren beide machines het verkeer via de default gateway te laten lopen, terwijl het juist de IPSEC tunnel ingeschopt moet worden.
Ik heb dus al wat lopen stoeien met ip xfrm policies, maar ook daar kom ik niet echt verder; Als in : Het verkeer gaat dan niet meer via de DirectConnect, maar ik zie het ook niet aan de andere kant van de IPSEC tunnel langskomen.

code:

ip xfrm policy add dir out src <ip VPN node AWS> dst <ip VPN node Azure> ptype main action allow priority 2080 tmpl src <ip VPN node AWS> dst <ip VPN node Azure>proto esp reqid 16386 mode transport

Als ik die regel er in zet loopt het verkeer niet meer via z'n default gateway, maar het komt ook niet aan door de IPSEC tunnel.

Ik ben gewend dat je aan beide kanten 2 los te routeren subnetten hebt, en dat is een stuk makkelijker haha. Iemand tips hoe dit aan elkaar te knopen?

Alvast enorm bedankt!

Als ik het goed begrijp dan gaat die tweede ipsec tunnel toch over dezelfde infra? Ik bedoel het zal toch ergens het internet op moeten, of gaat dit echt via een fysiek gescheiden switch/internet pijp?

Als dat niet het geval is, wat win je er dan mee?

Een optie zou kunnen zijn om de hosts die je via IPsec wilt laten praten een extra ip adres te geven, uit een andere range en zodat je een kenmerk hebt om aan te geven dat je dat verkeer over de tunnel wilt hebben.

Beetje meer info.