linux-kernel - ipsec using xfrm mark on kernel 3.13.5-101.fc19.x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <5332C664.4060503@apinetstore.apirx.biz>
Date:	Wed, 26 Mar 2014 08:21:56 -0400
From:	Bill Shirley <bshirley@...netstore.apirx.biz>
To:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: ipsec using xfrm mark on kernel 3.13.5-101.fc19.x86_64 is broken

I apologize in advance if I'm posting this to the wrong list.  Also, I've attempted to post in plain text; I hope 
Thunderbird behaves.

I have set up a ipsec tunnel between Server-A and Server-B using public IP addresses and configured the ip xfrm state 
and ip xfrm policy database to use marks.  This works correctly if both servers are not using a newer kernel.  I have 
this working with (1st setup) :
Server-A kernel 3.6.9-2.fc17.x86_64 <-> Server-B kernel 3.6.3-1.fc17.x86_64 (no marks this side)
also:
Server-A kernel 3.6.9-2.fc17.x86_64 <-> Server-B kernel 3.4.2-1.fc16.x86_64

However, this doesn't work completely with this setup (2nd setup) :
Server-A kernel 3.4.2-1.fc16.x86_64 <-> Server-B kernel 3.13.5-101.fc19.x86_64
nor with:
Server-A kernel 2.6.33.7-server-2mnb (Mandriva 2010, no marks this side) <-> Server-B kernel 3.12.11-201.fc19.x86_64

Keep in mind that this is a TUNNEL ipsec using MARKS (mark 12032/0xff00).  On the 2nd setup, all traffic flows for:
PC-A <-> Server-A <-> Server-B <-> PC-B
PC-A <-> Server-A <-> Server-B
                   Server-A <-> Server-B <-> PC-B

Actual values for Server-A kernel 3.4.2-1.fc16.x86_64 (192.168.64.0/23 (yes, /23) <-> Server-B kernel 
3.13.5-101.fc19.x86_64  (10.0.0.0/8):
192.168.65.137 = PC-A
192.168.64.1 = Server-A
10.96.0.9 = Server-B
10.96.0.8 = PC-B

However, SSH doesn't work for (either direction):
Server-A <-> Server-B

These do work:
ping
dig axfr
telnet imap
links http://

I get incomplete response (takes a long time):
from Server-A: smbclient -L 10.96.0.9

However this works completely and swiftly:
from Server-B: smbclient -L 192.168.64.1

Something about ipsec in the OUTPUT chain on newer kernels is broken.  In the Server-B mangle table I can put a dummy 
mark (outside the xfrm mask, of course) on outgoing SSH traffic and ESP traffic and observe that the ssh daemon on the 
3.13.5 kernel DOES respond to all packets but not all packets are encrypted and sent out the wire.

I've attached a portion of my iptables OUTPUT chain to demonstrate this.  This is from:
Server-A kernel 2.6.33.7-server-2mnb (Mandriva 2010, no marks this side) <-> Server-B kernel 3.12.11-201.fc19.x86_64
192.168.0.231/24 <-> 172.20.8.3/24
mangle.ssh.txt => ssh 192.168.0.231
mangle.imap.txt => telnet 192.168.0.231 imap

I chose this pair because Server-B is idle and there is no other esp traffic.

What is different about the way openssh and smbclient operate that fails vs several other programs not failing?  There 
may be other programs failing, I just haven't though of any to test.

Any help or pointers is much appreciated.

Thanks,
Bill

View attachment "mangle.ssh.txt" of type "text/plain" (1313 bytes)

View attachment "ip.xfrm.txt" of type "text/plain" (1106 bytes)

View attachment "mangle.imap.txt" of type "text/plain" (1315 bytes)