[Cisco] L2L VPN gaat NAT'en

[RoelVB]

Beste mede-Tweakers,

Ik heb een probleempje met een Cisco router i.c.m. een LAN-to-LAN IPSec verbinding.
Het probleem is dat requests die via de VPN verbinding binnenkomen geNAT worden.

Bijvoorbeeld:
Ik heb een VPN verbinding tussen LAN1: 192.168.10.0/24 en LAN2: 192.168.11.0/24.
Als ik vanaf 192.168.11.11 verbind naar 192.168.10.15 via RDP (poort 3389) wordt dit geNAT door de volgende regel:

code:

ip nat inside source static tcp 192.168.10.15 3389 <BuitenIP-1> 3315 extendable

Wanneer ik deze NAT regel verwijder kan ik wel gewoon verbinden via RDP. Ander buiten IP gebruiken in deze NAT regel blijft hetzelfde probleem geven.

Overige poorten naar 192.168.10.15 die niet in NAT regels voorkomen werken ook zonder probleem.
Aan beide zijden van de VPN verbinding staat een Cisco 871.

Hopelijk kan iemand mij hiermee helpen, ik ben namelijk zo'n half jaar geleden ook al dit probleem tegengekomen, toen laten bekijken door een Cisco expert, maar er helaas niet uitgekomen.

Running config van router op LAN1:

code:

no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname hhrouter2
!
boot-start-marker
boot-end-marker
!
logging buffered 51200 warnings
enable secret 5 <weg>
!
no aaa new-model
clock timezone GMT 1
clock summer-time GMT date Mar 30 2002 1:00 Oct 26 2035 1:59
!
dot11 syslog
ip cef
!
!
no ip domain lookup
ip domain name yourdomain.com
ip name-server 213.51.129.37
ip name-server 213.51.144.37
!
!
!
!
!
crypto isakmp policy 10
 encr aes 256
 authentication pre-share
crypto isakmp key <weg> address <IPAdres-Loc2>
!
!
crypto ipsec transform-set aes-sha-transform esp-aes 256 esp-sha-hmac
!
crypto map VPN 10 ipsec-isakmp
 set peer <IPAdres-Loc2>
 set transform-set aes-sha-transform
 match address acl_vpn
!
archive
 log config
  hidekeys
!
!
!
!
!
interface FastEthernet0
!
interface FastEthernet1
!
interface FastEthernet2
!
interface FastEthernet3
!
interface FastEthernet4
 ip address <BuitenIP-2> 255.255.255.248 secondary
 ip address <BuitenIP-3> 255.255.255.248 secondary
 ip address <BuitenIP-4> 255.255.255.248 secondary
 ip address <BuitenIP-5> 255.255.255.248 secondary
 ip address <BuitenIP-1> 255.255.255.248
 ip nat outside
 ip virtual-reassembly
 speed 100
 full-duplex
 crypto map VPN
!
interface Vlan1
 description FE0 t/m FE3
 ip address 192.168.10.2 255.255.255.0
 ip nat inside
 ip virtual-reassembly
 ip tcp adjust-mss 1452
 no ip mroute-cache
 hold-queue 32 in
!
interface Dialer1
 no ip address
 no cdp enable
!
ip default-gateway <GW-IP>
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 <GW-IP>
!
no ip http server
ip http access-class 23
ip http authentication local
ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
ip nat inside source list 101 interface FastEthernet4 overload
ip nat inside source static tcp 192.168.10.15 3389 <BuitenIP-1> 3315 extendable
!
ip access-list extended acl_vpn
 permit ip 192.168.10.0 0.0.0.255 192.168.11.0 0.0.0.255
!
access-list 23 permit 192.168.10.0 0.0.0.255
access-list 101 deny   ip 192.168.10.0 0.0.0.255 192.168.11.0 0.0.0.255
access-list 101 permit ip 192.168.10.0 0.0.0.255 any
no cdp run
!
!
!
control-plane
!
!
line con 0
 password 7 <weg>
 login
 no modem enable
line aux 0
line vty 0 4
 access-class 23 in
 privilege level 15
 password 7 <weg>
 login
 transport input telnet
!
scheduler max-task-time 5000
end

Bij voorbaat dank,
Roel

[ Voor 1% gewijzigd door RoelVB op 20-01-2010 09:15 . Reden: Had regel "ip nat inside source list 101 interface FastEthernet4 overload" per ongelijk uit config hier boven geknipt. ]

[axis]

Hmm.. ik ken alleen maar Cisco ASA's, en ik ben zo'n n00b die alles met de ASDM (gui) doet, dus ik kan je misschien niet echt helpen. Echter is het op de ASA zo dat ik eerst een nat excempt rule moet maken zodat traffic van 192.168.10.0/24 naar 192.168.11.0/24 expliciet niet genat wordt.. Misschien omdat je al een NAT rule hebt, dat je een expliciete NAT excempt rule moet maken voor je vpn..

(maar da's misschien mede omdat ik het standaard vinkje 'do not allow traffic through the device without translation' aan heb staan).

[Kabouterplop01]

Wat werkt er niet?
Wat werkt er wel?

[ Voor 168% gewijzigd door Kabouterplop01 op 20-01-2010 00:52 . Reden: onzon weg en gewoon vraag gesteld ]

[RoelVB]

Kabouterplop01 schreef op woensdag 20 januari 2010 @ 00:41:
Wat werkt er niet?
Wat werkt er wel?

Werkt niet:
Verkeer vanaf 192.168.11.0/24 naar een 192.168.10.0/24 adres over een poort die ook in een NAT translatie gebruikt wordt. Deze verschijnt tussen de actieve NAT translations.

Werkt wel:
Vekeer vanaf 192.168.11.0/24 naar een 192.168.10.0/24 adres over een poort die NIET in een NAT translatie voorkomt.

[Kabouterplop01]

ok dank! (Ik had een heel verhaal geklopt en de stelling opnieuw gelezen en zag dat ik dat nog eens op een heeel andere manier kon zien )


voor een vpn tunnel dien je eerst L3 connectivity te hebben; daarover zet je je vpn tunnel.
|192.168.10.0 vlan1---nat/----------\nat---vlan1 192.168.11.0|
------------------------------ |<--- VPN --->|-------------------------------
Het eerste waar ik acl's zou gaan zetten is op de VLAN1 interfaces.
je vpn relatie zegt nl dat je 192.168 subnetten directly connected zijn door de vpn.

anyway wat ik gek vind is acl 103 eerst blok je de range en daarna permit je die.

overigens ik zie nergens een mtu van 1492 dan kun je vlan1 tcp-adjust 1452 ook weglaten (ik zie nergens een pppoe dialer)

edit: ONZIN weggehaald oefff :S; ik zie dat ik eenzelfde setup heb... Ik gebruik alleen geen extendable en geen ip adres maar de interface.

zou zoiets worden: ip nat inside source static tcp 192.168.10.15 3389 interface FastEthernet4 3315

Bedankt @Trailblazer hieronder : Als je met het IP adres ipv de interface connection probeert te maken, zou dat kunnen dat het niet werkt, omdat de socket al "in -use" is. Is dat waar je op doelt TB?

[ Voor 35% gewijzigd door Kabouterplop01 op 20-01-2010 17:25 ]

[TrailBlazer]

Naar welk ip staat je crypto-peer vanaf lokatie 2 naar lokatie 1 is dit ook BuitenIP-1

Dat zou niet uit mogen maken want volgens deze pagina doet hij eerst decrypten en dan pas nat.
http://www.cisco.com/en/U...ote09186a0080133ddd.shtml

[ Voor 52% gewijzigd door TrailBlazer op 20-01-2010 15:45 ]

[pablo_p]

De oplossing is het gebruik van een route-map op de static Port NAT die het verkeer uit de VPN tunnel exclude van de port-nat.

Het commando hiervoor is identiek aan je huide port-nat regel, maar ipv extendable gebruikt je 'route-map R1'. En je maakt een route-map die het verkeer uit de VPN tunnel exclude en de rest expliciet permit.

Ik weet alleen niet of de 871 dit ondersteunt, eventueel afhankelijk van de software versie. Eerste test is dus: kan je een route-map opgeven achter de nat regel ( controleren met ?)

[RoelVB]

Een route-map heb ik ook al geprobeerd, helaas is dit niet de oplossing.

Heb dit probleem nog samen met iemand bekeken die meer weet van de combinatie Cisco's en VPN tunnels.
We zijn tot de conclusie gekomen dat dit een bug in deze Cisco moet zijn. (Nieuwe IOS geeft nog steeds dit probleem)

[TrailBlazer]

Deze configuratie voor VPN is trouwens niet heel erg standaard en ik zou hem liever helemaal omgooien naar een GRE oplossing.
http://www.cisco.com/en/U...ple09186a008023ce5b.shtml

Als je verkeer tussen je LAN segmenten gaat dan over GRE tunnel. Op de lange termijn is dit wat schaalbaarder. Een keer je GRE opzetten en alles wat je over je GRE tunnel routeert wordt automatisch geencrypt.

Ik heb trouwens geen idee of al die secondaries nodig zijn. Het kan best zijn dat als je een extern ip opneemt in een static nat entry dat de router er dan een arp reply voor uitstuurt op het moment dat er een request voor komt. Een PIX werkte wel zo geloof ik.

Even snel op een router geconfigureerd.

code:

ip nat inside source static  192.168.88.14 10.30.8.200

sh arp

Internet  10.30.8.79               -   0026.0a25.e240  ARPA   GigabitEthernet5/2
Internet  10.30.8.200              -   0026.0a25.e240  ARPA   GigabitEthernet5/2

Hij zal dus gewoon gaan arpen voor je. Je config met secondaries is dus niet nodig.

[ Voor 21% gewijzigd door TrailBlazer op 01-02-2010 15:08 ]

[Verwijderd]

access-list 101 deny ip 192.168.10.0 0.0.0.255 192.168.11.0 0.0.0.255

Volgens mij is die gewoon verkeerd om?

edit:

dus:
access-list 101 deny ip 192.168.11.0 0.0.0.255 192.168.10.0 0.0.0.255
en dan word het:
[code]
conf t
no access-list 101
!
access-list 101 deny ip 192.168.10.0 0.0.0.255 192.168.11.0 0.0.0.255
access-list 101 deny ip 192.168.11.0 0.0.0.255 192.168.10.0 0.0.0.255
access-list 101 permit ip 192.168.10.0 0.0.0.255 any
[/code]

[ Voor 61% gewijzigd door Verwijderd op 04-02-2010 14:22 ]

[Verwijderd]

access-list 101 deny ip 192.168.10.0 0.0.0.255 192.168.11.0 0.0.0.255

Volgens mij is die gewoon verkeerd om?

Wanneer verkeer vanaf vlan 1 (192.168.10.0) komt en gaat naar de andere kant van de VPN-tunnel (192.168.11.0) dan moet het het niet genat worden. Die access-list regel klopt dus gewoon.

Een route-map heb ik ook al geprobeerd, helaas is dit niet de oplossing.

Kun je dan de configuratie met route-map eens posten want dit zou wel de oplossing moeten zijn.

De reden dat het met de geposte configuratie niet werkt heeft in ieder geval niets met een bug te maken maar is gewoon te verklaren.

Een router werkt namelijk anders dan een ASA. Bij een ASA geef je aan de hand van match statements in een ACL en een (nat) 0 regel op welk verkeer NOOIT genat moet worden. Dus bij een ASA zal een static ook niet gebruikt worden bij verkeer over de VPN verbinding tussen deze locaties want het verkeer mag immers nooit genat worden.

Bij een router geef je echter met het commando ip nat inside source list 101 interface FastEthernet4 overload via deny regels in je access-list alleen maar op welk verkeer niet gePAT mag worden door dit commando. Dit wil echter niet zeggen dat het verkeer helemaal niet genat mag worden. verkeer kan dus gewoon via een static alsnog genat worden. Daarom moet je dus middels een route-map bij de static opgeven wanneer deze wel en niet gebruikt moet worden.

Je route-map zou er zou uit moeten zien:
route-map NONAT permit 10
match ip address 101

En dan je static:
ip nat inside source static tcp 192.168.10.15 3389 <BuitenIP-1> 3315 route-map NONAT

[Flyduck]

Je geeft aan dat route-map niet de oplossing is, maar dat is het wel. Ik heb namelijk hetzelfde gehad en dit ook opgelost via een route-map.

[RoelVB]

Graafie, hartelijk dank voor de uitleg, nu is het opeens duidelijk.

Ik heb een bedrijf dat VPN verbindingen levert (voor interfiliaal verkeer) hier naar laten kijken, maar zij melden mij dat dit een bug was in het apparaat. Aangezien het netwerk gebeuren hun core business is ben ik er vanuit gegaan dat dit inderdaad een bug in de betreffende IOS is.

Nu blijkt dus dat ze het fout hadden en dit gewoon een configuratie 'fout' is. Ik heb een route-map aan de nat regels toegevoegd en dit verhelpt inderdaad mijn probleem.

Nogmaals bedankt en alle andere in dit topic natuurlijk ook bedankt.