[ASA 5506/Strongswan] Na een tijd geen verkeer over s2s vpn

[Hero of Time]

Mijn vraag/probleemomschrijving:
Op kantoor hebben we drie site-to-site VPN verbindingen naar verschillende endpoints. Eentje is een ipsec/IKEv1 verbinding met een Sophos UTM. Dat blijft zonder problemen draaien. De andere twee zijn ipsec/IKEv2 naar Ubuntu 16.04 met Strongswan 5.3.5. Deze hadden eerst het probleem dat elk uur de verbinding opnieuw werd opgezet, wat erg vervelend is als je met SSH verbinding maakt. Die valt dan ook uit. Dat heb ik met wat aanpassen van de configuratie (matchen van key lifetimes) opgelost zodat de phase 2 rekey correct werkt en geen uitval van de hele verbinding veroorzaakt.

Echter is nu het probleem dat zodra de tunnel 24 uur actief is, deze alsnog helemaal opnieuw wordt opgebouwd. Het ziet er dus naar uit dat de rekey van phase 1 niet goed gaat. Dit zou an sich niet zo'n probleem zijn, al zou ik wel graag een tunnel willen die langer dan 1 dag up blijft. Maar na een paar dagen is het opeens niet meer mogelijk om verkeer door de tunnel te sturen. Dit gebeurt wanneer de tunnel opnieuw wordt opgezet, maar niet altijd als de 24 uur van de phase 1 key lifetime is bereikt. Ik heb het ook enkele uren erna zien gebeuren (bijvoorbeeld om 8:00 wordt de tunnel volledig opnieuw opgezet en om 11:00 dezelfde ochtend nogmaals, maar dan zonder verkeer mogelijk).
Het maakt dan niet uit of ik de tunnel handmatig opnieuw opzet door Strongswan te herstarten. De verbinding is er, het ziet er goed uit, maar er komt gewoon geen verkeer doorheen. Om het weer te laten werken, moet de hele Cisco ASA herstart worden. Dat is natuurlijk verre van ideaal, want het hele bedrijf ligt dan plat totdat deze weer online is.


Relevante software en hardware die ik gebruik:
Cisco ASA 5506 met software versie 9.6(1)
Ubuntu 16.04 met Strongswan 5.3.5. Ik heb ook 5.5.1 via een PPA geprobeerd, maar maakt geen verschil.


Wat ik al gevonden of geprobeerd heb:
Een goed beheerder zoekt natuurlijk eerst zelf. Ik had dus al wat gevonden om de tunnel langer online te houden en dat heeft ook een tijd gewerkt. Tot recentelijk dus.

In eerste instantie ben ik gaan testen met Packet-tracer om te kijken of er verkeer naar de andere kant komt. Eerst had ik het resultaat dat bij fase 8 of 9, wanneer het de tunnel in moet met type VPN, subtype ENCRYPT, het verkeer gedropt werd. De laatste regel in de access-lists werd geraakt. Dat was al heel vreemd, aangezien hetzelfde via de andere tunnel die nog wel verkeer door liet een ander resultaat gaf.
Nu is het zo dat alles groen is en verkeer lijkt door de VPN te gaan. Maar een ping, SSH of wat dan ook komt gewoon niet aan. En ik kan niet achterhalen waar het heen gaat.

Google zoeken op o.a. 'cisco asa ipsec tunnel up but no traffic' en 'cisco asa drops traffic vpn' geven veel resultaten, maar geen van de resultaten geven een oplossing die bij ons hier van toepassing is. Bijvoorbeeld https://community.cisco.c...p-no-traffic/td-p/2299125 heeft het over dubbele en overbodige regels in de access-list. Die hebben we niet, dus daar ligt het helaas niet aan.

Een ander resultaat brengt mij bij https://networkengineerin...p-but-not-passing-traffic. Het antwoord dat wordt gegeven klinkt erg logisch en ik zie bij de uitvoer van het commando ook meerdere in en out regels. Echter zie ik er hoe dan ook meer dan 1, ongeacht of er verkeer mogelijk is of niet. Dat lijkt dus ook niet de boosdoener te zijn.


Om nog volledig te zijn, de configuratie voor de VPN voor zover ik die kan geven (gevoelige zaken weggehaald natuurlijk).
Strongswan config

code:

config setup
  charondebug="all"
  uniqueids=yes
  strictcrlpolicy=no

conn kantoor
  authby=secret
  left=%defaultroute
  leftid=<extern ip>
  leftsubnet=<interne subnet>
  right=<kantoor ip>
  rightid=<kantoor ip>
  rightsubnet=<kantoor subnet>
  ike=aes256-sha-modp1536
  esp=aes256-sha2_256!
  keyexchange=ikev2
  keyingtries=%forever
  ikelifetime=24h
  # Option below is equivalent to salifetime and keylife
  lifetime=1h
  dpddelay=30
  dpdtimeout=120
  dpdaction=restart
  auto=start

Cisco ASA

Crypto Maps

• IKEv2 IPsec Proposal: AES256_SHA256
• Enable NAT-T
• SA Lifetime: 1h
• Traffic Selection: Action: Protect; Source Criteria: <kantoor subnet>, Destination Criteria: <server intern subnet>

IKEv2 Policies

• Encryption: aes-256
• Integrity Hash: sha256, sha
• PRF Hash: sha256, sha
• Dh-H Group: 2; 5
• Lifetime (seconds): 86400 (1 dag)

Er zijn meer policies gedefinieerd, allemaal standaard eigenlijk met lagere encryptiegrootte, zoals 192-sha, 3des, etc. Beetje onzinnig dat ook op te schrijven.

Connection Profile
IKE v2 Settings

• Authentication: PSK
• Encryption Algoritms:
  • IKE Policy: aes-256-sha256&sha-sha256&sha, aes-192-sha-sha, aes-sha-sha, 3des-sha-sha, des-sha-sha
  • IPsec Proposal: AES256_SHA256
• NAT Exempt: Exempt ASA side host/network from address translation: <interne range>

NAT Rules

• Match Criteria: Original Packet
  • Source intf: <kantoor intern interfaces groep>
  • Dest Intf: <WAN interface>
  • Source: <kantoor subnet>
  • Destination: <server interne subnet>
  • Service: any
• Action: Translated Packet
  • Source, Destination, Service: -- Original --
• Options: No Proxy ARP, Route Lookup

En nog een paar meer rules, maar het gaat er even om dat we wel NAT rules hebben voor het andere subnet.

Dit is wat ik in het log van Strongswan zie zodra het phase 1 rekey uitvoert. Wat mij opvalt is dat de Cisco geen antwoord lijkt te geven, getuige de 'retransmit' meldingen. Ik zie die alleen als er geen verkeer over de tunnel kan.

code:

