EzVPN Remote using DVTI

Dears,
I am trying to configure a very basic example on EzVPN remote using R1 as EzVPN Server and R2 as EzVPN remote but using DVTI interface on both.
My issue is that both pings from e0/0 and lo0 from R2 to 150.1.1.1 are using the VPN received IP address.

Here is my setup:
[Lo0]R1[E0/0]----[E0/0]R2[Lo0]
External subnet is 192.168.1.0/24 where 1.1 and 1.2 are IP addresses on R1 and R2 respectively. Moreover, loopback interfaces are 150.1.1.1/24 and 150.1.2.2 on R1 and R2 respectively.

Here are my configs:

R1:
aaa new-model
!
aaa authentication login default none
aaa authentication login authc local
aaa authorization network authz local
!
ip local pool pool 192.1.1.1 192.1.1.10
access-list 101 permit ip host 150.1.1.1 host 150.1.2.2
!
crypto isakmp policy 1
 encr 3des
 hash md5
 authentication pre-share
 group 2
crypto isakmp client configuration group ezvpn
 key cisco
 pool pool
 acl 101
 save-password
crypto isakmp profile myprof
   match identity group ezvpn
   client authentication list authc
   isakmp authorization list authz
   client configuration address respond
   client configuration group ezvpn
   virtual-template 1
crypto ipsec transform-set myset esp-3des esp-md5-hmac
 mode tunnel
crypto ipsec profile myprof
 set transform-set myset
 set isakmp-profile myprof
!
int e0/0
 ip address 192.168.1.1 255.255.255.0
int lo0
 ip add 150.1.1.1 255.255.255.0
interface Virtual-Template1 type tunnel
 ip unnumbered Ethernet0/0
 tunnel source Ethernet0/0
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile myprof
ip route 0.0.0.0 0.0.0.0 192.168.1.2

R2:
crypto ipsec client ezvpn ezvpn
 connect auto
 group ezvpn key cisco
 mode client
 peer 192.168.1.1
 virtual-interface 2
 username cisco password cisco
 xauth userid mode local
int lo0
 ip address 150.1.2.2 255.255.255.0
 crypto ipsec client ezvpn ezvpn inside
int e0/0
 ip address 192.168.1.2 255.255.255.0
 crypto ipsec client ezvpn ezvpn
interface Virtual-Template2 type tunnel
 ip unnumbered Loopback0
ip route 0.0.0.0 0.0.0.0 192.168.1.1

My issue is that with the above config when i ping 150.1.1.1 from R2 e0/0 and lo0, i can see that it is using the IP address received by the vpn. However, if i remove the command virtual-interface 2 from my crypto ipsec client ezvpn ezvpn config, only ping from R2's lo0 will be using the vpn received address.

R2(config-if)#do ping 150.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/5 ms
R2(config-if)#

R1(config)#
*Apr 21 22:46:19.211: ICMP: echo reply sent, src 150.1.1.1, dst 192.1.1.7, topology BASE, dscp 0 topoid 0
*Apr 21 22:46:19.216: ICMP: echo reply sent, src 150.1.1.1, dst 192.1.1.7, topology BASE, dscp 0 topoid 0
*Apr 21 22:46:19.221: ICMP: echo reply sent, src 150.1.1.1, dst 192.1.1.7, topology BASE, dscp 0 topoid 0
*Apr 21 22:46:19.225: ICMP: echo reply sent, src 150.1.1.1, dst 192.1.1.7, topology BASE, dscp 0 topoid 0
*Apr 21 22:46:19.230: ICMP: echo reply sent, src 150.1.1.1, dst 192.1.1.7, topology BASE, dscp 0 topoid 0
R1(config)#

Can someone assist me in the above issue?

