01-02-2004 10:08 AM - edited 02-21-2020 12:59 PM
HNY to all :)
I have set up this IPSEC config and I am a little confused as the packet that is sent, only has an IPSEC made header and I dont see the original IP header even though I am running IPSEC in transport mode.
I am using basic ethereal to capture the packet.
Is this correct? Accourding to the "deploying IPSEC reference guide" you should see the original IP header and then the IPSEC header?
Please can someone confirm this. Packet decode at the bottom of this post.
hostname 2600-r02
!
crypto isakmp policy 1
authentication pre-share
group 5
lifetime 120
crypto isakmp key kenny address 1.1.1.1
!
!
crypto ipsec transform-set KEN esp-des esp-md5-hmac
mode transport
crypto ipsec transform-set KEN1 ah-md5-hmac !transform set not in use
!
crypto map IPSEC local-address Loopback98
crypto map IPSEC 10 ipsec-isakmp
set peer 1.1.1.1
set transform-set KEN
set pfs group5
match address IPSEC-test
!
!
interface Loopback98
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
ip address xxxx xxxx
crypto map IPSEC
!
!
ip access-list extended IPSEC-test
permit icmp any any
--------------------------------------------------------
hostname 2600-r01
!
crypto isakmp policy 1
authentication pre-share
group 5
lifetime 120
crypto isakmp key kenny address 2.2.2.2
!
!
crypto ipsec transform-set KEN esp-des esp-md5-hmac
mode transport
crypto ipsec transform-set KEN1 ah-md5-hmac !transform set not in use
!
crypto map IPSEC local-address Loopback98
crypto map IPSEC 10 ipsec-isakmp
set peer 2.2.2.2
set transform-set KEN
set pfs group5
match address IPSEC-test
!
!
interface Loopback98
ip address 1.1.1.1 255.255.255.255
!
!
interface FastEthernet0/0
ip address xxxx xxxx
crypto map IPSEC
!
!
ip access-list extended IPSEC-test
permit icmp any any
Frame 320 (170 bytes on wire, 170 bytes captured)
Arrival Time: Jan 2, 2004 17:52:12.095628000
Time delta from previous packet: 0.350549000 seconds
Time relative to first packet: 56.103468000 seconds
Frame Number: 320
Packet Length: 170 bytes
Capture Length: 170 bytes
Ethernet II, Src: 00:01:64:2e:b3:fc, Dst: 00:0d:65:5b:84:c0
Destination: 00:0d:65:5b:84:c0 (Cisco_5b:84:c0)
Source: 00:01:64:2e:b3:fc (Cisco_2e:b3:fc)
Type: 802.1Q Virtual LAN (0x8100)
802.1q Virtual LAN
000. .... .... .... = Priority: 0
...0 .... .... .... = CFI: 0
.... 0000 0011 0010 = ID: 50
Type: IP (0x0800)
Internet Protocol, Src Addr: 2.2.2.2 (2.2.2.2), Dst Addr: 1.1.1.1 (1.1.1.1)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 152
Identification: 0x0517 (1303)
Flags: 0x00
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 253
Protocol: ESP (0x32)
Header checksum: 0xb217 (correct)
Source: 2.2.2.2 (2.2.2.2)
Destination: 1.1.1.1 (1.1.1.1)
Encapsulating Security Payload
SPI: 0x07e3004c
Sequence: 0x00000003
Data (124 bytes)
0000 35 14 ad 55 68 29 b1 0d c5 7e ff ce ee 9a 1b 97 5..Uh)...~......
0010 69 8f d1 2a 11 7a bd 5c 7b 86 b2 d8 1f 2e fd 5e i..*.z.\{......^
0020 52 8e 52 04 69 2a 24 af 69 8f 40 12 99 42 ad 4c R.R.i*$.i.@..B.L
0030 15 26 80 0f b5 6f 55 f7 c9 de f7 03 f6 9f 2e ec .&...oU.........
0040 ee 21 38 10 9b 72 13 9d 05 e6 b3 83 ed 33 7b 58 .!8..r.......3{X
0050 10 71 b9 ff 14 c3 f2 22 27 68 81 79 b3 0a 8f c0 .q....."'h.y....
0060 bd a5 f0 d8 28 2c 77 ca 07 60 77 a0 f7 ab 81 86 ....(,w..`w.....
0070 e3 e2 0f 72 22 b8 61 b6 f4 ae 66 37 ...r".a...f7
01-02-2004 07:02 PM
This looks correct. The following section is your original IP header:
Type: IP (0x0800)
Internet Protocol, Src Addr: 2.2.2.2 (2.2.2.2), Dst Addr: 1.1.1.1 (1.1.1.1)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 152
Identification: 0x0517 (1303)
Flags: 0x00
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 253
Protocol: ESP (0x32)
Header checksum: 0xb217 (correct)
Source: 2.2.2.2 (2.2.2.2)
Destination: 1.1.1.1 (1.1.1.1)
then we see the ESP packet. Some things within the original IP header will be changed, like the Protocol (will be made ESP), and the checksum obviously, but the source and dest IP address should remain intact.
I presume from this that you say, pinged from 2.2.2.2 to 1.1.1.1, so the ICMP portion of the packet is now encrypted, but the original IP header is still there with its original src/dest, just the protocol has changed from ICMP to ESP.
Try doing tunnel mode and capturing one of those packets and you should be able to see the difference.
I think the main issue you're having is that you're pinging from and to the IPSec peers, so you're seeing 1.1.1.1 and 2.2.2.2 everywhere, but this is both your IPSec endpoints AND your data endpoints, so it looks like things aren't working right. If you had other ethernet ports on these routers and pinged from hosts behind these routers, you'd see the original IP addresses in the IP header then, and they'd be different to the IPSec peers so it'd be more obvious what was happening.
01-04-2004 04:41 AM
Hello, and many thx for you reply :)
Sorry, one point I should have mentioned is that I am pinging a loopback on rtr1 from a loopback on rtr2 so that the IPsec header creation is different from the original IP header scr/dst addresses.
I am actually ping 16.1.1.1 from address 21.1.1.1 which are two loopbacks on my routers.
I have tested in tunnel mode and I see the esp packet encrypt all of the packet with only the new IPsec header in the packet.
Maybe you could help me further and see if we could get to the bottom of this?
Many thx indeed,
Ken
01-05-2004 03:45 AM
Also, Here is the debug ip packet det when I perform the ping.
600-r02#ping 16.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 16.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/12 ms
2600-r02#
2d18h: IP: s=30.96.100.13 (local), d=16.1.1.1, len 100, cef process switched
2d18h: ICMP type=8, code=0
2d18h: IP: s=30.96.100.13 (local), d=16.1.1.1 (FastEthernet0/0), len 100, sending
2d18h: ICMP type=8, code=0
2d18h: IP: s=16.1.1.1 (FastEthernet0/0), d=30.96.100.13 (FastEthernet0/0), len 100, rcvd 3
2d18h: ICMP type=0, code=0
2d18h: IP: s=30.96.100.13 (local), d=16.1.1.1, len 100, cef process switched
2d18h: ICMP type=8, code=0
2d18h: IP: s=30.96.100.13 (local), d=16.1.1.1 (FastEthernet0/0), len 100, sending
2d18h: ICMP type=8, code=0
2d18h: IP: s=16.1.1.1 (FastEthernet0/0), d=30.96.100.13 (FastEthernet0/0), len 100, rcvd 3
2d18h: ICMP type=0, code=0
2d18h: IP: s=30.96.100.13 (local), d=16.1.1.1, len 100, cef process switched
2d18h: ICMP type=8, code=0
2d18h: IP: s=30.96.100.13 (local), d=16.1.1.1 (FastEthernet0/0), len 100, sending
2d18h: ICMP type=8, code=0
2d18h: IP: s=16.1.1.1 (FastEthernet0/0), d=30.96.100.13 (FastEthernet0/0), len 100, rcvd 3
2d18h: ICMP type=0, code=0
2d18h: IP: s=30.96.100.13 (local), d=16.1.1.1, len 100, cef process switched
2d18h: ICMP type=8, code=0
2d18h: IP: s=30.96.100.13 (local), d=16.1.1.1 (FastEthernet0/0), len 100, sending
2d18h: ICMP type=8, code=0
2d18h: IP: s=16.1.1.1 (FastEthernet0/0), d=30.96.100.13 (FastEthernet0/0), len 100, rcvd 3
2d18h: ICMP type=0, code=0
2d18h: IP: s=30.96.100.13 (local), d=16.1.1.1, len 100, cef process switched
2d18h: ICMP type=8, code=0
2d18h: IP: s=30.96.100.13 (local), d=16.1.1.1 (FastEthernet0/0), len 100, sending
2d18h: ICMP type=8, code=0
2d18h: IP: s=16.1.1.1 (FastEthernet0/0), d=30.96.100.13 (FastEthernet0/0), len 100, rcvd 3
2d18h: ICMP type=0, code=0
2600-r02#
2600-r02#
2600-r01#debug ip pack det 150
IP packet debugging is on (detailed) for access list 150
2600-r01#term mon
2600-r01#
2d18h: IP: s=16.1.1.1 (local), d=30.96.100.13, len 100, cef process switched
2d18h: ICMP type=0, code=0
2d18h: IP: s=16.1.1.1 (local), d=30.96.100.13 (FastEthernet0/0), len 100, sending
2d18h: ICMP type=0, code=0
2d18h: IP: s=16.1.1.1 (local), d=30.96.100.13, len 100, cef process switched
2d18h: ICMP type=0, code=0
2d18h: IP: s=16.1.1.1 (local), d=30.96.100.13 (FastEthernet0/0), len 100, sending
2d18h: ICMP type=0, code=0
2d18h: IP: s=16.1.1.1 (local), d=30.96.100.13, len 100, cef process switched
2d18h: ICMP type=0, code=0
2d18h: IP: s=16.1.1.1 (local), d=30.96.100.13 (FastEthernet0/0), len 100, sending
2d18h: ICMP type=0, code=0
2d18h: IP: s=16.1.1.1 (local), d=30.96.100.13, len 100, cef process switched
2d18h: ICMP type=0, code=0
2d18h: IP: s=16.1.1.1 (local), d=30.96.100.13 (FastEthernet0/0), len 100, sending
2d18h: ICMP type=0, code=0
2d18h: IP: s=16.1.1.1 (local), d=30.96.100.13, len 100, cef process switched
2d18h: ICMP type=0, code=0
2d18h: IP: s=16.1.1.1 (local), d=30.96.100.13 (FastEthernet0/0), len 100, sending
2d18h: ICMP type=0, code=0
2600-r01#
2600-r01#
Also, The cry engine conn active - if this helps
2600-r02#sh cry engine conn active
ID Interface IP-Address State Algorithm Encrypt Decrypt
2000 FastEthernet0/0 30.96.100.13 set HMAC_MD5+DES_56_CB 0 32
2001 FastEthernet0/0 30.96.100.13 set HMAC_MD5+DES_56_CB 32 0
2600-r02#
2600-r01#sh cry engine conn active
ID Interface IP-Address State Algorithm Encrypt Decrypt
2000 FastEthernet0/0 30.96.100.17 set HMAC_MD5+DES_56_CB 0 32
2001 FastEthernet0/0 30.96.100.17 set HMAC_MD5+DES_56_CB 32 0
2600-r01#
Many thx indeed,
Ken
01-10-2004 04:54 AM
Hi Ken,
Transport mode is only negotiated between two hosts not between two subnets.Here Permit ip any any indicates between two lan subnets any traffic should be encrypted.
Please check the o/p show crypto ipsec sa, and check whether what Mode is negotiated. I suppose it will be tunnel in your case.(check inbound sa and outbound sa)
Other way round to investigate the problem is:
Make an access-list for interesting traffic as given below.(specifying ipsec endpoints in the acl as intersting traffic)
example:
access-list 101 permit icmp host
apply this acl to the crypto map, and check the o/p of show crypto ipsec sa....
in the inbound sa/outbound sa it will show the type of mode negotiated.It will be transport with the above acl
Generally Transport mode is used for GRE in Ipsec( ecapsulating GRE traffic in Ipsec) as traffic to be encrypted is now between two hosts.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide