[Cisco] ASA5510 static route ASDM

[Snors]

Allen,

Ik probeer via Cisco ASDM 5.2 een static route toe te voegen op mijn ASA5510 VPN/Firewall maar dit wilt maar niet werken.

Het netwerk is als volgende geconfigureerd;
- VPN van ASA5510 1(Nederland) -> ASA5510 2(Amerika)

De static routes die aanwezig zijn op de ASA5510 1 zijn:
Interface; Outside, IP Address; 0.0.0.0, Netmask; 0.0.0.0, Gateway IP; Publiek IP ASA5510 2; Metric 1; Options; None

Wat ik uiteindelijk wil is een netwerk die met fiber verbonden is met de ASA5510 2(Amerika) bereiken. Dit netwerk valt echter buiten het "standaard" subnet wat wij gebruiken.
"Standaard" netwerk = 10.x.x.x
"Nieuw" netwerk = 192.168.8.x

Hoe de route moet verlopen is:
Client Nederland -> ASA5510 1(Nederland) -> ASA5510 2(Amerika) over VPN -> 192.168.8.x
Vanaf een PC uit Amerika kan ik prima het 192.168.8.x netwerk benaderen. Vanuit Nederland dus niet.

Wat ik al heb geprobeerd:
Static route & NAT Rule aanmaken met de volgende gegevens:
Static Route
Interface: outside
IP: 192.168.8.0
Netmask: 255.255.255.0
Gateway IP: Internet of Externe IP ASA5510 2
Metric: 3

NAT Rule
Type: Exempt
Source: 10.24.0.0/24
Destination: 192.168.8.0/24
Interface: Outbound

Wie o wie kan mij verder op weg helpen?

[_-= Erikje =-_]

nat exempten en zorgen dat ie ook in je IPSec proxy valt, gezien die route ws al in je default viel is die niet eens expliciet nodig. Je kan met de Packet tracer ook nog stap voor stap zien wat er met je pakketje gebeurd

[Snors]

_-= Erikje =-_ schreef op dinsdag 11 december 2012 @ 14:16:
nat exempten en zorgen dat ie ook in je IPSec proxy valt, gezien die route ws al in je default viel is die niet eens expliciet nodig. Je kan met de Packet tracer ook nog stap voor stap zien wat er met je pakketje gebeurd

Even een EDIT: Ik krijg nu op zowel TCP als ICMP de melding RESULT: The packet is allowed. Echter als ik een ping via CMD doe of bijvoorbeeld RDP probeer naar een server in het nieuwe netwerk dan krijg ik nog steeds timeouts....

Ook de PING tool in de ASDM krijgt timeouts. Enig idee wat er nu nog fout zou kunnen staan...

Alvast bedankt!

[ Voor 46% gewijzigd door Snors op 11-12-2012 15:51 ]

[_-= Erikje =-_]

Andere kant ook routes terug en stopt de asa het pakket ook in de tunnel (kun je ook in de tracer zien)

[Snors]

_-= Erikje =-_ schreef op dinsdag 11 december 2012 @ 17:37:
Andere kant ook routes terug en stopt de asa het pakket ook in de tunnel (kun je ook in de tracer zien)

Ja ik heb zojuist de IPSec rule weer toegevoegd en hij gaat van NAT LOOKUP(SUCCESS) naar VPN LOOKUP(FAILURE).

Result = The packet is dropped, (acl-drop) Flow is denied by configured rule.
Type - VPN
Subtype - encrypt
Action - DROP

Wat houd dit in? Gaat het fout op de ASA5510 aan de andere kant(Amerika)?
Nogmaals enorm bedankt!

[mbaltus]

Ik neem aan dat de VPN naar de US gewoon goed werkt en dat Ping toegestaan is? Is de IP reeks waar je naartoe wilt ook toegevoegd aan je VPN tunnel? Heb je een ACL waarin het verkeer naar die IP reeks wordt toegestaan? wordt door de ACL op de ASA in de US ook verkeer vanaf IP reeks toegestaan?

[Snors]

mbaltus schreef op woensdag 12 december 2012 @ 16:20:
Ik neem aan dat de VPN naar de US gewoon goed werkt en dat Ping toegestaan is? Is de IP reeks waar je naartoe wilt ook toegevoegd aan je VPN tunnel? Heb je een ACL waarin het verkeer naar die IP reeks wordt toegestaan? wordt door de ACL op de ASA in de US ook verkeer vanaf IP reeks toegestaan?

- VPN naar de US werkt gewoon goed en ik kan alle servers in de US gewoon vanaf NL pingen.
- IP Reeks heb ik als IPSEC-RA toegevoegd aan de Tunnel Group als Address Pool
- De ACL lijkt ook goed te staan. Ik heb een Access Rule toegevoegd die al het IP en ICMP verkeer toestaat naar het nieuwe netwerk.
- ACL op de ASA in de US lijkt me ook juist. Dit op basis van als ik inlog op een server in de US en doe een ping command naar het nieuwe netwerk dan krijg ik wel netjes een response

Zie hieronder een screenshot van de Cisco packet tracer:


Wie o wie kan mij de juiste richting op sturen

[mhofstra]

De nieuwe reeks ook als NAT EXEMPT toegevoegd in de NL ASA?

[Snors]

mhofstra schreef op donderdag 13 december 2012 @ 10:02:
De nieuwe reeks ook als NAT EXEMPT toegevoegd in de NL ASA?

Yes is ook gedaan:

[_-= Erikje =-_]

Klik de nat vakjes eens open en kijk of ie idd je source IP niet verbouwd, daarnaast heb je 'm wel in je ipsec ACL toegevoegd?

[Snors]

_-= Erikje =-_ schreef op donderdag 13 december 2012 @ 11:01:
Klik de nat vakjes eens open en kijk of ie idd je source IP niet verbouwd, daarnaast heb je 'm wel in je ipsec ACL toegevoegd?

De volgende IPSec rule is toegevoegd:

Waarbij 10.1.7.4 het interne IP adres van de ASA5510 in de USA is. Group2 is de groep waar de IPSec van de VPN ook inhangt.

Ik snap niet wat je bedoelt met klik de NAT vakjes eens open. Hier in ieder geval het Edit scherm:


En alle NAT Rules:


Ik wil niet overkomen alsof ik zelf niks probeer maar ik ben gewoon ten einde raad wat hier precies fout gaat. Ik heb eerder nieuwe netwerken toegevoegd op exact dezelfde wijze en dat werkte gewoon... Thanks voor jullie hulp in ieder geval!

[ Voor 3% gewijzigd door Snors op 13-12-2012 11:18 ]

[mhofstra]

_-= Erikje =-_ bedoelt (waarschijnlijk) de vakjes in het Packet Tracer scherm.

[ Voor 12% gewijzigd door mhofstra op 13-12-2012 11:32 ]

[Snors]

Dan krijg ik het volgende:
NAT EXEMPT:

code:

Config

nat (inside) 0 access-list inside_nat0_outbound 
match ip inside any outside 192.168.8.0 255.255.255.0 
NAT exempt 
translate_hits = 2, untranslate_hits = 0

NAT 1:

code:

Config

nat (inside) 0 access-list inside_nat0_outbound 
nat (inside) 1 0.0.0.0 0.0.0.0 
match ip inside any outside any 
dynamic translation to pool 1 (<publiek IP ASA5510 NL> [Interface PAT]) 
translate_hits = 894606, untranslate_hits = 58801

NAT 2:

code:

Config

nat (inside) 0 access-list inside_nat0_outbound 
nat (inside) 1 0.0.0.0 0.0.0.0 
match ip inside any outside any dynamic translation to pool 1 (<publiek IP ASA5510 NL> [Interface PAT]) 
translate_hits = 894606, untranslate_hits = 58801

[_-= Erikje =-_]

M34nM4chin3 schreef op donderdag 13 december 2012 @ 11:16:
[...]

De volgende IPSec rule is toegevoegd:
[afbeelding]
Waarbij 10.1.7.4 het interne IP adres van de ASA5510 in de USA is. Group2 is de groep waar de IPSec van de VPN ook inhangt.

Zonder de rest van het scherm te zien is het ff lastig te zeggen (mijn ASDM ziet er anders uit) maar is 10.1.7.4 het peer ip ? dan zou je daar het externe IP van die ASA aan de andere kant verwachten...

Zo te zien idd het peer ip, wat je moet doen is bij Source van je orginele VPN tunnel al de ACL toevoegen (daar kunnen meerdere ACL's staan), het peer IP is idd het externe IP van je ASA aan de andere kant. Group2 slaat op DH group2 en heeft met PFS te maken

[ Voor 19% gewijzigd door _-= Erikje =-_ op 13-12-2012 14:07 ]

[Snors]

_-= Erikje =-_ schreef op donderdag 13 december 2012 @ 14:02:
[...]


Zonder de rest van het scherm te zien is het ff lastig te zeggen (mijn ASDM ziet er anders uit) maar is 10.1.7.4 het peer ip ? dan zou je daar het externe IP van die ASA aan de andere kant verwachten...

Zo te zien idd het peer ip, wat je moet doen is bij Source van je orginele VPN tunnel al de ACL toevoegen (daar kunnen meerdere ACL's staan), het peer IP is idd het externe IP van je ASA aan de andere kant. Group2 slaat op DH group2 en heeft met PFS te maken

Zie hier het totaal overzicht van mijn IPSec Rules:


Korte beschrijving:
Rule 1 = Nederland -> Corporate
Rule 2 = Overbodig(ignore)
Rule 3 = Vianen -> Nieuw netwerk USA
Rule 4(dynamic) = Geen idee..

De ACL van de VPN Tunnel kan ik die aanpassen bij de Group Policy die aan de Tunnel Group is ge-assigned? Dit is de overview van mijn ASDM v5.2:


De 10.1.7.4 heb ik inmiddels ook veranderd naar hetzelfde IP als Rule 1(externe IP ASA5510 in USA). Ook heb ik de Priority op 30 gezet zodat hij boven Rule 2 komt te staan. Nog steeds hetzelfde probleem.

Thanks,

[ Voor 12% gewijzigd door Snors op 13-12-2012 14:23 ]

[mbaltus]

Het lijkt er nu op alsof je een aparte VPN tunnel wilt opzetten naar dat netwerk, maar volgens mij moet je de 192 reeks toevoegen aan de destination van de peer naar de US. Daardoor wordt dat verkeer over dezelfde tunnel naar de US gestuurd en kan de ASA aan de andere kant het verkeer de juiste kant op routeren.

Of begrijp ik je vraag niet goed? Het 192 netwerk ligt toch achter de ASA in de US waar ook de andere systemen staan (dus als aparte DMZ zone of gerouteerd door een ander device)?

M34nM4chin3 schreef op donderdag 13 december 2012 @ 09:44:
[...]
- ACL op de ASA in de US lijkt me ook juist. Dit op basis van als ik inlog op een server in de US en doe een ping command naar het nieuwe netwerk dan krijg ik wel netjes een response

Dat zegt alleen maar dat je vanaf de US naar dat netwerk mag, als jij met een NL IP aankomt (want dat is Exempt-ed van NAT) kan het best zijn dat de ASA je daarop aftikt. Jouw NL netwerk moet dus ook in de ACL staan die het 192-netwerk afschermt.

Post anders eens een sh run, want dan zien we de hele configuratie die ingesteld staat en niet alleen bits en pieces

[ Voor 5% gewijzigd door mbaltus op 13-12-2012 15:15 ]

[Snors]

mbaltus schreef op donderdag 13 december 2012 @ 15:09:
Het lijkt er nu op alsof je een aparte VPN tunnel wilt opzetten naar dat netwerk, maar volgens mij moet je de 192 reeks toevoegen aan de destination van de peer naar de US. Daardoor wordt dat verkeer over dezelfde tunnel naar de US gestuurd en kan de ASA aan de andere kant het verkeer de juiste kant op routeren.

Of begrijp ik je vraag niet goed? Het 192 netwerk ligt toch achter de ASA in de US waar ook de andere systemen staan (dus als aparte DMZ zone of gerouteerd door een ander device)?


[...]

Dat zegt alleen maar dat je vanaf de US naar dat netwerk mag, als jij met een NL IP aankomt (want dat is Exempt-ed van NAT) kan het best zijn dat de ASA je daarop aftikt. Jouw NL netwerk moet dus ook in de ACL staan die het 192-netwerk afschermt.

Post anders eens een sh run, want dan zien we de hele configuratie die ingesteld staat en niet alleen bits en pieces

Ik kan het zelf niet beter voorwoorden dat is wat ik probeer in te stellen! Dus geen 2de VPN Tunnel! Moet ik een Network Object Group aanmaken bij Rule 1 van de IPSec Rules en daar zowel het 10.0.0.0 netwerken in stoppen en het nieuwe 192.168.8.0 netwerk?

USA heeft mij laten weten dat het aan hun kant goed staat. We kunnen dat pas met zekerheid zeggen als ook de instellingen hier in Nederland goed staan in de ASA5510.

Super bedankt!

[ Voor 10% gewijzigd door Snors op 13-12-2012 15:31 ]

[mbaltus]

Volgens mij kun je 'm (ff uit mn hoofd) gewoon als destination erbij toevoegen zonder een netwerk object group aan te maken. Vziw moet aan de USA kant ook dat netwerk toegevoegd worden (dan als source), anders wordt het verkeer terug niet getunneld.

[Snors]

mbaltus schreef op donderdag 13 december 2012 @ 15:39:
Volgens mij kun je 'm (ff uit mn hoofd) gewoon als destination erbij toevoegen zonder een netwerk object group aan te maken. Vziw moet aan de USA kant ook dat netwerk toegevoegd worden (dan als source), anders wordt het verkeer terug niet getunneld.

Dat lukt dus helaas niet zie ook:


Ik heb ook een export gemaakt van de config. Ik post hem niet hier als code maar heb hem geupload:
**REMOVED** zie 2de pagina.

[ Voor 3% gewijzigd door Snors op 14-12-2012 15:29 ]

[mbaltus]

Volgens mij moet je aan het volgende deel:

code:

access-list outside_20_cryptomap remark Corp VPN
access-list outside_20_cryptomap extended permit ip 10.24.0.0 255.255.0.0 10.0.0.0 255.252.0.0

toevoegen (dus niet vervangen!)

code:

access-list outside_20_cryptomap extended permit ip 10.24.0.0 255.255.0.0 192.168.8.0 255.255.255.0

Daarmee wordt dat netwerk "interessant" voor je VPN tunnel naar de US.

Garantie tot aan de deur, dus pas op met testen hiermee.

edit:

toevoeging!

Hmm, er nog even naar kijkend, zie ik verschillende VPN profielen richting de US. ff de juiste opsnorren.....

[ Voor 16% gewijzigd door mbaltus op 13-12-2012 16:00 ]

[Snors]

mbaltus schreef op donderdag 13 december 2012 @ 15:54:
Volgens mij moet je aan het volgende deel:

code:

access-list outside_20_cryptomap remark Corp VPN
access-list outside_20_cryptomap extended permit ip 10.24.0.0 255.255.0.0 10.0.0.0 255.252.0.0

toevoegen (dus niet vervangen!)

code:

access-list outside_20_cryptomap extended permit ip 10.24.0.0 255.255.0.0 192.168.8.0 255.255.255.0

Daarmee wordt dat netwerk "interessant" voor je VPN tunnel naar de US.

Garantie tot aan de deur, dus pas op met testen hiermee.

edit:

toevoeging!

Hmm, er nog even naar kijkend, zie ik verschillende VPN profielen richting de US. ff de juiste opsnorren.....

Ik ben er toch altijd wat voorzichtig mee. Vandaar dat ik het liever via de ASDM aanpas dan de CLI. Enig idee waar deze optie verstopt zit in de ASDM? En nogmaals super bedankt voor het meedenken!

[mbaltus]

heb helaas hier even geen ADSM beschikbaar. Dat moet ik dus later even opzoeken.

[Snors]

mbaltus schreef op donderdag 13 december 2012 @ 16:07:
heb helaas hier even geen ADSM beschikbaar. Dat moet ik dus later even opzoeken.

Top, ik hoor het graag volgens mij zat ik al bij het goede deel te kijken namelijk de IPSec Rules. Daar staat ook netjes de Corp VPN als description aangegeven en:

Het gaat dus om de eerste Rule.

De Destination kan ik dus enkel 1 IP Address(netwerk) opgeven of een Network Group Object:


Is het dan toch niet zo dat ik een Network Group Object met de 2 netwerken:
10.0.0.0 / 255.252.0.0
192.168.8.0 / 255.255.255.0
Aan moet maken en vervolgens deze als Destination moet kiezen bij Rule 1 van de IPSec rules?

[mbaltus]

Het kan inderdaad zijn dat het met een Netwerk Object Group lukt. Volgens mij kon je in eerdere versies van ASDM extra adressen opgeven zonder N.O.G, maar dat heb ik niet meer helder op mn netvlies.

[Snors]

mbaltus schreef op donderdag 13 december 2012 @ 16:34:
Het kan inderdaad zijn dat het met een Netwerk Object Group lukt. Volgens mij kon je in eerdere versies van ASDM extra adressen opgeven zonder N.O.G, maar dat heb ik niet meer helder op mn netvlies.

Heb ik nu gedaan. Nogsteeds hetzelfde resultaat met Packet Tracer


Echter zie ik alleen dat die een inside -> outside NAT aanmaakt met de network group en de outside_20_cryptomap niet aanpast:

code:

access-list outside_20_cryptomap extended permit ip 10.24.0.0 255.255.0.0 10.0.0.0 255.252.0.0 
access-list inside_nat0_outbound extended permit ip 10.24.0.0 255.255.0.0 object-group CorpVPNRanges

Ik heb trouwens ook in de NAT Exempt de CorpVPNRanges group gebruikt op de rule die al bestond.

[Snors]

Toch nog even een update van mijn kant. Om het verhaal wat duidelijker te maken zal ik uitleggen hoe de route moet verlopen:
ASA5510 Nederland -> ASA5510 USA -> Cisco 4506 Gateway op destination locatie

Er is een VPN verbinding aanwezig tussen ASA5510 Nederland en ASA5510 USA. In de ASA5510 USA is enkel een Static route aangemaakt:
Interface: Inside
IP Address: 192.168.8.0/24
Netmask: 255.255.255.0
Gateway: 10.1.7.4(Cisco 4506 op destination locatie)
Metric/Distance: 1
Options: None

Vreemde is dat als ik de ping tool gebruik in de ASA5510 USA ik netjes het adres 192.168.8.1 kan pingen. Als ik de Packet Tracer gebruik dan krijg ik een ACL Drop:

code:

Config

nat (inside) 1 0.0.0.0 0.0.0.0 
nat-control 
match ip inside any inside any 
dynamic translation to pool 1 (No matching global) 
translate_hits = 1281539, untranslate_hits = 0

(acl-drop) Flow is denied by configured rule

Dit gebeurd zowel als ik een 10.24.0.1(Lokaal IP Nederland) adres als source gebruik maar ook als ik een 10.1.7.10(Lokaal IP Amerika) gebruik. Destination gebruik ik 192.168.8.1.

Ik denk dat op dit moment de ASA5510 in Nederland goed geconfigureerd heb staan maar dat het verkeer tegen wordt gehouden in de ASA5510 in Amerika omdat hier enkel een Static Route is geconfigureerd en verder geen ACL. Is deze constatering juist? Klopt het dat als ik een IP ACL maak in de ASA5510 Amerika met als Source het lokale netwerk in Nederland en als destination het netwerk achter de Cisco 4506(nieuwe 192.168.8.0 netwerk) het zou moeten werken?

Thanks!

[mhofstra]

Ik ben niet bekend met ASDM 5.x (gebruik zelf ASDM 6.x icm ASA 8.2.x) maar als je nu een ping opstart vanuit NL naar de nieuwe range in de US, vervolgs bij Monitor->VPN->Sessions kijkt en vervolgens op de details bij de VPN naar de US, zie je dan dat de nieuwe range er ook tussen staat? Zoja, dan weet je dat het aan jou kant goed gaat....

[mhofstra]

In je config zie ik niet de regel "no sysopt connection permit-vpn", dit betekend dat verkeer wat via een VPN verbinding loopt niet via een access list hoeft (wordt altijd geallowed). Je zou even kunnen kijken of deze regel ook ontbreekt aan de US kant, zoja dan hoef je alleen maar een NAT exempt regel voor het verkeer aan beide zijden toe te voegen (wat je al hebt).

(Zie http://www.cisco.com/en/U...ence/s8_72.html#wp1198155 )

[mhofstra]

M34nM4chin3 schreef op donderdag 13 december 2012 @ 16:45:
[...]
Echter zie ik alleen dat die een inside -> outside NAT aanmaakt met de network group en de outside_20_cryptomap niet aanpast:

code:

access-list outside_20_cryptomap extended permit ip 10.24.0.0 255.255.0.0 10.0.0.0 255.252.0.0 
access-list inside_nat0_outbound extended permit ip 10.24.0.0 255.255.0.0 object-group CorpVPNRanges

Die access list genaampt outside_20_cryptomap wordt waarschijnlijk niet meer gebruikt, zoek de regel met "crypto map outside_map 20 match address outside_20_cryptomap" maar eens op (waarschijnlijk is het cursieve gedeelte vervangen door je object-group).

[Snors]

mhofstra schreef op vrijdag 14 december 2012 @ 11:38:
Ik ben niet bekend met ASDM 5.x (gebruik zelf ASDM 6.x icm ASA 8.2.x) maar als je nu een ping opstart vanuit NL naar de nieuwe range in de US, vervolgs bij Monitor->VPN->Sessions kijkt en vervolgens op de details bij de VPN naar de US, zie je dan dat de nieuwe range er ook tussen staat? Zoja, dan weet je dat het aan jou kant goed gaat....

Via Monitoring krijg ik alleen IPSec Tunnels = 1. No matter welke ping ik uitvoer. De rest blijft allemaal op 0 staan.
Om mijn bovenstaande verhaal nog een aanvulling te geven. De management interface van de Cisco 4506 is te bereiken via 10.1.7.4(management interface) ook vanuit Nederland. Het netwerk wat hier achter hangt is het nieuwe 192.168.8.0 netwerk. Het gaat hier gewoon om een simpele switch die de fiber connectie tussen de de ASA5510 en het nieuwe gebouw regelt. Alles wordt hier doorgegeven en niks wordt geblokkeerd dus kan me ook niet voorstellen dat het hier fout gaat.

mhofstra schreef op vrijdag 14 december 2012 @ 11:49:
[...]


Die access list genaampt outside_20_cryptomap wordt waarschijnlijk niet meer gebruikt, zoek de regel met "crypto map outside_map 20 match address outside_20_cryptomap" maar eens op (waarschijnlijk is het cursieve gedeelte vervangen door je object-group).

In de ASA5510 Nederland zie ik het volgende staan:

code:

crypto map outside_map 20 match address outside_20_cryptomap

Iemand nog suggesties? Wellicht dat er toch nog iets toegevoegd moet worden in de ASA5510 van Amerika?

[ Voor 18% gewijzigd door Snors op 14-12-2012 12:10 ]

[mhofstra]

Als je van beide ASA's de complete configs kunt posten dan moet er achter te komen zijn wat er mis gaat....

[Snors]

mhofstra schreef op vrijdag 14 december 2012 @ 12:10:
Als je van beide ASA's de complete configs kunt posten dan moet er achter te komen zijn wat er mis gaat....

Ga ik doen. De privacy gevoelige data ga ik er nu even uit filteren.
CONFIGS KOMEN HIERONDER:
ASA5510 NL: **REMOVED**
ASA5510 USA: **REMOVED**

[ Voor 8% gewijzigd door Snors op 18-12-2012 10:39 ]

[mbaltus]

In je config staat een aparte VPN config voor de reeks 192.168.8.0/24. Misschien dat je daarom die reeks niet toe kunt voegen aan de bestaande VPN config richting de US.

Het gaat om:

code:

access-list outside_cryptomap_1 extended permit ip 10.24.0.0 255.255.0.0 192.168.8.0 255.255.255.0 
...
crypto map outside_map 30 match address outside_cryptomap_1
crypto map outside_map 30 set pfs 
crypto map outside_map 30 set peer **Public IP ASA5510 USA**
crypto map outside_map 30 set transform-set ESP-3DES-SHA
crypto map outside_map 30 set phase1-mode aggressive

Ik zou dat eerst even opruimen zodat het zeker niet in de weg zit. En dan nog eens proberen op basis van een netwerk object group zowel de 10-reeks als het 192-netwerk toe te voegen aan je VPN config.

[ Voor 9% gewijzigd door mbaltus op 14-12-2012 13:06 ]

[Snors]

mbaltus schreef op vrijdag 14 december 2012 @ 13:04:
In je config staat een aparte VPN config voor de reeks 192.168.8.0/24. Misschien dat je daarom die reeks niet toe kunt voegen aan de bestaande VPN config richting de US.

Het gaat om:

code:

access-list outside_cryptomap_1 extended permit ip 10.24.0.0 255.255.0.0 192.168.8.0 255.255.255.0 
...
crypto map outside_map 30 match address outside_cryptomap_1
crypto map outside_map 30 set pfs 
crypto map outside_map 30 set peer **Public IP ASA5510 USA**
crypto map outside_map 30 set transform-set ESP-3DES-SHA
crypto map outside_map 30 set phase1-mode aggressive

Ik zou dat eerst even opruimen zodat het zeker niet in de weg zit. En dan nog eens proberen op basis van een netwerk object group zowel de 10-reeks als het 192-netwerk toe te voegen aan je VPN config.

In onze Cisco 1811 in Nederland van KPN zie ik wel het volgende geconfigureerd staan:

code:

interface Vlan1
 ip address pool IAS
 ip access-group 99 out
 ip verify unicast reverse-path
 ip tcp adjust-mss 1452
 load-interval 30

access-list 99 deny   10.0.0.0 0.255.255.255
access-list 99 deny   172.16.0.0 0.15.255.255
access-list 99 deny   192.168.0.0 0.0.255.255
access-list 99 permit any

Nou refereert de FastEthernet poort waar de ASA5510 op zit aangesloten niet naar de Vlan1 maar kan dit het probleem zijn? Overigens heb ik de crypto map outside_map 30 verwijderd maar nog steeds hetzelfde resultaat

De inet verbinding loopt bij ons dus als volgt:
Fiber modem KPN -> Cisco 1811 KPN -> ASA5510 NL

[ Voor 6% gewijzigd door Snors op 14-12-2012 13:32 ]

[mbaltus]

De Cisco 1811 is niet je probleem, voor die tijd is het verkeer al in de tunnel gestopt en niet zichtbaar voor de router.
Ik blijf er nog steeds bij dat je ervoor moet zorgen dat je de 192.168.8.0-reeks als interessant verkeer voor je VPN tunnel instelt. Dan wordt het via de tunnel naar de US gestuurd. Daarnaast is het ook wel nuttig om even de config van de US fw te zien om te kijken of daar alles goed staat, maar dat is stap 2. Eerst moet je ervoor zorgen dat het verkeer de tunnel in gaat.

[Snors]

mbaltus schreef op vrijdag 14 december 2012 @ 13:38:
De Cisco 1811 is niet je probleem, voor die tijd is het verkeer al in de tunnel gestopt en niet zichtbaar voor de router.
Ik blijf er nog steeds bij dat je ervoor moet zorgen dat je de 192.168.8.0-reeks als interessant verkeer voor je VPN tunnel instelt. Dan wordt het via de tunnel naar de US gestuurd. Daarnaast is het ook wel nuttig om even de config van de US fw te zien om te kijken of daar alles goed staat, maar dat is stap 2. Eerst moet je ervoor zorgen dat het verkeer de tunnel in gaat.

Mee eens maar hoe controleer ik dat? Als ik logging aan zet staat er alleen dat de tunnel established is en niet dat het verkeer ook daadwerkelijk de tunnel in gaat. Of moet dit aan de hand van Packet Tracer duidelijk worden? We hebben trouwens GEEN dedicated lijn van NL naar de USA de VPN loopt gewoon over het publieke IP adres van beide locaties. Response tijden zijn ook niet super maar het is werkbaar. Dus in theorie zou die volgens mij WEL door de Cisco 1811 gaan anders komt het verkeer niet bij KPN terecht.

[ Voor 14% gewijzigd door Snors op 14-12-2012 13:42 ]

[mhofstra]

Als ik in een ASA met 8.2+ASDM6.2 kijk bij de VPN session monitoring dan zie ik dat ie per object van je ObjectGroup een IPsec tunnen opbouwt, als dat gebeurt weet je zeker dat je het goed ingesteld staat. De VPN configuratie aan de andere kant moet echter exact hetzelfde zijn (zelfde objecten in de ObjectGroup), anders heb je kans dat de tunnel niet eens opgebouwd wordt. Als je daarna nog geen verkeer terug krijgt kun je verder zoeken in access-lists en static routes in de ASA in de US.

[ Voor 7% gewijzigd door mhofstra op 14-12-2012 13:54 ]

[mbaltus]

De Packet Tracer zou je (op basis van de config) laten zien of het lukt. Maar als ik de laatste config bekijk, zie ik nog steeds alleen de US als "interessant" verkeer voor de VPN:

code:

access-list outside_20_cryptomap extended permit ip 10.24.0.0 255.255.0.0 10.0.0.0 255.252.0.0

zolang daar niet de 192-reeks aan toegevoegd wordt, zal de ASA het verkeer nooit de tunnel insturen.

Als je het via ASDM met een netwerk object group niet voor elkaar krijgt
(effe opnieuw proberen nu je de outside_30_cryptomap hebt opgeschoond, want hiervoor wilde de ASA wellicht je commando niet doorvoeren omdat de 192-reeks al aan een andere VPN profiel was geknoopt!)

dan wellicht toch via de command line.
Als je bang bent dat je de config. verprutst, dan zorg je ervoor dat je vooraf gesaved heb, dan de aanpassing doet en als het niet werkt is een reboot voldoende om terug te zijn bij de gesavede config. Wel even in een service window doen dus.

code:

no access-list outside_20_cryptomap
access-list outside_20_cryptomap remark Corp VPN
access-list outside_20_cryptomap extended permit ip 10.24.0.0 255.255.0.0 10.0.0.0 255.252.0.0 
access-list outside_20_cryptomap extended permit ip 10.24.0.0 255.255.0.0 192.168.0 255.255.255.0

(of desgewenst met een netwerk object group)

code:

object-group network US_CorpVPN
 network-object 10.0.0.0 255.252.0.0
 network-object 192.168.0 255.255.255.0

no access-list outside_20_cryptomap
access-list outside_20_cryptomap remark Corp VPN
access-list outside_20_cryptomap extended permit ip 10.24.0.0 255.255.0.0 object-group US_CorpVPN

Belangrijk is dat aan de US kant de beide adresreeksen als source zijn toegevoegd!
Let op dat je tunnel niet breekt door aanpassingen te doen aan de VPN!

[ Voor 4% gewijzigd door mbaltus op 14-12-2012 13:58 . Reden: Toevoeging ]

[Snors]

mbaltus schreef op vrijdag 14 december 2012 @ 13:56:
De Packet Tracer zou je (op basis van de config) laten zien of het lukt. Maar als ik de laatste config bekijk, zie ik nog steeds alleen de US als "interessant" verkeer voor de VPN:

code:

access-list outside_20_cryptomap extended permit ip 10.24.0.0 255.255.0.0 10.0.0.0 255.252.0.0

zolang daar niet de 192-reeks aan toegevoegd wordt, zal de ASA het verkeer nooit de tunnel insturen.

Als je het via ASDM met een netwerk object group niet voor elkaar krijgt
(effe opnieuw proberen nu je de outside_30_cryptomap hebt opgeschoond, want hiervoor wilde de ASA wellicht je commando niet doorvoeren omdat de 192-reeks al aan een andere VPN profiel was geknoopt!)

dan wellicht toch via de command line......(ingekort)

Lijkt nu aangepast:

code:

object-group network CorpVPNRanges
 description Corporate IP Ranges
 network-object 10.0.0.0 255.252.0.0
 network-object 192.168.8.0 255.255.255.0
access-list outside_20_cryptomap remark Corp VPN
access-list outside_20_cryptomap extended permit ip 10.24.0.0 255.255.0.0 object-group CorpVPNRanges 
access-list inside_nat0_outbound extended permit ip 10.24.0.0 255.255.0.0 object-group CorpVPNRanges

Volgens Packet Tracer gaat het nog steeds niet de tunnel in. Hij failed wederom bij VPN.
Als ik de logging functie open en de debug logs selecteer en deze filter op 192.168.8.1 krijg ik het volgende:


Waarom geeft hij hier het IP als Source aan en niet de Destination? De Source zou toch mijn workstation 10.24 IP moeten zijn?

[ Voor 32% gewijzigd door Snors op 14-12-2012 14:22 ]

[mbaltus]

Wat doet de volgende regel nog in je config?

code:

ip local pool RemoteVPNUSAIPPool 192.168.8.1-192.168.8.254 mask 255.255.255.0

Dat is normaliter om een IP pool aan te maken voor Remote Access VPNs

Kun je verder even een screenshot posten van de packet tracer?
Heb je nog een ACL om het VPN verkeer verder af te schermen?

[Snors]

mbaltus schreef op vrijdag 14 december 2012 @ 14:22:
Wat doet de volgende regel nog in je config?

code:

ip local pool RemoteVPNUSAIPPool 192.168.8.1-192.168.8.254 mask 255.255.255.0

Dat is normaliter om een IP pool aan te maken voor Remote Access VPNs

Kun je verder even een screenshot posten van de packet tracer?
Heb je nog een ACL om het VPN verkeer verder af te schermen?

Screenshot packet-tracer:


Screenshot debug logs:


Ik denk dat we een stap verder zijn. Het gaat de tunnel in als ik een ping via de ASDM zelf doe(zie de 14:14 lines). De 14:17 lines zijn vanaf mijn workstation en daar blocked hij ze. Wellicht toch nog een ACL issue daar kijk ik nu naar. Vind het wel vreemd dat hij 192.168.8.1 in de debug logs als Source ziet...

Ik heb alle oude JUNK zojuist uit de ASA5510 verwijderd. Dat krijg je als er vaak van funcites wordt gewisseld binnen een bedrijf.. Oude VPN connecties ETC. is nu allemaal schoon. Zo zijn ook alle IP Pools verwijderd.

Enig idee wat er bij de ACL nog fout zou kunnen staan? Er is bijvoorbeeld al een 10.24 -> Any IP Rule en zo is er ook op de outside interface een echo-reply rule om die te accepten(als ik tweakers.net ping krijg ik netjes een reply terug).

EDIT: Mijn constatering bleek niet helemaal waar. Ik kan toch niet afleiden aan de hand van de debug log of die nou wel of niet in de VPN tunnel gaat. Ik dacth dat hij het publiek IP van de ASA5510 in de USA liet zien maar de doorgekrasde IP Nummers zijn de IP nummers van de ASA5510 in NL(logisch want ik probeerde het 192.168.8.1 te pingen via de outside interface onder het mom wie niet waagt die niet wint lol)..

En hieronder de ge-updated config:
ASA5510 NL: http://g2f.nl/00lrw23

[ Voor 24% gewijzigd door Snors op 14-12-2012 15:10 ]

[mbaltus]

Wat staat er onder het '+' bij de VPN regel in de packet trace? nog extra informatie wellicht (bijvoorbeeld welke ACL de drop veroorzaakt)?

edit:
Toevoeging

Staat de 192-reeks aan de US kant ook als source? Anders maakt deze volgens mij geen deel uit van de volledige VPN tunnel en kan er nog steeds geen verkeer overheen.

[ Voor 41% gewijzigd door mbaltus op 14-12-2012 15:30 ]

[Snors]

mbaltus schreef op vrijdag 14 december 2012 @ 15:12:
Wat staat er onder het '+' bij de VPN regel in de packet trace? nog extra informatie wellicht (bijvoorbeeld welke ACL de drop veroorzaakt)?

Nee dat is ook het probleem en daarom ben ik ook zo lang aan het k*tten met dit probleem... Als ik nou wist waar het fout ging maar het lijkt wel alsof we hier met een Microsoft product bezig zijn lol..

Zie onderstaande screenshot:

[mbaltus]

Weet je zeker dat aan de US kant beide netwerken als source zijn gedefinieerd in de VPN tunnel naar jouw netwerk toe? Jouw config ziet er nu prima uit, dus het lijkt me dat het zou moeten werken

[Snors]

mbaltus schreef op zaterdag 15 december 2012 @ 09:39:
Weet je zeker dat aan de US kant beide netwerken als source zijn gedefinieerd in de VPN tunnel naar jouw netwerk toe? Jouw config ziet er nu prima uit, dus het lijkt me dat het zou moeten werken

Welke rules moeten er daar aangemaakt worden? Het enige wat ik zie in die firewall is een static route van het 10.0.0.0/16 netwerk naar 192.168.8.0/24 netwerk. Niets meer en niets minder. Moet er nog een ACL worden geconfigureerd? NAT Exempt? Zoals gezegd kan ik met enkel de static route vanaf een server in Amerika het 192.168.8.0 netwerk bereiken.

Thanks!

[mbaltus]

In de US moet sowieso een NAT exempt naar jouw netwerk staan en daarnaast moet in de VPN config als source ook het 192-netwerk. Anders wordt verkeer vanaf dat netwerk niet de tunnel ingestuurd. Dit is gelijk als je gedaan hebt met de destination kant (door gebruik te maken van een netwerk object group), maar dat moet dan aan de andere kant als source.

[Snors]

mbaltus schreef op maandag 17 december 2012 @ 11:48:
In de US moet sowieso een NAT exempt naar jouw netwerk staan en daarnaast moet in de VPN config als source ook het 192-netwerk. Anders wordt verkeer vanaf dat netwerk niet de tunnel ingestuurd. Dit is gelijk als je gedaan hebt met de destination kant (door gebruik te maken van een netwerk object group), maar dat moet dan aan de andere kant als source.

Er bestaat al een NAT Exempt met Source 10.0.0.0/14(Amerika)(geen 16 was een foutje in mijn vorige post) en Destination 10.24.0.0/16(Nederland). Ik denk dat hier niets aan veranderd hoeft te worden of moet ik ook een Network Object Group voor de Source van de NAT Exempt maken(Met het 10.0.0.0 en 192.168.8.0 netwerk)?

Verder draait op de ASA5510 in Amerika een andere ASDM versie namelijk 6.3(Degene die jij ook hebt). Klopt het dat ik bij:
Site-to-Site VPN -> Edit de VPN verbinding naar Nederland -> En dan onder Protected Networks het Local Network wijzigen naar een Network Group Object met zowel het 10.0.0.0/14 netwerk als het 192.168.8.0/24 netwerk right?

Alvast bedankt!

[_-= Erikje =-_]

Let wel dat 10.0.0.0/14 niet meer binnen RFC1918 valt....

[mhofstra]

M34nM4chin3 schreef op maandag 17 december 2012 @ 13:02:
[...]
Er bestaat al een NAT Exempt met Source 10.0.0.0/14(Amerika)(geen 16 was een foutje in mijn vorige post) en Destination 10.24.0.0/16(Nederland). Ik denk dat hier niets aan veranderd hoeft te worden of moet ik ook een Network Object Group voor de Source van de NAT Exempt maken(Met het 10.0.0.0 en 192.168.8.0 netwerk)?

Object-group voor de NAT0 hoeft niet, een 2de regel met source 192.168.8.0/255.255.255.0 en destination 10.24.0.0/255.255.0.0 is voldoende.

Verder draait op de ASA5510 in Amerika een andere ASDM versie namelijk 6.3(Degene die jij ook hebt). Klopt het dat ik bij:
Site-to-Site VPN -> Edit de VPN verbinding naar Nederland -> En dan onder Protected Networks het Local Network wijzigen naar een Network Group Object met zowel het 10.0.0.0/14 netwerk als het 192.168.8.0/24 netwerk right?

Waarschijnlijk kan je met asdm 6.x wel gewoon een adres toevoegen aan de cryptomap accesslist van de vpn tunnel, kijk maar eens bij Configuration->Site-to-Site VPN->Advanced->Crypto Maps->Dan de betreffende selecteren en vervolgens edit->Traffic selection. (waarschijnlijk wordt er dan trouwens ook een ObjectGroup van gemaakt echter doet ASDM dat dan voor je...)

Mocht je de betreffende ASA trouwens configureren via de VPN-tunnel pas dan wel op, mocht het misgaan kom je er niet meer in! (als je em gewoon benaderd via z'n outside adres is er geen 'gevaar')

[Snors]

mhofstra schreef op maandag 17 december 2012 @ 14:26:
[...]

Object-group voor de NAT0 hoeft niet, een 2de regel met source 192.168.8.0/255.255.255.0 en destination 10.24.0.0/255.255.0.0 is voldoende.


[...]

Waarschijnlijk kan je met asdm 6.x wel gewoon een adres toevoegen aan de cryptomap accesslist van de vpn tunnel, kijk maar eens bij Configuration->Site-to-Site VPN->Advanced->Crypto Maps->Dan de betreffende selecteren en vervolgens edit->Traffic selection. (waarschijnlijk wordt er dan trouwens ook een ObjectGroup van gemaakt echter doet ASDM dat dan voor je...)

Mocht je de betreffende ASA trouwens configureren via de VPN-tunnel pas dan wel op, mocht het misgaan kom je er niet meer in! (als je em gewoon benaderd via z'n outside adres is er geen 'gevaar')

Thanks ga het zo proberen. Ik benader hem idd via het outside adres :)! Nogmaals bedankt,

EDIT: AAAAAAANDDDDDDD it's working Thanks allen voor de info en hulp!

[ Voor 4% gewijzigd door Snors op 18-12-2012 10:28 ]