Comments

  • What you see, basically all client traffic is being NAT'ed is expected, as the client/R2 runs in "client mode". If you remove the "virtual-intercace" command from the client side, the session is no longer tied to the virtual-template intercace which is the DVTI.

  • Thank you Cristian for the clarification.
    In this case, is there any option on the client side that only makes traffic from internal interface to use the vpn IP. P.S. ACL on client side did not accomplish it.

  • Only interfaces configured with " crypto ipsec client ezvpn ezvpn inside" will be allowed to send traffic through the IPsec tunnel.

  • Hi Cristian,

    You mean by your last answer when we are not using virtual-interface on the client side right?
    Suppose that i am requested to use the virtual-interface on the client side, is there any way to allow only interfaces with "crypto ipsec client ezvpn ezvpn inside" to be encrypted? I can see both inside and outside are encrypted in my configuration.

    Please advise.

  • What do you mean by "both inside and outside are encrypted"?

  • What do you mean by "both inside and outside are encrypted”?

    On 28 Apr 2015, at 20:08, moustapha <[email protected]> wrote:

    Hi Cristian,

    You mean by your last answer when we are not using virtual-interface on the client side right?
    Suppose that i am requested to use the virtual-interface on the client side, is there any way to allow only interfaces with "crypto ipsec client ezvpn ezvpn inside" to be encrypted? I can see both inside and outside are encrypted in my configuration.

    Please advise.




    INE - The Industry Leader in CCIE Preparation
    http://www.INE.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • What i mean is that traffic initiated from the client side from both interfaces outside (where applied crypto ipsec client ezvpn ezvpn) and inside (where applied crypto ipsec client ezvpn ezvpn inside) is encrypted by IPSec SAs and i can the counters incrementing by displaying the output of sh crypto ipsec sa.


  • On 28 Apr 2015, at 22:18, moustapha <[email protected]> wrote:

    What i mean is that traffic initiated from the client side from both interfaces outside (where applied crypto ipsec client ezvpn ezvpn) and inside (where applied crypto ipsec client ezvpn ezvpn inside) is encrypted by IPSec SAs and i can the counters incrementing by displaying the output of sh crypto ipsec sa.




    INE - The Industry Leader in CCIE Preparation
    http://www.INE.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • Send 100 ping packets sourced from outside and please post the output of “show crypto ipsec sa” and “show crypto session detail” before and after ping, and the running-config. I want to see if there are any changes at the SA level.


    On 28 Apr 2015, at 22:18, moustapha <[email protected]> wrote:

    What i mean is that traffic initiated from the client side from both interfaces outside (where applied crypto ipsec client ezvpn ezvpn) and inside (where applied crypto ipsec client ezvpn ezvpn inside) is encrypted by IPSec SAs and i can the counters incrementing by displaying the output of sh crypto ipsec sa.




    INE - The Industry Leader in CCIE Preparation
    http://www.INE.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • Here is the output after the tunnel came up from the client side:

    R2(config-if)#
    *Apr 29 13:32:21.188: %CRYPTO-6-EZVPN_CONNECTION_UP: (Client)  User=cisco  Group
    =ezvpn2  Server_public_addr=192.168.1.1  Assigned_client_addr=10.10.10.1
    R2(config-if)#
    *Apr 29 13:32:21.194: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state t
    o up
    R2(config-if)#
    *Apr 29 13:32:22.100: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback10
    000, changed state to up
    *Apr 29 13:32:22.109: %LINEPROTO-5-UPDOWN: Line protocol on Interface NVI0, chan
    ged state to up

    R2(config-if)#do sh cry session det
    Crypto session current status

    Code: C - IKE Configuration mode, D - Dead Peer Detection
    K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
    X - IKE Extended Authentication, F - IKE Fragmentation
    R - IKE Auto Reconnect

    Interface: Virtual-Access1
    Uptime: 00:00:32
    Session status: UP-ACTIVE
    Peer: 192.168.1.1 port 500 fvrf: (none) ivrf: (none)
          Phase1_id: 192.168.1.1
          Desc: (none)
      Session ID: 0
      IKEv1 SA: local 192.168.1.2/500 remote 192.168.1.1/500 Active
              Capabilities:CX connid:1006 lifetime:23:58:55
      Session ID: 0
      IKEv1 SA: local 192.168.1.2/500 remote 192.168.1.1/500 Inactive
              Capabilities:(none) connid:1005 lifetime:0
      Session ID: 0
      IKEv1 SA: local 192.168.1.2/500 remote 192.168.1.1/500 Inactive
              Capabilities:(none) connid:1004 lifetime:0
      Session ID: 0
    -----------------------------------------------------------------------
    R2(config-if)#do sh cry ips sa

    interface: Virtual-Access1
        Crypto map tag: Virtual-Access1-head-0, local addr 192.168.1.2

       protected vrf: (none)
       local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
       remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
       current_peer 192.168.1.1 port 500
         PERMIT, flags={origin_is_acl,}
        #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
        #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
        #pkts compressed: 0, #pkts decompressed: 0
        #pkts not compressed: 0, #pkts compr. failed: 0
        #pkts not decompressed: 0, #pkts decompress failed: 0
        #send errors 0, #recv errors 0

         local crypto endpt.: 192.168.1.2, remote crypto endpt.: 192.168.1.1
         plaintext mtu 1446, path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
         current outbound spi: 0x2A21355E(706819422)
         PFS (Y/N): N, DH group: none

         inbound esp sas:
          spi: 0x95C57185(2512744837)

    Here is the output after issuing a ping:

    R2(config-if)#do ping 150.1.1.1
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 150.1.1.1, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 6/6/8 ms
    R2(config-if)#do sh cry ips sa

    interface: Virtual-Access1
        Crypto map tag: Virtual-Access1-head-0, local addr 192.168.1.2

       protected vrf: (none)
       local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
       remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
       current_peer 192.168.1.1 port 500
         PERMIT, flags={origin_is_acl,}
        #pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
        #pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
        #pkts compressed: 0, #pkts decompressed: 0
        #pkts not compressed: 0, #pkts compr. failed: 0
        #pkts not decompressed: 0, #pkts decompress failed: 0
        #send errors 0, #recv errors 0

         local crypto endpt.: 192.168.1.2, remote crypto endpt.: 192.168.1.1
         plaintext mtu 1446, path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
         current outbound spi: 0x2A21355E(706819422)
         PFS (Y/N): N, DH group: none

         inbound esp sas:
          spi: 0x95C57185(2512744837)

    R2(config-if)#do ping 150.1.1.1 rep 100
    Type escape sequence to abort.
    Sending 100, 100-byte ICMP Echos to 150.1.1.1, timeout is 2 seconds:
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    Success rate is 100 percent (100/100), round-trip min/avg/max = 2/6/22 ms
    R2(config-if)#do sh cry ips sa

    interface: Virtual-Access1
        Crypto map tag: Virtual-Access1-head-0, local addr 192.168.1.2

       protected vrf: (none)
       local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
       remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
       current_peer 192.168.1.1 port 500
         PERMIT, flags={origin_is_acl,}
        #pkts encaps: 105, #pkts encrypt: 105, #pkts digest: 105
        #pkts decaps: 105, #pkts decrypt: 105, #pkts verify: 105
        #pkts compressed: 0, #pkts decompressed: 0
        #pkts not compressed: 0, #pkts compr. failed: 0
        #pkts not decompressed: 0, #pkts decompress failed: 0
        #send errors 0, #recv errors 0

         local crypto endpt.: 192.168.1.2, remote crypto endpt.: 192.168.1.1
         plaintext mtu 1446, path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
         current outbound spi: 0x2A21355E(706819422)
         PFS (Y/N): N, DH group: none

         inbound esp sas:
          spi: 0x95C57185(2512744837)

    Here are the configs below:

    R1 EzVPN Server:



    hostn R1
    aaa new-model
    !
    !
    aaa authentication login authc local
    aaa authorization network authz local
    !
    ip local pool pool2 10.10.10.1 10.10.10.10
    ip access-list extended r1tor2
     permit ip host 150.1.1.1 host 150.2.2.2

    int e0/0
     ip add 192.168.1.1 255.255.255.0
     no shut
    !
    interface Virtual-Template1 type tunnel
     ip unnumbered e0/0
     tunnel source e0/0
     tunnel mode ipsec ipv4

    crypto isakmp policy 1
     encr 3des
     authentication pre-share
     group 2
    crypto isakmp client configuration group ezvpn2
     key cisco
     pool pool2
     acl r1tor2
     save-password
    crypto isakmp profile isakprof2
       match identity group ezvpn2
       client authentication list authc
       isakmp authorization list authz
       client configuration address respond
       virtual-template 1
    crypto ipsec transform-set myset esp-3des esp-md5-hmac
    crypto ipsec profile myprof
     set transform-set myset
     set isakmp-profile isakprof2
    !
    interface Virtual-Template1 type tunnel
     tunnel protection ipsec profile myprof
    !
    interface Loopback100
     ip address 150.1.1.1 255.255.255.255
    !

     

    R2 EzVPN Remote:

    hostn R2
    int e0/0
    ip add 192.168.1.2 255.255.255.0
    no shut

    interface Virtual-Template1 type tunnel
     ip unnumbered Loopback100
    exit
    crypto ipsec client ezvpn ezvpn
     connect auto
     group ezvpn2 key cisco
     mode client
     peer 192.168.1.1
     virtual-interface 1
     username cisco password cisco
     xauth userid mode local
    interface Loopback0
     ip address 150.2.2.2 255.255.255.255
     crypto ipsec client ezvpn ezvpn inside
    interface e0/0
     crypto ipsec client ezvpn ezvpn

  • Hi Cristian,
    I found one thing: When i ping 150.1.1.1 from R2, it is sourced by default from Loopback0 interface and not from ethernet0/0 interface. When i ping 150.1.1.1 source e0/0, i can see that the packets are encrypted on R2 and decrypted on R1 but not encrypted back on R1. Please check the sh crypto ipsec sa output below, does it make sense:

    ------------------------------------------------------------

    R2:

    R2(config)#do ping 150.1.1.1
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 150.1.1.1, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/6 ms
    R2(config)#do sh cry ips sa

    interface: Virtual-Access1
        Crypto map tag: Virtual-Access1-head-0, local addr 192.168.1.2

       protected vrf: (none)
       local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
       remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
       current_peer 192.168.1.1 port 500
         PERMIT, flags={origin_is_acl,}
        #pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
        #pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
        #pkts compressed: 0, #pkts decompressed: 0
        #pkts not compressed: 0, #pkts compr. failed: 0
        #pkts not decompressed: 0, #pkts decompress failed: 0
        #send errors 0, #recv errors 0

         local crypto endpt.: 192.168.1.2, remote crypto endpt.: 192.168.1.1
         plaintext mtu 1446, path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
         current outbound spi: 0xEA020F50(3926003536)
         PFS (Y/N): N, DH group: none

         inbound esp sas:
          spi: 0x749DE42(122281538)

    R2(config)#do ping 150.1.1.1 sou e0/0
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 150.1.1.1, timeout is 2 seconds:
    Packet sent with a source address of 192.168.1.2
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/7 ms
    R2(config)#do sh cry ips sa

    interface: Virtual-Access1
        Crypto map tag: Virtual-Access1-head-0, local addr 192.168.1.2

       protected vrf: (none)
       local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
       remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
       current_peer 192.168.1.1 port 500
         PERMIT, flags={origin_is_acl,}
        #pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10
        #pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
        #pkts compressed: 0, #pkts decompressed: 0
        #pkts not compressed: 0, #pkts compr. failed: 0
        #pkts not decompressed: 0, #pkts decompress failed: 0
        #send errors 0, #recv errors 0

         local crypto endpt.: 192.168.1.2, remote crypto endpt.: 192.168.1.1
         plaintext mtu 1446, path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
         current outbound spi: 0xEA020F50(3926003536)
         PFS (Y/N): N, DH group: none

         inbound esp sas:
          spi: 0x749DE42(122281538)

    R2(config)#

    ------------------------------------------------------------

    R1:

    R1#sh cry ips sa

    interface: Virtual-Access2
        Crypto map tag: Virtual-Access2-head-0, local addr 192.168.1.1

       protected vrf: (none)
       local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
       remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
       current_peer 192.168.1.2 port 500
         PERMIT, flags={origin_is_acl,}
        #pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
        #pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10
        #pkts compressed: 0, #pkts decompressed: 0
        #pkts not compressed: 0, #pkts compr. failed: 0
        #pkts not decompressed: 0, #pkts decompress failed: 0
        #send errors 0, #recv errors 0

         local crypto endpt.: 192.168.1.1, remote crypto endpt.: 192.168.1.2
         plaintext mtu 1446, path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
         current outbound spi: 0x749DE42(122281538)
         PFS (Y/N): N, DH group: none

         inbound esp sas:
          spi: 0xEA020F50(3926003536)

    R1#

    ------------------------------------------------------------

    Moreover, when i ping 150.1.1.1 source e0/0 from R2, the received icmp packet is R2's e0/0 interface IP address and not the VPN address.

    I think the problem is clear now but the traffic is still encrypted on R2. This is the weird thing.

     

  • Hi Moustapha

    I just tested it, it took a while to get it working. but I think I have a sollution for you.  I used policy based routing on the client router, not a very clean sollution but it does seem to wotk.

    Add the following to your client's config:

    !
    ip access-list extended NOENCR
     permit ip host 192.168.1.2 host 150.1.1.1
    !
    route-map NOENCR permit 10
     match ip address NOENCR
     set ip next-hop 192.168.1.1
    !
    ip local policy route-map NOENCR
    !

    I guess it is a order of operations issue.

  • If you would ping from behind the router, like from the user perspective, only traffic going inside-outside will be sent through the tunnel.


    On 29 Apr 2015, at 16:12, moustapha <[email protected]> wrote:

    Hi Cristian,
    I found one thing: When i ping 150.1.1.1 from R2, it is sourced by default from Loopback0 interface and not from ethernet0/0 interface. When i ping 150.1.1.1 source e0/0, i can see that the packets are encrypted on R2 and decrypted on R1 but not encrypted back on R1. Please check the sh crypto ipsec sa output below, does it make sense:

    ------------------------------------------------------------

    R2:

    R2(config)#do ping 150.1.1.1
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 150.1.1.1, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/6 ms
    R2(config)#do sh cry ips sa

    interface: Virtual-Access1
        Crypto map tag: Virtual-Access1-head-0, local addr 192.168.1.2

       protected vrf: (none)
       local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
       remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
       current_peer 192.168.1.1 port 500
         PERMIT, flags={origin_is_acl,}
        #pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
        #pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
        #pkts compressed: 0, #pkts decompressed: 0
        #pkts not compressed: 0, #pkts compr. failed: 0
        #pkts not decompressed: 0, #pkts decompress failed: 0
        #send errors 0, #recv errors 0

         local crypto endpt.: 192.168.1.2, remote crypto endpt.: 192.168.1.1
         plaintext mtu 1446, path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
         current outbound spi: 0xEA020F50(3926003536)
         PFS (Y/N): N, DH group: none

         inbound esp sas:
          spi: 0x749DE42(122281538)

    R2(config)#do ping 150.1.1.1 sou e0/0
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 150.1.1.1, timeout is 2 seconds:
    Packet sent with a source address of 192.168.1.2
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/7 ms
    R2(config)#do sh cry ips sa

    interface: Virtual-Access1
        Crypto map tag: Virtual-Access1-head-0, local addr 192.168.1.2

       protected vrf: (none)
       local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
       remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
       current_peer 192.168.1.1 port 500
         PERMIT, flags={origin_is_acl,}
        #pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10
        #pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
        #pkts compressed: 0, #pkts decompressed: 0
        #pkts not compressed: 0, #pkts compr. failed: 0
        #pkts not decompressed: 0, #pkts decompress failed: 0
        #send errors 0, #recv errors 0

         local crypto endpt.: 192.168.1.2, remote crypto endpt.: 192.168.1.1
         plaintext mtu 1446, path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
         current outbound spi: 0xEA020F50(3926003536)
         PFS (Y/N): N, DH group: none

         inbound esp sas:
          spi: 0x749DE42(122281538)

    R2(config)#

    ------------------------------------------------------------

    R1:

    R1#sh cry ips sa

    interface: Virtual-Access2
        Crypto map tag: Virtual-Access2-head-0, local addr 192.168.1.1

       protected vrf: (none)
       local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
       remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
       current_peer 192.168.1.2 port 500
         PERMIT, flags={origin_is_acl,}
        #pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
        #pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10
        #pkts compressed: 0, #pkts decompressed: 0
        #pkts not compressed: 0, #pkts compr. failed: 0
        #pkts not decompressed: 0, #pkts decompress failed: 0
        #send errors 0, #recv errors 0

         local crypto endpt.: 192.168.1.1, remote crypto endpt.: 192.168.1.2
         plaintext mtu 1446, path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
         current outbound spi: 0x749DE42(122281538)
         PFS (Y/N): N, DH group: none

         inbound esp sas:
          spi: 0xEA020F50(3926003536)

    R1#

    ------------------------------------------------------------

    Moreover, when i ping 150.1.1.1 source e0/0 from R2, the received icmp packet is R2's e0/0 interface IP address and not the VPN address. 

    I think the problem is clear now.

     



    INE - The Industry Leader in CCIE Preparation
    http://www.INE.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • Dears,

    I opened a case with Cisco for the below and it seems that there is a bug in this setup and it is still open:
    https://tools.cisco.com/bugsearch/bug/CSCsw24960/?reffering_site=dumpcr

    Best Regards,

    Moustafa

Sign In or Register to comment.