Toon posts:

IPSEC Routing bij dubbele route

Pagina: 1
Acties:
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:
1
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
  • Registratie: Januari 2012
  • Niet online

Sandor_Clegane

Fancy plans and pants to match

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:
1
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. :)

Less alienation, more cooperation.



Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee