[c-nsp] VRF aware IPSec for remote access without xauth
Jay Nakamura
zeusdadog at gmail.com
Tue Feb 16 00:30:47 EST 2010
I have fixed this issue with TAC help. To help those that may
encounter this issue later, here is the changes,
crypto isakmp profile CustomerVPN
! Remove this line for Authentication. You have to keep authorization line.
no client authentication list CustomerVPNCliAuth
Then, I forgot to add crypto-map on the two interfaces that the
traffic actually came in on. (I was under the mistaken understanding
that you can only put crypto-map on one interface.)
On Tue, Feb 9, 2010 at 2:41 PM, Jay Nakamura <zeusdadog at gmail.com> wrote:
> I have not explained my situation very well so let me restart.
>
> VPN is client VPN, not LAN to LAN. The old style IPsec Cisco VPN
> client, not Anyconnect client.
>
> Internet access on the router is on one VRF. Network we want to
> access via VPN is on another VRF. See below config.
>
> I have gotten it to work so far where it will connect, do Xauth, and
> establish connection. You can see the VPN client IP in the routing
> table of the Customer VRF. Traffic gets sent to the VPN from the
> client but nothing from the Customer VRF comes back out to the VPN.
>
> I do want to do this without XAuth if possible. Also, I used the
> loopback interface as the destination of the VPN so it could fail over
> if one link goes down.
>
>
>
> aaa new-model
> !
> aaa authentication login CustomerVPNCliAuth local
> aaa authorization network CustomerVPNNetAuth local
> !
> ip cef
> !
> ip vrf Customer
> rd 12345:1100
> import map internetVRFDefaultMap
> route-target export 12345:1100
> route-target import 12345:1100
> route-target import 12345:1
> !
> ip vrf internet
> rd 12345:1
> route-target export 12345:1
> route-target import 12345:1
> !
> crypto keyring CustomerVPNKey vrf internet
> local-address Loopback1
> pre-shared-key address 0.0.0.0 0.0.0.0 key testtest
> no crypto xauth Loopback1
> !
> crypto isakmp policy 1
> encr aes 256
> authentication pre-share
> group 2
> !
> crypto isakmp client configuration group CustomerVPNGroup
> key testtest
> pool CustomerVPNPool
> acl CustomerVPNSplitTunnel
> crypto isakmp profile CustomerVPN
> vrf Customer
> keyring CustomerVPNKey
> self-identity address
> match identity group CustomerVPNGroup
> client authentication list CustomerVPNCliAuth
> isakmp authorization list CustomerVPNNetAuth
> client configuration address initiate
> client configuration address respond
> client configuration group CustomerVPNGroup
> local-address Loopback1
> !
> !
> crypto ipsec transform-set AES256 esp-aes 256 esp-sha-hmac
> !
> crypto dynamic-map CustomerVPNDynMap 1
> set transform-set AES256
> set isakmp-profile CustomerVPN
> reverse-route
> !
> !
> crypto map CustomerVPN local-address Loopback1
> crypto map CustomerVPN 10 ipsec-isakmp dynamic CustomerVPNDynMap
> !
> !
> !
> !
> !
> !
> interface Loopback0
> ip vrf forwarding internet
> ip address a.a.a.1 255.255.255.255
> !
> !
> interface Loopback1
> ip vrf forwarding internet
> ip address a.a.a.2 255.255.255.255
> crypto map CustomerVPN
> !
> !
> interface Loopback2
> ip vrf forwarding internet
> ip address a.a.a.3 255.255.255.255
> ip nat outside
> ip virtual-reassembly
> !
> !
> interface GigabitEthernet0/0
> ip address m.m.m.x 255.255.255.0
> duplex auto
> speed auto
> !
> !
> interface GigabitEthernet0/0.802
> encapsulation dot1Q 802
> ip vrf forwarding internet
> ip address b.b.b.b 255.255.255.240
> ip nat outside
> ip virtual-reassembly
> !
> interface GigabitEthernet0/1
> no ip address
> duplex auto
> speed auto
> !
> !
> interface GigabitEthernet0/1.803
> encapsulation dot1Q 803
> ip vrf forwarding internet
> ip address c.c.c.c 255.255.255.240
> ip nat outside
> ip virtual-reassembly
> ip ospf cost 15
> !
> interface GigabitEthernet0/1.811
> encapsulation dot1Q 811
> ip address n.n.n.n.x 255.255.255.0
> !
> interface GigabitEthernet0/2
> no ip address
> duplex auto
> speed auto
> !
> !
> interface GigabitEthernet0/2.1100
> encapsulation dot1Q 1100
> ip vrf forwarding Customer
> ip address 10.0.244.1 255.255.255.0
> ip nat inside
> ip virtual-reassembly
> !
> interface GigabitEthernet0/2.1101
> encapsulation dot1Q 1101
> ip vrf forwarding Customer
> ip address 10.0.245.1 255.255.255.0
> ip nat inside
> ip virtual-reassembly
> !
> router ospf 1 vrf internet
> log-adjacency-changes
> redistribute static metric-type 1 subnets
> passive-interface default
> no passive-interface GigabitEthernet0/0.802
> no passive-interface GigabitEthernet0/1.803
> network a.a.a.1 0.0.0.0 area 0
> network b.b.b.b 0.0.0.15 area 0
> network c.c.c.c 0.0.0.15 area 0
> !
> router bgp 12345
> no synchronization
> bgp log-neighbor-changes
> no auto-summary
> !
> address-family ipv4 vrf Customer
> no synchronization
> redistribute static
> default-information originate
> exit-address-family
> !
> address-family ipv4 vrf internet
> no synchronization
> redistribute ospf 1 vrf internet match internal external 1 external 2
> default-information originate
> exit-address-family
> !
> ip local pool CustomerVPNPool 192.168.254.1 192.168.254.254 recycle delay 10
> ip forward-protocol nd
> !
> ip extcommunity-list 1 permit rt 12345:1
> ip nat inside source list CustomerNATACL interface Loopback2 vrf
> Customer overload
> !
> ip access-list extended CustomerNATACL
> deny ip 10.0.244.0 0.0.1.255 192.168.254.0 0.0.0.255
> permit ip 10.0.244.0 0.0.1.255 any
> ip access-list extended CustomerVPNSplitTunnel
> permit ip 10.0.244.0 0.0.0.255 192.168.254.0 0.0.0.255
> permit ip 10.0.245.0 0.0.0.255 192.168.254.0 0.0.0.255
> !
> !
> ip prefix-list DefaultOnly seq 5 permit 0.0.0.0/0
> ip prefix-list DefaultOnly seq 10 permit 192.168.254.0/24
> !
> route-map internetVRFDefaultMap permit 10
> match ip address prefix-list DefaultOnly
> match extcommunity 1
>
>
>
> On Wed, Feb 3, 2010 at 4:01 PM, Ryan Goldberg <RGoldberg at compudyne.net> wrote:
>>> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
>>> bounces at puck.nether.net] On Behalf Of Jay Nakamura
>>> Sent: Tuesday, February 02, 2010 10:20 PM
>>> To: cisco-nsp
>>> Subject: [c-nsp] VRF aware IPSec for remote access without xauth
>>>
>>> I am trying to configure vrf aware IPSec VPN for remote access, coming
>>> into one VRF and tunneling into another VRF. Can I do that without
>>> XAUTH? I can't seem to find any reference to doing it without xauth.
>>> If it's possible and someone has done this, can you please post a
>>> sample config?
>>
>> I believe the following tidbits should get you going. This is from an 2801 running 12.4.24T1. Tunnels lands on vrf ISP2 and pops out into vrf LAN.
>>
>> ip vrf ISP2
>> rd 1:2
>>
>> ip vrf LAN
>> rd 1:3
>>
>> crypto keyring ISP2 vrf ISP2
>> pre-shared-key address a.b.c.d key blahblahblah
>>
>> crypto isakmp policy 2
>> encr 3des
>> authentication pre-share
>> group 2
>>
>> crypto isakmp profile ProfileForNuttyVendor
>> vrf LAN
>> keyring ISP2
>> match identity address a.b.c.d 255.255.255.255 ISP2
>>
>> crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
>>
>> crypto map AwesomeMap 3 ipsec-isakmp
>> description tunnel for Nutty Vendor
>> set peer a.b.c.d
>> set transform-set ESP-3DES-SHA
>> set isakmp-profile ProfileForNuttyVendor
>> match address 111
>> reverse-route
>>
>> interface FastEthernet0/1
>> ip vrf forwarding LAN
>> ip address 10.1.19.250 255.255.255.0
>>
>> nterface FastEthernet0/0
>> ip vrf forwarding ISP2
>> ip address w.x.y.z 255.255.255.248
>>
>>
>> access-list 111 remark Nutty Vendor tunnel
>> access-list 111 permit ip host 10.3.19.247 10.0.1.0 0.0.0.255
>>
>> -
>>
>> Ryan
>>
>
More information about the cisco-nsp
mailing list