Bug 712189 - ipsec over loopback with specific ports does not work
Summary: ipsec over loopback with specific ports does not work
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.1
Hardware: Unspecified
OS: Unspecified
urgent
high
Target Milestone: rc
: ---
Assignee: Red Hat Kernel Manager
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-09 18:21 UTC by Avesh Agarwal
Modified: 2011-06-14 20:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-14 20:07:53 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Avesh Agarwal 2011-06-09 18:21:26 UTC
Description of problem:
Scenario is:

127.0.0.1 (tcp: any port)<----> 127.0.0.1 (tcp: some port say 6000)

The above scenario does not work, i.e., packets are not being processed through ipsec, or no ESP packets are visible through tcpdump. 

Version-Release number of selected component (if applicable):
2.6.32-131.0.15.el6.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Setup ipsec policies as follows:

ip xfrm policy add src 127.0.0.1/32 dst 127.0.0.1/32 proto tcp dport 60000 dir out ptype main priority 2080 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp mode transport reqid 16389

ip xfrm policy add src 127.0.0.1/32 dst 127.0.0.1/32 proto tcp dport 60000 dir in ptype main priority 2080 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp mode transport reqid 16389

ip xfrm policy add src 127.0.0.1/32 dst 127.0.0.1/32 proto tcp sport 60000 dir out ptype main priority 2080 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp mode transport reqid 16389

ip xfrm policy add src 127.0.0.1/32 dst 127.0.0.1/32 proto tcp sport 60000 dir in ptype main priority 2080 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp mode transport reqid 16389


2. setup ipsec state as follows:

ip xfrm state add src 127.0.0.1 dst 127.0.0.1 proto esp spi 0xcb9cfc0c mode transport reqid 16389 replay-window 32 auth sha1 0xd2194aa97972a9e1a3c78c636d291af1d9e5bddc enc aes 0xeeadc60ef6a06f22a94e3779ca6ca72ab1389a03e1ac80c58428142ca55d315c

3. nc -lk 127.0.0.1 6000 on one term.

4. nc -w 30 -v 127.0.0.1 6000 
Connection to 127.0.0.1 6000 port [tcp/x11] succeeded! 
  
Actual results:
connection succeeds but not through ipsec as tcpdump output does not show any ESP packets:

13:17:02.048983 IP 127.0.0.1.48732 > 127.0.0.1.x11: Flags [S], seq 4213246335, win 32792, options [mss 16396,sackOK,TS val 1307410 ecr 0,nop,wscale 5], length 0
13:17:02.049060 IP 127.0.0.1.x11 > 127.0.0.1.48732: Flags [S.], seq 4213498696, ack 4213246336, win 32768, options [mss 16396,sackOK,TS val 1307410 ecr 1307410,nop,wscale 5], length 0
13:17:02.049098 IP 127.0.0.1.48732 > 127.0.0.1.x11: Flags [.], ack 1, win 1025, options [nop,nop,TS val 1307410 ecr 1307410], length 0


Expected results:
Packets should be encrypted and tcpdump should shows ESP packets.

Additional info:
What works:
if I specify just tcp connection without any specific port as follows:

1. ipsec policies:

ip xfrm policy add src 127.0.0.1/32 dst 127.0.0.1/32 proto tcp  dir out ptype main priority 2080 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp mode transport reqid 16389

ip xfrm policy add src 127.0.0.1/32 dst 127.0.0.1/32 proto tcp  dir in ptype main priority 2080 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp mode transport reqid 16389

2. ipsec state:

ip xfrm state add src 127.0.0.1 dst 127.0.0.1 proto esp spi 0xcb9cfc0c mode transport reqid 16389 replay-window 32 auth sha1 0xd2194aa97972a9e1a3c78c636d291af1d9e5bddc enc aes 0xeeadc60ef6a06f22a94e3779ca6ca72ab1389a03e1ac80c58428142ca55d315c

3. nc -lk 127.0.0.1 6000 on one term.

4. nc -w 30 -v 127.0.0.1 6000 
Connection to 127.0.0.1 6000 port [tcp/x11] succeeded! 

5. tcpdump output:


14:06:11.616264 IP 127.0.0.1 > 127.0.0.1: ESP(spi=0xcb9cfc0c,seq=0x1), length 84
14:06:11.616326 IP 127.0.0.1 > 127.0.0.1: ESP(spi=0xcb9cfc0c,seq=0x2), length 84
14:06:11.616357 IP 127.0.0.1 > 127.0.0.1: ESP(spi=0xcb9cfc0c,seq=0x3), length 84

In summary: a general connection to tcp policies works, but tcp policies with specific ports does not work.

Comment 2 Avesh Agarwal 2011-06-14 20:07:53 UTC
Further investigation showed that this was happening due to configuration issue. kernel seems to be doing right thing. So I am close this bz as not a bug.


Note You need to log in before you can comment on or make changes to this bug.