Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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.
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.