From: Kal Han (calikali2006@gmail.com)
Date: Mon Nov 27 2006 - 21:25:56 ART
Hi
Richard: thats what I noticed. I tried other combinations before. But
they never worked. What is difference when I use the loopback as
tunnel source and apply my crypto map on the loopback interface
in terms of how the packet travells and hitting VPN acls ?
Why doesnt it work when I apply the crypto map on loopback after
setting the crypto map local-address as loopback ?
( may be I got the purpose of this command wrong )
Jens: You pointed out to my other question. Whether I use an ip or gre
in the access-list, the behavior is the same. I am confused at this.
I always used the gre acl. once by mistake I put ip instead of gre and it
still worked. I tried to monitor session the traffic on to my pc to see the
ip and gre headers. Before encryption, I see packet in the following format
Every thing below is in the packet with appropriate IPs set.
Here is the packet capture.
IP src=tunnel-src-int-address IP
dst=tunnel-dst-address-define-under-tunnel
GRE(IP) ( with protocol type set to IP )
IP src=ip-addr-of-tunnel-itself IP dst=224.0.0.10
*Frame 6 (98 bytes on wire, 98 bytes captured)
Ethernet II, Src: 00:02:4b:77:53:20, Dst: 00:30:19:0a:c5:60
**Internet Protocol, Src Addr: 195.1.124.2 (195.1.124.2), Dst Addr:
195.1.124.4 (195.1.124.4)
Generic Routing Encapsulation (IP)
Flags and version: 0000
Protocol Type: IP (0x0800)
Internet Protocol, Src Addr: 195.1.24.2 (195.1.24.2), Dst Addr: 224.0.0.10 (
224.0.0.10)
**Cisco EIGRP
*
Here is my crypto acl after the tunnel is up and I see the hit counts
for IP access list.
R3#sh access-li 193
Extended IP access list 193
10 permit ip 103.103.103.0 0.0.0.255 106.106.106.0 0.0.0.255 (115
matches)
20 permit gre 103.103.103.0 0.0.0.255 106.106.106.0 0.0.0.255
Thanks
Kal
On 11/27/06, Richard Dumoulin <Richard.Dumoulin@vanco.fr> wrote:
>
> Jens, it is the other way around; the crypto map should be applied on the
> physical interface not the tunnel
>
> -- Richard
> CCIE 13891
>
> -----Message d'origine-----
> De: nobody@groupstudy.com [mailto:nobody@groupstudy.com] De la part de
> Jens Petter
> Envoyi: Monday, November 27, 2006 11:03 PM
> @: 'Kal Han'
> Cc: 'Groupstudy'; 'Cisco certification'
> Objet: RE: VPN between loopbacks - GRE
>
> Wich version IOS do you use. this should not be a problem, you should not
> use the crypto map on
> your loopback either.. ONLY on the tunnel interface.
>
>
>
> The only thing that I notice. You should only match the endpoints of your
> tunnel with the GRE protocol
> and not the IP protocol. So, remove that first line in your acl. And only
> use :
>
>
>
> permit gre <http://103.103.103.0> 103.103.103.0 <http://0.0.0.255>
> 0.0.0.255 <http://106.106.106.0> 106.106.106.0 <http://0.0.0.255>
> 0.0.0.255
>
>
>
>
>
> Let me know
>
>
>
>
>
> Mvh
>
> Jens Petter Eikeland
>
> Mob 98247550
> Hipercom AS
>
> _____
>
> From: Kal Han [mailto:calikali2006@gmail.com]
> Sent: 27. november 2006 20:32
> To: Jens Petter
> Cc: Groupstudy; Cisco certification
> Subject: Re: VPN between loopbacks - GRE
>
>
>
> Hi
>
> I tried what you said and it not working for me.
>
> If it goes on the tunnel interface what will be my interesting
>
> traffic ?
>
> I dont know whats the order of encryption. I mean how will
>
> the EIGRP packet pass thru converting into a gre packet /
>
> get encrypted packed on tunnel interface. Which is first ?
>
>
>
> interface Tunnel0
> ip address 36.36.36.3 255.255.255.0
> tunnel source Loopback36
> tunnel destination 106.106.106.6
> crypto map loop
>
>
>
> With this on the tunnel interface, its not working.
>
> Its only working when I apply crypto map on the physical interface.
>
> Its working only when I put my crypto map on the physical interface
>
> and doesnt matter whether I have it on loopback or tunnel interfaces.
>
>
>
> Here are some outputs.
>
>
>
> acl: (no hit counts after applying on tunnel/loopback interface)
>
> Extended IP access list 193
> ***10 permit ip 103.103.103.0 0.0.0.255 106.106.106.0 0.0.0.255 *****
> 20 permit gre 103.103.103.0 0.0.0.255 106.106.106.0 0.0.0.255
>
>
>
> loopback interface:
>
> interface Loopback36
> ip address 103.103.103.3 255.255.255.0
> crypto map loop <--------- no difference with/without this
>
>
> Physical Interface: (no crypto map applied)
>
> interface Serial0/0.6 point-to-point
> ip address 195.1.136.3 255.255.255.0
> ip nat outside
> ip ospf message-digest-key 1 md5 cciesec
> ntp broadcast key 1
> frame-relay interface-dlci 306
>
>
>
> R3#sh ip eig nei (eigrp is running fine)
> IP-EIGRP neighbors for process 123
> H Address Interface Hold Uptime SRTT
> RTO Q Seq
> Type
> (sec) (ms) Cnt
> Num
>
> 1 195.1.123.2 Fa0/0 10 1d21h 4
> 200 0 26
>
> 0 195.1.123.1 Fa0/0 14 1d21h 4
> 200 0 26
>
> IP-EIGRP neighbors for process 36
> H Address Interface Hold Uptime SRTT
> RTO Q Seq
> Type
> (sec) (ms) Cnt
> Num
> 0 36.36.36.6 Tu0 12 18:06:51 1 3000 0 5
>
>
>
> **************************************
>
> crypto related outputs.
>
>
>
> R3#sh cry eng conn act
>
> ID Interface IP-Address State Algorithm Encrypt
> Decrypt
>
> R3#
> R3#sh cry isa sa
> dst src state conn-id slot
>
> R3#sh cry ipsec sa
>
> interface: Loopback36
> Crypto map tag: loop, local addr. 103.103.103.3
>
> protected vrf:
> local ident (addr/mask/prot/port): (103.103.103.0/255.255.255.0/0/0)
> remote ident (addr/mask/prot/port): ( 106.106.106.0/255.255.255.0/0/0
> <http://106.106.106.0/255.255.255.0/0/0> )
> current_peer: 106.106.106.6: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.: 103.103.103.3, remote crypto endpt.:
> 106.106.106.6
> path mtu 1476, media mtu 1476
> current outbound spi: 0
>
> Thanks
>
> Kal
>
> On 11/26/06, Jens Petter <jenseike@start.no> wrote:
>
> Crypto map should go directly on the tunnel interface, not physical or
> loopback interface. That goes for both sides... Your "crypto map local"
> command still goes
> to the loopback...
>
>
> Mvh
> Jens Petter Eikeland
> Mob 98247550
> Hipercom AS
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Kal
> Han
> Sent: 27. november 2006 01:35
> To: Groupstudy; Cisco certification
> Subject: VPN between loopbacks - GRE
>
> Hi
>
> Im trying to configure vpn between two loopback interfaces
> for gre traffic.
> I set the tunnel source as loopback interface.
> and applied my crypto map on the physical interface.
> I am also using "crypto map loop local-address Loopback36"
>
> In this case, my interesting traffic for VPN is gre
> traffic from loopback - to - loopback.
> *So why should I apply the crypto map on physical interface ?*
> *Is it possible to apply the crypto map on the loopback interface*
> *and bring the tunnel up* ? It didnt work for me.
>
> R3#sh access-li 193
> Extended IP access list 193
> 20 permit gre 103.103.103.0 0.0.0.255 106.106.106.0 0.0.0.255 (398
> matches)
>
> R3#sh run int t0
> Building configuration...
>
> Current configuration : 122 bytes
> !
> interface Tunnel0
> ip address 36.36.36.3 255.255.255.0
> tunnel source Loopback36
> tunnel destination 106.106.106.6
> end
>
> R3#sh run int lo36
> Building configuration...
>
> Current configuration : 68 bytes
> !
> interface Loopback36
> ip address 103.103.103.3 255.255.255.0
> end
>
> R3#sh run int s0/0.6
> Building configuration...
>
> Current configuration : 180 bytes
> !
> interface Serial0/0.6 point-to-point
> ip address 195.1.136.3 255.255.255.0
> ip ospf message-digest-key 1 md5 cciesec
> ntp broadcast key 1
> frame-relay interface-dlci 306
> crypto map loop
> end
>
> R3#sh run
> Building configuration...
>
> Current configuration : 3953 bytes
> !
> ! Last configuration change at 16:24:20 PST Sun Nov 26 2006
> !
> version 12.2
> service timestamps debug datetime msec
> service timestamps log datetime msec
> no service password-encryption
> !
> hostname R3
> !
> logging queue-limit 100
> !
> enable use-tacacs
> enable last-resort succeed
> memory-size iomem 15
> clock timezone PST -8
> ip subnet-zero
> !
> !
> no ip domain lookup
> !
> ip audit notify log
> ip audit po max-events 100
> !
> !
> !
> crypto isakmp policy 10
> hash md5
> authentication pre-share
> group 2
> crypto isakmp key cciesec address 106.106.106.6
> !
> !
> crypto ipsec transform-set ts esp-des esp-md5-hmac
> !
> crypto map loop local-address Loopback36
> crypto map loop 10 ipsec-isakmp
> set peer 106.106.106.6
> set transform-set ts
> match address 193
> !
> no voice hpi capture buffer
> no voice hpi capture destination
> !
> !
> mta receive maximum-recipients 0
> !
> !
> !
> !
> interface Loopback0
> ip address 33.33.33.33 255.255.255.0 <http://255.255.255.0>
> !
> interface Loopback36
> ip address 103.103.103.3 255.255.255.0
> !
> interface Loopback100
> ip address 100.3.3.3 <http://100.3.3.3> 255.255.255.0
> !
> interface Tunnel0
> ip address 36.36.36.3 255.255.255.0
> tunnel source Loopback36
> tunnel destination 106.106.106.6
> !
> interface FastEthernet0/0
> ip address 195.1.123.3 255.255.255.0
> ip ospf message-digest-key 1 md5 cciesec
> duplex auto
> speed auto
> !
> interface Serial0/0
> no ip address
> encapsulation frame-relay IETF
> frame-relay lmi-type cisco
> !
> interface Serial0/0.4 point-to-point
> ip address 195.1.134.3 255.255.255.0
> ip ospf message-digest-key 1 md5 cciesec
> frame-relay interface-dlci 304
> !
> interface Serial0/0.5 point-to-point
> ip address 195.1.135.3 255.255.255.0
> ip ospf message-digest-key 1 md5 cciesec
> frame-relay interface-dlci 305
> !
> interface Serial0/0.6 point-to-point
> ip address 195.1.136.3 255.255.255.0
> ip ospf message-digest-key 1 md5 cciesec
> ntp broadcast key 1
> frame-relay interface-dlci 306
> crypto map loop
> !
> interface FastEthernet0/1
> no ip address
> shutdown
> duplex auto
> speed auto
> !
> router eigrp 123
> network 195.1.123.0
> distance eigrp 90 90
> no auto-summary
> !
> router eigrp 36
> network 36.36.36.0 0.0.0.255
> network 106.106.106.0 0.0.0.255
> distance eigrp 90 90
> no auto-summary
> !
> router ospf 1
> router-id 33.33.33.33
> log-adjacency-changes
> area 0 authentication message-digest
> area 4 authentication message-digest
> area 4 stub no-summary
> area 56 authentication message-digest
> area 56 nssa no-summary
> network 33.33.33.0 0.0.0.255 area 4
> network 103.103.103.0 0.0.0.255 <http://0.0.0.255> area 56
> network 195.1.123.0 0.0.0.255 area 0
> network 195.1.134.0 0.0.0.255 area 4
> network 195.1.135.0 0.0.0.255 area 56
> network 195.1.136.0 0.0.0.255 area 56
> !
> router bgp 3
> no synchronization
> bgp log-neighbor-changes
> network 100.3.3.0 mask 255.255.255.0
> neighbor 195.1.134.4 remote-as 4
> neighbor 195.1.134.4 local-as 356
> neighbor 195.1.135.5 remote-as 5
> neighbor 195.1.135.5 maximum-prefix 1000 50
> neighbor 195.1.136.6 remote-as 6
> neighbor 195.1.136.6 route-map asprepend out
> no auto-summary
> !
> ip http server
> no ip http secure-server
> ip classless
> !
> !
> !
> ip prefix-list pix-inside seq 5 deny 172.16.0.0/16 le 32
> !
> access-list 1 permit 100.3.3.0 0.0.0.255
> access-list 193 permit gre 103.103.103.0 0.0.0.255 106.106.106.0 0.0.0.255
> !
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> **********************************************************************
> Any opinions expressed in the email are those of the individual and not
> necessarily the company. This email and any files transmitted with it are
> confidential and solely for the use of the intended recipient. If you are
> not the intended recipient or the person responsible for delivering it to
> the intended recipient, be advised that you have received this email in
> error and that any dissemination, distribution, copying or use is strictly
> prohibited.
>
> If you have received this email in error, or if you are concerned with the
> content of this email please e-mail to: e-security.support@vanco.info
>
> The contents of an attachment to this e-mail may contain software viruses
> which could damage your own computer system. While the sender has taken
> every reasonable precaution to minimise this risk, we cannot accept
> liability for any damage which you sustain as a result of software viruses.
> You should carry out your own virus checks before opening any attachments to
> this e-mail.
> **********************************************************************
This archive was generated by hypermail 2.1.4 : Fri Dec 01 2006 - 08:05:48 ART