charon: 08[KNL] creating rekey job for CHILD_SA ESP/0xe730ea05/<kantoor ip>
charon: 08[IKE] establishing CHILD_SA <kantoor vpn>{5}
charon: 08[IKE] establishing CHILD_SA <kantoor vpn>{5}
charon: 08[ENC] generating CREATE_CHILD_SA request 62 [ N(REKEY_SA) SA No TSi TSr ]
charon: 08[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (204 bytes)
charon: 10[NET] received packet: from <kantoor ip>[4500] to <server ip>[4500] (236 bytes)
charon: 10[ENC] parsed CREATE_CHILD_SA response 62 [ SA No TSi TSr ]
charon: 10[IKE] CHILD_SA <kantoor vpn>{129} established with SPIs cb99af21_i 242cb60e_o and TS <server interne subnet> === <kantoor subnet>
charon: 10[IKE] CHILD_SA <kantoor vpn>{129} established with SPIs cb99af21_i 242cb60e_o and TS <server interne subnet> === <kantoor subnet>
charon: 10[IKE] closing CHILD_SA <kantoor vpn>{128} with SPIs c2cdaa5d_i (1238316 bytes) e730ea05_o (1450903 bytes) and TS <server interne subnet> === <kantoor subnet>
charon: 10[IKE] closing CHILD_SA <kantoor vpn>{128} with SPIs c2cdaa5d_i (1238316 bytes) e730ea05_o (1450903 bytes) and TS <server interne subnet> === <kantoor subnet>
charon: 10[IKE] sending DELETE for ESP CHILD_SA with SPI c2cdaa5d
charon: 10[ENC] generating INFORMATIONAL request 63 [ D ]
charon: 10[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (76 bytes)
charon: 09[NET] received packet: from <kantoor ip>[4500] to <server ip>[4500] (76 bytes)
charon: 09[ENC] parsed INFORMATIONAL request 0 [ D ]
charon: 09[IKE] received DELETE for ESP CHILD_SA with SPI e730ea05
charon: 09[IKE] CHILD_SA closed
charon: 09[ENC] generating INFORMATIONAL response 0 [ ]
charon: 09[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (76 bytes)
charon: 14[IKE] retransmit 1 of request with message ID 63
charon: 14[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (76 bytes)
charon: 04[IKE] retransmit 2 of request with message ID 63
charon: 04[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (76 bytes)
charon: 13[NET] received packet: from <kantoor ip>[4500] to <server ip>[4500] (76 bytes)
charon: 13[ENC] parsed INFORMATIONAL request 1 [ ]
charon: 13[ENC] generating INFORMATIONAL response 1 [ ]
charon: 13[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (76 bytes)
charon: 05[IKE] retransmit 3 of request with message ID 63
charon: 05[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (76 bytes)
charon: 15[NET] received packet: from <kantoor ip>[4500] to <server ip>[4500] (76 bytes)
charon: 15[ENC] parsed INFORMATIONAL request 2 [ ]
charon: 15[ENC] generating INFORMATIONAL response 2 [ ]
charon: 15[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (76 bytes)
charon: 07[NET] received packet: from <kantoor ip>[4500] to <server ip>[4500] (76 bytes)
charon: 07[ENC] parsed INFORMATIONAL request 3 [ ]
charon: 07[ENC] generating INFORMATIONAL response 3 [ ]
charon: 07[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (76 bytes)
charon: 11[NET] received packet: from <kantoor ip>[4500] to <server ip>[4500] (76 bytes)
charon: 11[ENC] parsed INFORMATIONAL request 4 [ ]
charon: 11[ENC] generating INFORMATIONAL response 4 [ ]
charon: 11[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (76 bytes)
charon: 10[IKE] retransmit 4 of request with message ID 63
charon: 10[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (76 bytes)
charon: 09[NET] received packet: from <kantoor ip>[4500] to <server ip>[4500] (76 bytes)
charon: 09[ENC] parsed INFORMATIONAL request 5 [ ]
charon: 09[ENC] generating INFORMATIONAL response 5 [ ]
charon: 09[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (76 bytes)
charon: 12[NET] received packet: from <kantoor ip>[4500] to <server ip>[4500] (76 bytes)
charon: 12[ENC] parsed INFORMATIONAL request 6 [ ]
charon: 12[ENC] generating INFORMATIONAL response 6 [ ]
charon: 12[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (76 bytes)
charon: 06[NET] received packet: from <kantoor ip>[4500] to <server ip>[4500] (76 bytes)
charon: 06[ENC] parsed INFORMATIONAL request 7 [ ]
charon: 06[ENC] generating INFORMATIONAL response 7 [ ]
charon: 06[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (76 bytes)
charon: 04[NET] received packet: from <kantoor ip>[4500] to <server ip>[4500] (76 bytes)
charon: 04[ENC] parsed INFORMATIONAL request 8 [ ]
charon: 04[ENC] generating INFORMATIONAL response 8 [ ]
charon: 04[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (76 bytes)
charon: 13[IKE] retransmit 5 of request with message ID 63
charon: 13[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (76 bytes)
charon: 05[NET] received packet: from <kantoor ip>[4500] to <server ip>[4500] (76 bytes)
charon: 05[ENC] parsed INFORMATIONAL request 9 [ ]
charon: 05[ENC] generating INFORMATIONAL response 9 [ ]
charon: 05[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (76 bytes)
charon: 07[NET] received packet: from <kantoor ip>[4500] to <server ip>[4500] (76 bytes)
charon: 07[ENC] parsed INFORMATIONAL request 10 [ ]
charon: 07[ENC] generating INFORMATIONAL response 10 [ ]
charon: 07[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (76 bytes)
charon: 08[NET] received packet: from <kantoor ip>[4500] to <server ip>[4500] (76 bytes)
charon: 08[ENC] parsed INFORMATIONAL request 11 [ ]
charon: 08[ENC] generating INFORMATIONAL response 11 [ ]
charon: 08[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (76 bytes)
charon: 11[NET] received packet: from <kantoor ip>[4500] to <server ip>[4500] (76 bytes)
charon: 11[ENC] parsed INFORMATIONAL request 12 [ ]
charon: 11[ENC] generating INFORMATIONAL response 12 [ ]
charon: 11[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (76 bytes)
charon: 09[NET] received packet: from <kantoor ip>[4500] to <server ip>[4500] (76 bytes)
charon: 09[ENC] parsed INFORMATIONAL request 13 [ ]
charon: 09[ENC] generating INFORMATIONAL response 13 [ ]
charon: 09[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (76 bytes)
charon: 12[NET] received packet: from <kantoor ip>[4500] to <server ip>[4500] (76 bytes)
charon: 12[ENC] parsed INFORMATIONAL request 14 [ ]
charon: 12[ENC] generating INFORMATIONAL response 14 [ ]
charon: 12[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (76 bytes)
charon: 14[NET] received packet: from <kantoor ip>[4500] to <server ip>[4500] (76 bytes)
charon: 14[ENC] parsed INFORMATIONAL request 15 [ ]
charon: 14[ENC] generating INFORMATIONAL response 15 [ ]
charon: 14[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (76 bytes)
charon: 04[IKE] giving up after 5 retransmits
charon: 04[IKE] restarting CHILD_SA <kantoor vpn>
charon: 04[IKE] initiating IKE_SA <kantoor vpn>[6] to <kantoor ip>
charon: 04[IKE] initiating IKE_SA <kantoor vpn>[6] to <kantoor ip>
charon: 04[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) ]
charon: 04[NET] sending packet: from <server ip>[500] to <kantoor ip>[500] (596 bytes)
charon: 04[IKE] restarting CHILD_SA <kantoor vpn>
charon: 05[NET] received packet: from <kantoor ip>[500] to <server ip>[500] (567 bytes)
charon: 05[ENC] parsed IKE_SA_INIT response 0 [ SA KE No V V N(NATD_S_IP) N(NATD_D_IP) CERTREQ ]
charon: 05[IKE] received Cisco Delete Reason vendor ID
charon: 05[IKE] received Cisco Copyright (c) 2009 vendor ID
charon: 05[IKE] received 4 cert requests for an unknown ca
charon: 05[IKE] authentication of '<server ip>' (myself) with pre-shared key
charon: 05[IKE] establishing CHILD_SA <kantoor vpn>{5}
charon: 05[IKE] establishing CHILD_SA <kantoor vpn>{5}
charon: 05[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(EAP_ONLY) ]
charon: 05[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (252 bytes)
charon: 15[NET] received packet: from <kantoor ip>[4500] to <server ip>[4500] (236 bytes)
charon: 15[ENC] parsed IKE_AUTH response 1 [ V IDr AUTH SA TSi TSr N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) ]
charon: 15[IKE] authentication of '<kantoor ip>' with pre-shared key successful
charon: 15[IKE] IKE_SA <kantoor vpn>[6] established between <server ip>[<server ip>]...<kantoor ip>[<kantoor ip>]
charon: 15[IKE] IKE_SA <kantoor vpn>[6] established between <server ip>[<server ip>]...<kantoor ip>[<kantoor ip>]
charon: 15[IKE] scheduling reauthentication in 85569s
charon: 15[IKE] maximum IKE_SA lifetime 86109s
charon: 15[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
charon: 15[IKE] CHILD_SA <kantoor vpn>{130} established with SPIs cfc0afa9_i 8d188c56_o and TS <server interne subnet> === <kantoor subnet>
charon: 15[IKE] CHILD_SA <kantoor vpn>{130} established with SPIs cfc0afa9_i 8d188c56_o and TS <server interne subnet> === <kantoor subnet>
charon: 15[IKE] establishing CHILD_SA <kantoor vpn>{5}
charon: 15[IKE] establishing CHILD_SA <kantoor vpn>{5}
charon: 15[ENC] generating CREATE_CHILD_SA request 2 [ SA No TSi TSr ]
charon: 15[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (204 bytes)
charon: 08[NET] received packet: from <kantoor ip>[4500] to <server ip>[4500] (76 bytes)
charon: 08[ENC] parsed INFORMATIONAL request 0 [ ]
charon: 08[ENC] generating INFORMATIONAL response 0 [ ]
charon: 08[NET] sending packet: from <server ip>[4500] to <kantoor ip>[4500] (76 bytes)
charon: 09[IKE] retransmit 1 of request with message ID 2

Ik denk dat ik hiermee alles heb. Mocht ik iets missen, zeg 't dan vul ik 't aan.

Edit:
Logging van Strongswan vanaf uitval toegevoegd.

[ Voor 63% gewijzigd door Hero of Time op 07-02-2019 13:13 ]

[kosz]

Ik zie nergens dat je gebruik maakt van keep alive of dead peer detection (DPD)
Mijn voorkeur gaat uit om DPD te gebruiken als de andere zijde dat ook ondersteund.
Heel basaal : keep alive kijkt of de andere kant van de tunnel nog op is, en DPD kijkt of er nog verkeer door de tunnel gaat.

[Hero of Time]

Dat gebruiken we wel. De config van Strongswan laat dat ook zien:

code:

  dpddelay=30
  dpdtimeout=120
  dpdaction=restart

Aan de Cisco kant is 't ook, IKE Keepalive: Monitor keepalives. Confidence interval: 10 seconds, retry interval: 2 seconds.

Dat is het dus helaas ook niet. En het verklaart ook niet dat het uitvalt op het moment dat phase 1 een rekey krijgt (meestal iig). Als het dead peer zou zijn, zou de tunnel niet up komen of blijven en dat doet het dus wel.

[Thralas]

Hero of Time schreef op woensdag 6 februari 2019 @ 15:39:
Ik denk dat ik hiermee alles heb. Mocht ik iets missen, zeg 't dan vul ik 't aan.

De logs van de ASA?

Overigens zie ik aan het begin van je Strongswan-log een ESP SA rekey, geen 'phase1' rekey (neem aan dat je daarmee IKE SA rekey bedoelt, phases zijn iets van IKEv1).

De daaropvolgende delete van de (oude) ESP SA aan de zijde van Strongswan lijkt niet te worden geackt. Logs van de ASA lijken me daartoe bijzonder relevant.

Neem aan dat je op zo'n ASA ook de IPsec/IKE state wel kunt dumpen. Lijkt me ook potentieel handig.

[ Voor 8% gewijzigd door Thralas op 08-02-2019 14:21 ]

[TAMW]

Hero of Time schreef op woensdag 6 februari 2019 @ 15:39:
Mijn vraag/probleemomschrijving:
Op kantoor hebben we drie site-to-site VPN verbindingen naar verschillende endpoints. Eentje is een ipsec/IKEv1 verbinding met een Sophos UTM. Dat blijft zonder problemen draaien. De andere twee zijn ipsec/IKEv2 naar Ubuntu 16.04 met Strongswan 5.3.5. Deze hadden eerst het probleem dat elk uur de

Ik zou als test/workaround eens van de probleem tunnel switchen van ikev2 naar ikev1
In de praktijk zie ik wel eens vaker reliability issues i.s.m ike v2 als de vendor aan beide kanten niet hetzelfde is.

[Hero of Time]

Thralas schreef op vrijdag 8 februari 2019 @ 14:18:
[...]

De logs van de ASA?

Via ASDM heel lastig te krijgen. Als ik live monitoring aan zet, zie ik maar een paar minuten en het wordt overspoelt met andere logging die helemaal niet relevant is. Geen idee hoe dat fatsoenlijk is te configureren, maar ik vermoed dat wat we standaard zien, elke verbinding die door het apparaat heen gaat wordt getoond. Compleet nutteloos dus en overspoelt de zinvolle meldingen.

Ik kan de weergave wel filteren, maar het is dan maar de vraag of wat ik laat zien ook alles is wat nodig is en niet net dat belangrijke stukje mis. En omdat het ook niet te voorspellen is wanneer het verkeer stopt door de tunnel heen, is het ook niet mogelijk om gericht het log te openen.

Overigens zie ik aan het begin van je Strongswan-log een ESP SA rekey, geen 'phase1' rekey (neem aan dat je daarmee IKE SA rekey bedoelt, phases zijn iets van IKEv1).

Ik dacht dat er niet echt een wezenlijk verschil tussen IKE v1 en v2 zat voor dit proces mbt de terminologie. Het is iig het rekey proces voor datgeen wat een lifetime heeft van 1 dag.

De daaropvolgende delete van de (oude) ESP SA aan de zijde van Strongswan lijkt niet te worden geackt. Logs van de ASA lijken me daartoe bijzonder relevant.

Als ik weet hoe ik de logs fatsoenlijk uit de ASA kan trekken, kan ik die verstrekken.

Neem aan dat je op zo'n ASA ook de IPsec/IKE state wel kunt dumpen. Lijkt me ook potentieel handig.

Als je bedoelt dat ik vanaf de ASA kant de verbinding kan verbreken, ja, dat kan. Ik zie dan geen crypto keys e.d. meer van de connectie. Bij de Strongswan kant lijkt het echter niet helemaal door te komen en moet ik die herstarten om de connectie opnieuw te maken. Echter heeft dat dus helaas geen nut, de tunnel komt wel up alsof alles werkt, maar verkeer is nog steeds niet mogelijk.

De status van de tunnel is te zien en als ik 't vergelijk met de andere IKEv2 tunnel die nog wel gewoon verkeer toestaat zie ik geen afwijkingen.

TAMW schreef op vrijdag 8 februari 2019 @ 14:40:
[...]

Ik zou als test/workaround eens van de probleem tunnel switchen van ikev2 naar ikev1
In de praktijk zie ik wel eens vaker reliability issues i.s.m ike v2 als de vendor aan beide kanten niet hetzelfde is.

Daar heb ik ook nog aan gedacht. Ik zal dan even moeten uitzoeken hoe ik Strongswan zo ver krijg om een IKEv1 tunnel op te zetten. Met de UTM, die alleen IKEv1 ondersteunt, hebben we immers een stabiele verbinding.

Toch zou ik liever IKEv2 willen gebruiken. Het werkt an sich, tot een bepaalde tijd. Er moet dus iets meer achter zitten dan een verschil in vendor ID.

[ Voor 5% gewijzigd door Hero of Time op 08-02-2019 15:12 ]

[Appel]

De laatste keer dat ik met vergelijkbare problemen aan de slag was heb ik er heel veel aan gehad om zowel de systeemtijd als de firewall van alle devices onder de loep te nemen.

Voor de firewall moest ik er specifiek op letten dat het IKE verkeer tussen de twee sites via de externe interfaces moest worden toegestaan. In mijn geval was het maar mogelijk vanuit een van de richtingen waardoor er maar 1 kant een mogelijkheid heeft om het rekey proces te starten.

[TAMW]

Hero of Time schreef op vrijdag 8 februari 2019 @ 15:10:
[...]


Toch zou ik liever IKEv2 willen gebruiken. Het werkt an sich, tot een bepaalde tijd. Er moet dus iets meer achter zitten dan een verschil in vendor ID.

Waarom zou je liever ike v2 gebruiken? In jouw setup zie ik niet echt dingen waarom ike v2 een must is.

Met het verschil bedoel ik niet alleen het vendor ID maar de gehele v2 implementatie die per vendor verschilt.

[Hero of Time]

Appel schreef op vrijdag 8 februari 2019 @ 15:18:
De laatste keer dat ik met vergelijkbare problemen aan de slag was heb ik er heel veel aan gehad om zowel de systeemtijd als de firewall van alle devices onder de loep te nemen.

Tijd staat goed en wijkt niet (veel) af.

Voor de firewall moest ik er specifiek op letten dat het IKE verkeer tussen de twee sites via de externe interfaces moest worden toegestaan. In mijn geval was het maar mogelijk vanuit een van de richtingen waardoor er maar 1 kant een mogelijkheid heeft om het rekey proces te starten.

Als het goed is, wordt door beide kanten hier desgewenst een rekey proces gestart. Maar omdat de lifetime toch gelijk is voor de keys, zullen ze het op ongeveer hetzelfde moment doen. Of iig reageren op het verzoek van de ander.

Het opbouwen van de tunnel gebeurt echter alleen door de Strongswan kant. De ASA is responder. Ik heb 'm niet betrapt op het zelf initiëren van de tunnel.

TAMW schreef op vrijdag 8 februari 2019 @ 15:24:
[...]

Waarom zou je liever ike v2 gebruiken? In jouw setup zie ik niet echt dingen waarom ike v2 een must is.

Nu zal het niet direct een wereldschokkend verschil zijn, maar is IKEv2 niet veiliger dan v1?

Met het verschil bedoel ik niet alleen het vendor ID maar de gehele v2 implementatie die per vendor verschilt.

Hmm, ok. Dat zou dan verklaren waarom de tunnel als nieuw wordt opgebouwd nadat de ikelifetime is verlopen. Niet dat het op een willekeurig moment verkeer weigert. Ik ga maandag kijken wat een v1 tunnel doet. Hopelijk hoeft niet de ASA herstart te worden om verkeer weer mogelijk te maken.

[TAMW]

Hero of Time schreef op vrijdag 8 februari 2019 @ 15:46:
[...]


Nu zal het niet direct een wereldschokkend verschil zijn, maar is IKEv2 niet veiliger dan v1?


[...]

Minimaal verschil, Peer validation is beter. maar dit uit zich meer in beter bescherming tegen DOS aanvallen.
ikev1 is op dit moment gewoon nog steeds veilig mits je maar de goede ciphers gebruikt.

[Thralas]

Hero of Time schreef op vrijdag 8 februari 2019 @ 15:10:
Ik kan de weergave wel filteren, maar het is dan maar de vraag of wat ik laat zien ook alles is wat nodig is en niet net dat belangrijke stukje mis. En omdat het ook niet te voorspellen is wanneer het verkeer stopt door de tunnel heen, is het ook niet mogelijk om gericht het log te openen.

Sorry, ik weet niets van ASA. Maar zoiets lijkt me handig: ASA IKEv2 Debugs for Site-to-Site VPN with PSKs

Neem aan dat je dat via SSH wel aan kunt zetten? Dan heb je volgens mij andere informatie dan waar je nu naar zit te kijken...

elke verbinding die door het apparaat heen gaat wordt getoon

..lijkt me niet persé enkel het relevante (namelijk: IKEv2 state)

Levert alsnog een hoop informatie op als ik de Cisco-pagina mag geloven (complete message dumps), maar als je de output van je SSH client logt dan kun je 'm daarna naast de Strongswan log leggen op te kijken of je iets geks ziet op het exacte tijdstip van die rekey en de SA delete die kwijtraakt.

Als je bedoelt dat ik vanaf de ASA kant de verbinding kan verbreken,

Nee. Bedoelde de daadwerkelijke state van IKE. Gezien:

code:

charon: 10[IKE] sending DELETE for ESP CHILD_SA with SPI c2cdaa5d
charon: 10[ENC] generating INFORMATIONAL request 63 [ D ]

Lijkt me dat je zou kunnen controleren of die SPI nog bestaat op de ASA. Zie het stukje onder 'Tunnel verification' op de gelinkte Cisco-pagina. Ziet er vrij handig uit om te hebben op het moment dat het stukgaat.

Timing is misschien wel tricky als je niet de mogelijkheid hebt om handig te debuggen (evt. lifetimes enorm laag zetten in de hoop dat je het dan ook vaker kunt reproduceren?)

Appel schreef op vrijdag 8 februari 2019 @ 15:18:
Voor de firewall moest ik er specifiek op letten dat het IKE verkeer tussen de twee sites via de externe interfaces moest worden toegestaan. In mijn geval was het maar mogelijk vanuit een van de richtingen waardoor er maar 1 kant een mogelijkheid heeft om het rekey proces te starten.

Goede opmerking. Kan geen kwaad om dat te controleren, al lees ik de log van Strongswan alsof er nog vrolijk wordt gedpd'ed in de tussentijd..

Hero of Time schreef op vrijdag 8 februari 2019 @ 15:46:
Als het goed is, wordt door beide kanten hier desgewenst een rekey proces gestart. Maar omdat de lifetime toch gelijk is voor de keys, zullen ze het op ongeveer hetzelfde moment doen. Of iig reageren op het verzoek van de ander.

Behalve als rekeys van een responder gefirewalled worden omdat de IKE-sessie uit een stateful firewall is verdwenen. Al geloof ik niet dat het hier aan de hand is (want je Strongswan kan initiaten), controleren waard.

[BluRay]

Heb je een specifieke reden waarom de ASA responder-only is? (puur uit interesse)

En heb je het volgende commando al geprobeerd als er geen verkeer meer door de tunnel gaat?
clear crypto ipsec sa inactive

[Hero of Time]

BluRay schreef op zaterdag 9 februari 2019 @ 05:48:
Heb je een specifieke reden waarom de ASA responder-only is? (puur uit interesse)

Geen idee. Ik was er nog niet toen de ASA in gebruik genomen werd. Het is in ASDM ook niet te zien dat het responder is. Ik kwam erachter toen ik het een en ander nakeek via SSH. Daar staat bij de tunnels dat het responder is.

En heb je het volgende commando al geprobeerd als er geen verkeer meer door de tunnel gaat?
clear crypto ipsec sa inactive

Ik heb elke keer de ipsec SA laten zien die er waren op het moment dat de boel uitvalt en geen inactieve gezien. In ADSM zie ik ook de uptime van de tunnel opnieuw beginnen. Ook het clearen van alle SA voor de specifieke peer geeft geen resultaat (na het herstarten van Strongswan op de server). Als in, de tunnel wordt wel opnieuw opgebouwd, maar nog steeds geen verkeer mogelijk.

[Vorkie]

@Hero of Time

Je draait 9.6.2

Resolved Bugs in Version 9.6(3.1)
Stale VPN Context entries cause ASA to stop encrypting traffic
Even onderzoeken of dit een bug is waar je tegenaan loopt? Valt specifiek onder IkeV2 en L2L VPN namelijk.

Verder lijkt het mij verstandig je ASA software te upgraden naar 9.6.4 er zijn nogal veel zaken "opgelost" .
https://www.cisco.com/c/e...tml#reference_dvd_zfb_2cb

[ Voor 5% gewijzigd door Vorkie op 09-02-2019 23:12 ]

[Hero of Time]

Tnx, hier was ik al een beetje bang voor. Ik heb geen idee of we een Cisco support contract hebben om de nieuwere ios te kunnen downloaden. Ik zal dit maandag even navragen. En je link wat beter bestuderen, nu is niet echt de juiste tijd.

[Hero of Time]

Even een update. We hebben geen Cisco support op ons account. Partij via wie we het apparaat hebben gevraagd voor de bestanden.

Ondertussen heb ik via SSH mbv https://www.cisco.com/c/e...935-asa-ikev2-debugs.html wat debug informatie naar voren gehaald voor het maken van de verbinding. Eerst de twee Strongswan instanties gestopt en gecontroleerd of er nog iets van crypto keys aanwezig waren en dat was niet meer het geval. Beginnen dus met een schone lei.

Door de debugging kwam ik er wel achter dat de Cisco wel degelijk probeert om een connectie op te zetten naar Strongswan. Maar omdat die niet luistert als de daemon niet draait, kan de verbinding niet worden gemaakt.

Uit de debug informatie kwam geen reden naar voren waarom het niet mogelijk is om verkeer er overheen te sturen en terug te krijgen. De stappen die worden uitgevoerd om de tunnel te maken komen overeen met de werkende en niet-werkende tunnel. Er vind een key-exchange plaats, de crypto maps worden opgezocht en gevonden, regels worden gemaakt en de connectie is voltooid. Maar geen verkeer dus.

En om het mooier te maken, vanochtend is de andere, nog wel werkende tunnel, opnieuw opgebouwd en kan geen verkeer meer afhandelen. Gelukkig sluiten we om 17:00, dus kan 'm vanavond een schop geven.

Ik heb ook de tip om IKEv1 te gebruiken geprobeerd, maar dat gaf niet het gewenste resultaat. Ik zag in de Strongswan log meldingen over invalid crypto e.d., terwijl de configuratie wel goed zou moeten zijn. Dat heb ik dus maar opgegeven toen het na een paar uur testen nog niet werkte.

Als ik de nieuwe IOS versie heb, is het updaten ervan niet zo lastig denk ik. Kwestie van de nieuwe op de flash zetten en rebooten. Ga ik uiteraard wel in de release notes e.d. fatsoenlijk uitzoeken zodat we niet met een ASA zitten die niets meer kan.

[PcDealer]

Kun je via snmp of zo de logging uitsturen naar een ander device? Ik heb hier twee 5510's nog onaangeroerd loggen en zal wat onderzoek plegen morgen als mijn vrouw uit huis is

[Hero of Time]

PcDealer schreef op vrijdag 15 februari 2019 @ 22:30:
Kun je via snmp of zo de logging uitsturen naar een ander device? Ik heb hier twee 5510's nog onaangeroerd loggen en zal wat onderzoek plegen morgen als mijn vrouw uit huis is

We hebben SNMP, zo weet ik dat de tunnels opnieuw opgebouwd worden en wanneer dat gebeurt. Maar logging eruit trekken, geen idee. De eerdere logging haalde ik op via SSH en heb ik met de hand uitgeplozen. Het is nu ook weekend, dus zal pas maandag weer op kantoor zijn.

Ik heb ook eind van de dag de ASA herstart omdat beide tunnels geen verkeer meer accepteerden. Eentje, die vandaag uitviel, kwam weer terug online. De andere heeft verbinding maar blijft een probleem hebben met verkeer.

Het vervelende is, is dat een traceroute vanaf m'n werkplek naar de server maar 1 hop laat zien: de Strongswan server zelf. En andersom net zo, van de server zie ik alleen m'n werkplek direct als resultaat. Niks geen ASA er tussen.

[PcDealer]

Quick search>> Heb je deze gezien?

Logging
https://www.cisco.com/c/e...-Firepower-Module-fo.html

https://www.cisco.com/c/e...ule-SFR-Troubleshoot.html

Houd deze in de gaten?
Cisco ASA IKEV2 Requirements?
https://community.cisco.c...requirements/td-p/3799641

Slow S2S VPN Tunnels, Lots of Fragmentation?
https://community.cisco.c...ragmentation/td-p/3801476

Als dit van toepassing is:

Appel schreef op vrijdag 8 februari 2019 @ 15:18:
De laatste keer dat ik met vergelijkbare problemen aan de slag was heb ik er heel veel aan gehad om zowel de systeemtijd als de firewall van alle devices onder de loep te nemen.

Dan NTP bekijken? https://www.cisco.com/c/e...echnote-firesight-00.html

---

Hero of Time schreef op vrijdag 15 februari 2019 @ 10:29:
Even een update. We hebben geen Cisco support op ons account. Partij via wie we het apparaat hebben gevraagd voor de bestanden.

Wait, whut? Is de firewall geleased of zo?

[ Voor 49% gewijzigd door PcDealer op 16-02-2019 00:42 ]

[Hero of Time]

NTP is geconfigureerd op de ASA, de tijd loopt ook gewoon goed.

Het apparaat is via een andere partij, die alles heeft ingericht voor ik in dienst kwam, aangeschaft. Als ik een nieuwe IOS of ASDM wil downloaden voor de ASA krijg ik met ons account de melding dat we geen support contract hebben. Omdat ik niet verder in 't account heb gekeken, denk ik dat het een standaard Cisco account is en er geen product aan gekoppeld is. En anders is de supportperiode ondertussen verlopen.

Ik heb wel al het een en ander aan informatie gevonden voor logging. De linkjes die je plaatst heb ik mogelijk al gezien, maar dat was toen ik nog geen SSH toegang had geregeld. Wat ik via ASDM aan logging kan krijgen en instellen heb ik niet echt bekeken. Alleen dat de standaard logging die aan staan en vanzelf start als je ASDM start redelijk nutteloos is. Het is van de zotte om logging te krijgen van elke verbinding die opgezet wordt en weer sluit. Dus ook verkeer naar een website toe e.d.

De IKEv2 vereisten voldoen we wel aan, anders zou het niet werken. En zouden de tunnels niet opgebouwd worden. Ik zal ze iig wel eens doornemen zodat ik zeker weet dat we niets over het hoofd zien.

Daarnaast doe ik het systeembeheer in m'n eentje en de servers die we hebben moeten ook nog onder handen genomen worden. Ik heb dus niet alle tijd om heel uitvoerig dit allemaal uit te gaan zoeken en testen. Zo nu en kan kan ik er naar kijken.

[Hero of Time]

Het heeft even geduurd, maar ik heb weer wat tijd gevonden om hier verder mee te gaan. Vorige week heb ik de tunnel naar onze testomgeving aangepast naar IKEv1, zoals ik twee weken daarvoor (dus ondertussen 3 weken geleden) dat voor productie had gedaan. We hebben dus geen IKEv2 tunnels meer.

Voordeel: ik krijg geen melding meer dat na 24 uur de tunnel opnieuw opgezet wordt. Ze blijven nu dagenlang online.

Nadeel: nog steeds geen verkeer over de tunnel naar productie. Test doet het wel.

Vrijdag heb ik nog de IOS bijgewerkt op de ASA naar 9.6 interim 4. En waar ik al bang voor was is het geval: ook hierna nog steeds geen verkeer door de tunnel mogelijk.

Omdat de tunnel dit weekend gewoon online is gebleven (ipv elke dag herstart), is het duidelijker zichtbaar of er verkeer wordt gegenereerd. De teller die aangeeft hoeveel bytes er is verstuurd en ontvangen geeft wel de indruk dat er verkeer de tunnel in gaat. Maar dit kan ook simpel DPD en rekey verkeer zijn, wat dan natuurlijk een vertekend beeld geeft.

Ik heb de ACL en NAT regels al meerdere keren bekeken om te zien of er iets verkeerd in staat, maar daar lijkt het niet op. Morgen zal ik de betreffende regels posten.

[Equator]

Hero of Time schreef op maandag 18 maart 2019 @ 19:52:

Nadeel: nog steeds geen verkeer over de tunnel naar productie. Test doet het wel.

Wat bedoel je met de test doet het wel? Kan je met een ping er wel verkeer over krijgen?

[Hero of Time]

Equator schreef op maandag 18 maart 2019 @ 20:08:
[...]

Wat bedoel je met de test doet het wel? Kan je met een ping er wel verkeer over krijgen?

We hebben twee omgevingen, productie en test. Beide hebben een site-to-site verbinding. De testomgeving is 100% werkbaar, ping, ssh, noem maar op, het gaat netjes door de tunnel. Productie doet echter niets het. Geen ping, geen ssh, het is alsof het in een zwart gat verdwijnt. Maar een packet-trace zegt 'all green'.

Ping ik naar productie, dan zie ik wel de Tx/Rx counter oplopen. Het lijkt dus verkeer de tunnel in te sturen, maar zie dat dus aan de andere kant niet aankomen. Andersom net zo.

[Equator]

En hoe zit de routing in elkaar? Heb je een laag 3 tekening die je kunt delen (na het weglaten van té interessante info)

[Vorkie]

Wat zegt:

debug crypto ipsec 127

op het moment dat je een ping start?

[Hero of Time]

De meeste informatie heb ik in de TS staan, maar kan morgen wel even een tekeningetje maken met hoe en wat het zou moeten lopen. Dit komt dan dus met de ACL en NAT regels. Die heb ik in de TS gezet zoals deze in ASDM zijn opgenomen. Via CLI is het makkelijker te lezen.

@Vorkie, geen idee, zal ik morgen dus voor je posten.

[ Voor 9% gewijzigd door Hero of Time op 18-03-2019 20:24 ]

[Hero of Time]

Dit is schematisch het netwerk. Niet heel spannend.


De relevante configuratie uit de CLI voor het verkeer:

code:

object network obj_test-int
 subnet 10.2.2.0 255.255.255.0
object network obj_prod-int
 subnet 10.1.1.0 255.255.255.0
object network obj_kantoor
 subnet 10.3.3.0 255.255.255.0

access-list Internet_cryptomap extended permit ip 10.3.3.0 255.255.255.0 object obj_test-int
access-list Internet_cryptomap_2 extended permit ip 10.3.3.0 255.255.255.0 object obj_prod-int

nat (lan,wan) source static obj_kantoor obj_kantoor destination static obj_test-int obj_test-int no-proxy-arp route-lookup
nat (lan,wan) source static obj_kantoor obj_kantoor destination static obj_prod-int obj_prod-int no-proxy-arp route-lookup

crypto map Internet_map 1 match address Internet_cryptomap
crypto map Internet_map 1 set peer 192.168.100.2
crypto map Internet_map 1 set ikev1 transform-set ESP-AES-256-SHA ESP-AES-256-SHA-TRANS
crypto map Internet_map 1 set security-association lifetime seconds 3600
crypto map Internet_map 1 set security-association lifetime kilobytes unlimited
crypto map Internet_map 2 match address Internet_cryptomap_2
crypto map Internet_map 2 set peer 192.168.50.2
crypto map Internet_map 2 set ikev1 transform-set ESP-AES-256-SHA ESP-AES-256-SHA-TRANS
crypto map Internet_map 2 set security-association lifetime kilobytes unlimited

Adressen gefingeerd.

Ik kan dus wel van 10.3.3.x naar 10.2.2.x pingen, maar niet naar 10.1.1.x. Een 'debug crypto ipsec 127' laat niets zien als ik ga pingen. Ook 'debug crypto ikev1 127' blijft stil buiten de DPD meldingen om. Wat vreemd genoeg alleen voor prod gebeurt, voor test zie ik geen DPD meldingen.

Omdat zowel test als prod op een openstack omgeving staat, ga ik nog controleren wat voor security/netwerk regels hier op staan ingesteld. Maar omdat daar in feite niets aan is verandert tussen toen het werkte en nu, verwacht ik weinig.
Edit: Nope, geen verschil, alle regels staan verkeer toe vanaf ons kantoor.

[TAMW]

@Hero of Time

Als je snift aan de WWW ASA kant en de Stronswan kant, zie je dan de ESP pakketten naar het WWW DST adres als je door de tunnel pingt? En als je de size van ping pakketjes aanpast zie je dat dan ook terug in de grote van de ESP pakketten?

Je weet dan in ieder geval echt of je pakketjes de tunnel ingaan en verstuurd worden.

Wat je ook nog kan proberen om ipsec NAT-T mode te gebruiken kijken of iets uitmaakt, worden er andere poorten gebruikt.

[Hero of Time]

@TAMW, uit m'n TS:

Crypto Maps
IKEv2 IPsec Proposal: AES256_SHA256
Enable NAT-T

Er wordt dus al NAT-T gebruikt. Toegegeven, dit is met de IKEv2 tunnel en niet met de huidige IKEv1, maar qua settings is er niets verandert dan het IKE protocol versie.

Ik heb ook al een paar keer met tcpdump aan de strongswan kant gekeken wat er met een ping gebeurt. Er zit nog een server achter de productie machine, dus van daaruit de ping uitgevoerd. Tcpdump laat icmp zien, maar de reply blijft uit.

Als ik ga sniffen, moet ik echt heel specifiek gaan filteren om al het andere verkeer uit te sluiten van de weergave, anders overstroomt dat wat ik wil zien door de rest dat naar buiten gaat.

Toen ik gisteren met de 'debug crypto ikev1 127' de boel bekeek, zag ik wel wat hits verschijnen toen ik een ping startte naar productie intern. Maar dat was alleen bij het starten van de ping, het eerste packet dat verstuurd werd zeg maar. Ik kan morgen wel verder kijken hoe zit zich uit.
Ik ga er ook even vanuit dat met de waarde voor debug die ik op kan geven, tussen 1 en 255, dat 1 de minste info geeft en 255 het meeste. Of geeft het andere informatie weer met verschillende getallen? Ik ga iig https://www.cisco.com/c/e.../5409-ipsec-debug-00.html verder bekijken. Lijkt mooi uit te leggen wat ik nog kan bekijken.

[TAMW]

Hero of Time schreef op woensdag 20 maart 2019 @ 20:59:
@TAMW, uit m'n TS:

[...]


Ik heb ook al een paar keer met tcpdump aan de strongswan kant gekeken wat er met een ping gebeurt. Er zit nog een server achter de productie machine, dus van daaruit de ping uitgevoerd. Tcpdump laat icmp zien, maar de reply blijft uit.

Bedoel je met hierboven nu dat je de ping uit de tunnel ziet komen of erin ziet gaan?

Wat ik bedoel is dat je aan de "buitenkant" van de tunnel snift, dus de internet src/dst ESP en IKE pakketten moet je zien

Als je NAT-T gebruikt kun je ook zonder of wordt er aan 1 van de 2 kanten echt genat?

Aangezien het blijkbaar een intermittent probleem is wat zonder config wijzigingen met alleen een reboot van de ASA oplost zou je deze dingen ook nog kunnen proberen:

alle sessions clearen met clear conn van de ipsec probleem peer (dus dst en src)

Van main naar agressive mode gaan voor de ipsec tunnel.

Als er aan de linux stronswan kant iptables gebruikt worden stateless ipv statefull gaan firewallen als test.

[ Voor 5% gewijzigd door TAMW op 20-03-2019 21:40 ]

[Hero of Time]

TAMW schreef op woensdag 20 maart 2019 @ 21:14:
[...]

Bedoel je met hierboven nu dat je de ping uit de tunnel ziet komen of erin ziet gaan?

Ik zag de ping op de 'router' aankomen om de tunnel in te sturen, maar ik kan mij niet meer herinneren of ik ook zag waar de ping heen ging, de default gateway uit of de tunnel in.

Wat ik bedoel is dat je aan de "buitenkant" van de tunnel snift, dus de internet src/dst ESP en IKE pakketten moet je zien

Dacht al dat je dat bedoelde. Ik zal daarom op de ASA het debug niveau eens verhogen en kijken wat daar uit komt.

Als je NAT-T gebruikt kun je ook zonder of wordt er aan 1 van de 2 kanten echt genat?

Daar twijfel ik dus een beetje aan. Hoewel de IP adressen gefingeerd zijn, is het wel de situatie zoals deze in gebruik is. Ik zou het niet NAT'en noemen, omdat er alleen maar tussen twee verschillende subnets wordt geroute. Echter staat het op alle drie de tunnels die we hebben aan en maar eentje weigert opeens verkeer zonder reden.

Aangezien het blijkbaar een intermittent probleem is wat zonder config wijzigingen met alleen een reboot van de ASA oplost zou je deze dingen ook nog kunnen proberen:

alle sessions clearen met clear conn van de ipsec probleem peer (dus dst en src)

Dat is nou net het meest vervelende. Het werkte eerst weer na een reload van de ASA, maar dat is nu ook niet meer het geval. Vrijdag had ik de IOS versie bijgewerkt en direct na boot was er nog steeds geen verkeer mogelijk naar prod. Wat mij wel opviel, was dat de andere twee tunnels aanzienlijk eerder online waren.

Van main naar agressive mode gaan voor de ipsec tunnel.

Dat doe ik liever niet. Want de tunnel is wel actief en voor de test omgeving hebben we een exact gelijke configuratie, op IP adressen na, en dat werkt wel gewoon.

Als er aan de linux stronswan kant iptables gebruikt worden stateless ipv statefull gaan firewallen als test.

Het staat erop, maar geen specifieke regels ingesteld. Op prod was initieel ook geeneens iptables aanwezig, wat op test wel was. Maar daar was geen enkele regel actief.

Qua configuratie is het aan de strongswan kanten gelijk. Wat heel misschien een potentiële factor zou kunnen spelen, is de uptime en kernel versie van prod. Test is meer recent herstart en draait derhalve een wat nieuwere kernel build. Maar omdat het eerst wel werkte, acht ik die kans minimaal tot nihil. En zomaar een reboot uitvoeren gaat ook niet zomaar. Daar is het prod voor.

[Hero of Time]

Nou, shit. Een 'tcpdump esp' laat het pijnlijk zien wat het issue is. Doe ik dit op prod, dan zie ik alleen verkeer van de server naar kantoor gaan, niets terug. Op test zie ik wel ESP verkeer van kantoor binnenkomen.

Omdat we op een OpenStack omgeving draaien, hebben we te maken met security groups als aparte firewall er tussen. We hebben een aparte security group dat al het verkeer van ons kantoor toestaat en die is voor beide machines toegewezen. Het zou dan dus in de machine zelf moeten zitten. Nu dus nog uitvogelen hoe ik kan testen of protocol 50 beschikbaar is of wordt geblokkeerd en hoe dit dan is te verhelpen. Anders wordt het een ticket inschieten bij de provider en ze bellen.

[Hero of Time]

Bijkomend 'leuk' probleem. Het is niet dat prod niets ontvangt, het is dat kantoor überhaupt niets stuurt. Ik heb al de 'debug crypto ikev1 255' vergeleken en zie daar geen gekke dingen of verschillen met de testomgeving.
Zoals twee weken terug gezegd, zie ik alleen DPD verkeer. Dat komt alleen als de andere kant geen verkeer genereert en dat is ook het issue.

Verder debuggen dan maar, met ipsec en andere opties in de asa. Hopelijk kom ik eruit waarom de ASA geen ESP verkeer genereert.

Edit:
Na de lunch ipsec debug aangezet. Ik zie geen noemenswaardig verschil tussen test en prod. Lijkt haast alsof de ASA compleet van 't padje is voor deze specifieke route/subnet.

[ Voor 15% gewijzigd door Hero of Time op 02-04-2019 21:59 ]

[Turdie]

Hero of Time schreef op dinsdag 2 april 2019 @ 09:16:
Bijkomend 'leuk' probleem. Het is niet dat prod niets ontvangt, het is dat kantoor überhaupt niets stuurt. Ik heb al de 'debug crypto ikev1 255' vergeleken en zie daar geen gekke dingen of verschillen met de testomgeving.
Zoals twee weken terug gezegd, zie ik alleen DPD verkeer. Dat komt alleen als de andere kant geen verkeer genereert en dat is ook het issue.

Verder debuggen dan maar, met ipsec en andere opties in de asa. Hopelijk kom ik eruit waarom de ASA geen ESP verkeer genereert.

Edit:
Na de lunch ipsec debug aangezet. Ik zie geen noemenswaardig verschil tussen test en prod. Lijkt haast alsof de ASA compleet van 't padje is voor deze specifieke route/subnet.

Misschien een routing issue ergens?

[Hero of Time]

shadowman12 schreef op dinsdag 2 april 2019 @ 23:56:
[...]

Misschien een routing issue ergens?

Nee, dat is het niet. Althans, zou het niet moeten zijn als ik de configuratie bekijk. Zoals ik in Hero of Time in "[ASA 5506/Strongswan] Na een tijd geen verkeer over s2s vpn" heb aangegeven, zijn de juiste access-list en NAT regels aanwezig om het verkeer over de tunnel te sturen. En een packet trace stuurt ook het verkeer de tunnel in (al zie ik dat niet aan de andere kant terug).

[mhofstra]

Staat aan de ene kant in de vpn config een subnet en aan de andere kant losse IP's (of een IP range)?

[Turdie]

Ik denk dat toch dat je in dit geval de support van Cisco en strongswan moet inschakelen anders ga je hier nooit uitkomen. Ik zag dat je een issue kan maken bij strongswan, misschien is dat een idee, dan kun je in ieder geval uitsluiten met hun dat het niet aan strongswan ligt. Er staat ook een email-adres van iemand van strongswan bij, een van de developers
[e-mail]

[ Voor 67% gewijzigd door Turdie op 04-04-2019 12:36 ]

[Hero of Time]

mhofstra schreef op donderdag 4 april 2019 @ 12:09:
Staat aan de ene kant in de vpn config een subnet en aan de andere kant losse IP's (of een IP range)?

Nee, er wordt een network object gebruikt en daar is een subnet in gedefinieerd. Zie de config die ik iets hoger heb gepost.

shadowman12 schreef op donderdag 4 april 2019 @ 12:32:
Ik denk dat toch dat je in dit geval de support van Cisco en strongswan moet inschakelen anders ga je hier nooit uitkomen. Ik zag dat je een issue kan maken bij strongswan, misschien is dat een idee, dan kun je in ieder geval uitsluiten met hun dat het niet aan strongswan ligt. Er staat ook een email-adres van iemand van strongswan bij, een van de developers
[e-mail]

Dat zal dan eerder Cisco zijn, dan Strongswan. Gister een testje gedaan met een ping vanaf de server naar mijn PC. Ik zie op mijn eigen systeem icmp binnenkomen, het antwoord eruit gaan naar de ASA en dan is het stil op de server. Niet gekeken wat er op de ASA gebeurt, dat komt op een ander moment als ik er weer voor ga zitten.

Het is iig erg raar. Feitelijk niets verandert en opeens geen verkeer meer mogelijk. Ondertussen zaken aangepast, maar nog steeds niets. De veranderingen op een rijtje:
- ASA IOS van 9.6(1) naar 9.6(4);
- S2S VPNs van IKEv2 naar IKEv1;
- Meerdere herstarts van de ASA;
- Getest met nieuwere versie Strongswan, daarna weer terug naar vorige versie ivm geen verandering.

Veel resultaten wat ik online zie met vergelijkbare issues is het gevolg van fouten in de config. Bij ons was er in principe niets verandert en ik zie niet de gemaakte fouten bij mij. Zelfs debug informatie laat geen verschil zien tussen de werkende en niet-werkende tunnel.

[mhofstra]

Hero of Time schreef op donderdag 4 april 2019 @ 14:01:
[...]

Nee, er wordt een network object gebruikt en daar is een subnet in gedefinieerd. Zie de config die ik iets hoger heb gepost.

En de andere kant?
En als je bij beide kanten de tunnel status bekijkt zien je dan aan beide kanten een subnet?

[Hero of Time]

mhofstra schreef op donderdag 4 april 2019 @ 20:31:
[...]

En de andere kant?
En als je bij beide kanten de tunnel status bekijkt zien je dan aan beide kanten een subnet?

Uiteraard. Ik heb echt teken voor teken vergeleken met de test omgeving die wel werkt. IP adressen en subnetten heb ik zo onderhand wel honderd keer nagekeken. Ik had tijdens het ombouwen van IKEv2 naar IKEv1 een foutje gemaakt in het subnet en de tunnel kwam niet online (foutje zat in de Strongswan kant) met ook een duidelijke melding erover (die ik 3x moest lezen tot ik de fout zag, /22 doet 't slecht als je /23 hebt ). Maar dat foutje had ik op test gemaakt, niet prod, die was al goed.

Morgen neem ik wat tijd om routering in de ASA te debuggen, want ik wil weten waar het verkeer heen gaat dat voor prod bestemd is. En waarom het dus schijnbaar niet naar de tunnel gaat. Packet-trace zegt iig dat het de tunnel in zou moeten gaan.

[ Voor 3% gewijzigd door Hero of Time op 04-04-2019 20:38 ]

[Hero of Time]

Nou, het probleem is opgelost. Op de meest idiote en onlogische manier.

Het productieplatform stuurt data via FTP (don't ask, heb ik zelf niet opgezet) naar een server bij ons op kantoor. Dit ging altijd over de VPN, maar omdat zo'n twee maanden geleden de VPN instabiel bleek, met toen al uitvallend verkeer, had ik als work-around een NAT regel gemaakt om FTP verkeer van die server buitenom naar de interne te sturen.

Zojuist heb ik die regel verwijdert en spontaan is verkeer weer mogelijk over de VPN. Waarom die NAT regel een probleem was, begrijp ik niet. TCP poorten 20 en 21 hebben niets te maken met ESP verkeer. En inkomend ervan zou al helemaal niets met uitgaand te maken moeten hebben. Blijkbaar was de ASA daar toch door in de war.