Now I'm a little bit lost in regard to your original question ;)
You meant to ask whether we have manually include the "ip unnumbered 
loopbackXXX" statement under the virtual-template interface ?
We confirmed that depending on the client mode the virtual-access interface 
behaves differently, namely binding different intefaces. Your point was about 
some faults that can be injected because of misconfiguration ?

Eugene
Sent from iPhone

On Jun 22, 2012, at 8:36 PM, "Imre Oszkar" 
<[email protected]<mailto:[email protected]>> wrote:

Hi Eugene,

In both cases, network-plus and client the virtual access interface will 
inherit the lo10000 ip address.

Oszkar

On Fri, Jun 22, 2012 at 1:23 PM, Eugene Pefti 
<[email protected]<mailto:[email protected]>> wrote:
That was my point, Imre,
Your client is network extension mode and according to Cisco the virtual-access 
interface doesn’t use loopback but the physical one.
Can you please try it in the client or network plus mode to confirm that it 
behaves differently. I loaded different labs to my routers.

Eugene

From: 
[email protected]<mailto:[email protected]>
 
[mailto:[email protected]<mailto:[email protected]>]
 On Behalf Of Imre Oszkar
Sent: Friday, June 22, 2012 1:08 PM
To: ccie security

Subject: Re: [OSL | CCIE_Security] DVTI IP unnumbered

Seems like my PC went crazy and sends the drafts by its own...here is the 
complete e-mail.


Hi guys!

I know this is an old post and it has been answered, but I would like to bring 
it back to discussion if you don't mind.

So we know that ip address is a requirement for EZVPN Remote for routing 
purposes which is great, but do we really need the "ip unnumbered lo0" or 
similar configured on the client virtual template?? I think the the answer 
could be very important when you need to find EZVPN injected faults in the 
config.

Here is my config:

Server:
crypto isakmp policy 10
 encr 3des
 authentication pre-share
 group 2
crypto isakmp client configuration group EZ
 key cisco
 pool remote
 acl split
 save-password
crypto isakmp profile EZ
   match identity group EZ
   client authentication list EZ
   isakmp authorization list EZ
   client configuration address respond
   virtual-template 1

crypto ipsec transform-set ESP3DES esp-3des esp-sha-hmac
crypto ipsec profile EZ_PROFILE
 set transform-set ESP3DES
 set isakmp-profile EZ

interface Virtual-Template1 type tunnel
 ip unnumbered Loopback23
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile EZ_PROFILE

ip access-list extended split
 permit ip 1.1.1.0 0.0.0.255 any

ip local pool remote 20.0.0.1 20.0.0.10


Remote:

crypto ipsec client ezvpn EZVPN
 connect manual
 group EZ key cisco
 mode network-extension
 peer 8.9.56.6
 virtual-interface 1
 username cisco password cisco
 xauth userid mode local

interface Virtual-Template1 type tunnel
 no ip address
 tunnel mode ipsec ipv4


interface FastEthernet0/0
 ip address 8.9.11.4 255.255.255.0
 crypto ipsec client ezvpn EZVPN

interface FastEthernet0/1.4
 encapsulation dot1Q 4
 ip address 192.1.49.4 255.255.255.0
 crypto ipsec client ezvpn EZVPN inside



If you take a look at the output virtual-access interface will have an IP 
address even though I didn't configure  any ip address for the virtual-template.


R4#sh crypto ipsec client ezvpn
Easy VPN Remote Phase: 6

Tunnel name : EZVPN
Inside interface list: FastEthernet0/1.4
Outside interface: Virtual-Access2 (bound to FastEthernet0/0)
Current State: IPSEC_ACTIVE
Last Event: MTU_CHANGED
Save Password: Allowed
Split Tunnel List: 1
       Address    : 1.1.1.0
       Mask       : 255.255.255.0
       Protocol   : 0x0
       Source Port: 0
       Dest Port  : 0
Current EzVPN Peer: 8.9.56.6


R4#sh interfaces virtual-access 2
Virtual-Access2 is up, line protocol is up
  Hardware is Virtual Access interface
  Interface is unnumbered. Using address of FastEthernet0/0 (8.9.11.4)
  MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL
  Tunnel vaccess, cloned from Virtual-Template1
  Vaccess status 0x44, loopback not set
  Keepalive not set
  Tunnel source 8.9.11.4 (FastEthernet0/0), destination 8.9.56.6
  Tunnel protocol/transport IPSEC/IP
  Tunnel TTL 255
  Fast tunneling enabled
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Last input never, output never, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     30 packets input, 3000 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     40 packets output, 4000 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out



R4#sh crypto session detail


Interface: Virtual-Access2
Uptime: 01:04:29
Session status: UP-ACTIVE
Peer: 8.9.56.6 port 500 fvrf: (none) ivrf: (none)
      Phase1_id: 8.9.56.6
      Desc: (none)
  IKE SA: local 8.9.11.4/500<http://8.9.11.4/500> remote 
8.9.56.6/500<http://8.9.56.6/500> Active
          Capabilities:CX connid:1002 lifetime:22:55:07
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0<http://0.0.0.0/0.0.0.0> 
0.0.0.0/0.0.0.0<http://0.0.0.0/0.0.0.0>
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 5 drop 0 life (KB/Sec) 4477477/3159
        Outbound: #pkts enc'ed 15 drop 0 life (KB/Sec) 4477477/3159


_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Are you a CCNP or CCIE and looking for a job? Check out 
www.PlatinumPlacement.com

Reply via email to