Cisco ASA IPSec ruch nie przechodzi na druga strone.

Problemy z zakresu security (VPN, firewall, IDS/IPS itp.)

Moderatorzy: mikrobi, garfield, gangrena, Seba, aron, PatrykW

Wiadomość
Autor
Awatar użytkownika
qligowski
wannabe
wannabe
Posty: 251
Rejestracja: 16 maja 2014, 18:35

Cisco ASA IPSec ruch nie przechodzi na druga strone.

#1

#1 Post autor: qligowski »

Hej,

Klient ma Cisco ASA z dwoma ISP, dwie trasy domyslne z roznym AD. Potrzebowalem zapiac tunel Ipsec przez ISP2 (AD 7). Dodalem trase statyczna do swojego peera przez interface ISP2, skonfigurowalem wszystko i VPN wstaje od razu, widze ruch wchodzi w tunnel, pakiety enkapsulacji rosna i logi pokazuja TX. Problem w tym ze zaden z tych pakietow nie dochodzi na druga strone. Nie ma NAt-T ani nic z tych rzeczy, po prostu zwykly IPSec ikev1 w trybie tunnel. Skonfigurowalem drugi tunnel do swojego servera Strongswan i rzecz jest identyczna, jak puszczam pingi ze strony ASA, wchodza one w tunel, lecz tcpdump po drugiej stronie nic nie pokazuje. Mial ktos podobny problem? NAT itp wszystko skonifugrowane OK, packet tracer tez pokazuje ze wszystko jest allowed.

Awatar użytkownika
konradrz
CCIE
CCIE
Posty: 380
Rejestracja: 23 sty 2008, 14:21
Lokalizacja: Singapore, SG
Kontakt:

Re: Cisco ASA IPSec ruch nie przechodzi na druga strone.

#2

#2 Post autor: konradrz »

Zgaduję: asymetria? W sensie, wysyłasz via ISP2, ale pakiety wracają via ISP1 (bo ISP2 myśli że to najlepsza ścieżka do Twojej ASA)?
Spróbuj zestawić tego Swana przez interfejs ASA-do-ISP1, wtedy działa?

Awatar użytkownika
qligowski
wannabe
wannabe
Posty: 251
Rejestracja: 16 maja 2014, 18:35

Re: Cisco ASA IPSec ruch nie przechodzi na druga strone.

#3

#3 Post autor: qligowski »

Dzieki za opdowiedz, no wlasnie nie. Wszystko idzie via ISP2 i wraca via ISP2 do peera.

Awatar użytkownika
qligowski
wannabe
wannabe
Posty: 251
Rejestracja: 16 maja 2014, 18:35

Re: Cisco ASA IPSec ruch nie przechodzi na druga strone.

#4

#4 Post autor: qligowski »

Temat mozna zamknac. Problemem okazal sie Cisco Meraki po stronie ISP2 ktory nie przepuszczal wychodzacych pakietow ESP (ip protcol 50) :D

ODPOWIEDZ