Bug 712189

Summary: ipsec over loopback with specific ports does not work
Product: Red Hat Enterprise Linux 6 Reporter: Avesh Agarwal <avagarwa>
Component: kernelAssignee: Red Hat Kernel Manager <kernel-mgr>
Status: CLOSED NOTABUG QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: high Docs Contact:
Priority: urgent    
Version: 6.1CC: iboverma, jrieden, sgrubb
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-06-14 20:07:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

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.