netdev - Ipsec with mark encryption decision made before mangle output chain

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <54D26DB6.6000404@apinetstore2.apirx.biz>
Date:	Wed, 04 Feb 2015 14:06:30 -0500
From:	Bill Shirley <bshirley@...netstore2.apirx.biz>
To:	netdev@...r.kernel.org
Subject: Ipsec with mark encryption decision made before mangle output chain

I'm setting up a pair of Ipsec tunnels (to the same destination) and using ip xfrm policy marks (no state marks).

The following doesn't work, the packet never gets incrypted:
ping 192,168.4.1

However, this works:
ping -m 80896 192.168.4.1

I have rules in my iptables -t mangle output to set the mark:
     0     0 RETURN     esp  --  *      * 0.0.0.0/0            0.0.0.0/0            mark match 0x13c00/0x3ff00 /* esp 
with a mark */
     0     0 RETURN     esp  --  *      * 0.0.0.0/0            0.0.0.0/0            mark match 0x12c00/0x3ff00 /* esp 
with a mark */
     4   336 CONNMARK  !esp  --  *      * 0.0.0.0/0            192.168.4.0/24       ctstate NEW /* -vpn- new outgoing */ 
CONNMARK xset 0x10700/0x3ff00
     4   336 MARK      !esp  --  *      * 0.0.0.0/0            0.0.0.0/0            connmark match 0x10700/0x3ff00 
match-set sfn_ctel_up dst /* -vpn- mark for encryption */ MARK xset 0x13c00/0x3ff00
     4   336 MARK      !esp  --  *      * 0.0.0.0/0            0.0.0.0/0            connmark match 0x10700/0x3ff00 
match-set sfn_pwrbd_up dst /* -vpn- mark for encryption */ MARK xset 0x12c00/0x3ff00
The numbers are from the ping without the mark.  As you can see, it does encrypt the packet (no esp matches).


Is it possible that the encryption mark is selected before the output chain?

Is this the right place to post for this type of problem?

Thanks,
Bill

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html