Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Community Member

IPSEC in Transport Mode

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

4 REPLIES
Cisco Employee

Re: IPSEC in Transport Mode

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.

Community Member

Re: IPSEC in Transport Mode

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

Community Member

Re: IPSEC in Transport Mode

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

Community Member

Re: IPSEC in Transport Mode

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 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.

303
Views
0
Helpful
4
Replies
CreatePlease to create content