Bug 497591

Try reversing the priorities.

that would give me exactly the behaviour I dont want. ICMP traffic would be forced to use esp because that rule would match first

the rules are correct. The problem is that ping goes

UDP bind to remote
then ICMP

the -i option supresses the UDP bind - which is why it works

First of all your priorities are definitely the wrong way around, try it please because I did.  We always use the policy with the lowest numerical priority value.  In any case, I failed to reproduce your problem with the upstream kernel, but it does happen in RHEL5.  So I'll try to find out what's broken it in RHEL5.

setkey inverts the priorities

as i said - the problem is that ping does a UDP bind first

I suspect that you fixed the kernel so that a UDP bind doesnt cause a flow setup until a packet is actually sent. On rhel5 the UDP bind triggers an acquire even though no packets are ever sent

here is the inversion

spdadd 192.168.218.0/24  192.168.218.0/24 any -P out priority 2 ipsec esp/transport//unique:1 
spdadd 192.168.218.0/24  192.168.218.0/24 any -P in priority 1 ipsec esp/transport//unique:2 

xfrm output

src 192.168.218.0/24 dst 192.168.218.0/24 
        dir in priority 2147483647 
        tmpl src 0.0.0.0 dst 0.0.0.0
                proto esp reqid 2 mode transport
src 192.168.218.0/24 dst 192.168.218.0/24 
        dir out priority 2147483646 
        tmpl src 0.0.0.0 dst 0.0.0.0
                proto esp reqid 1 mode transport

pri 1 rule gets xfrm pri = 2147483647 
pri 2 rule gets xfrm pri = 2147483646

I see why it works upstream.  It's because we added non-blocking IPsec route lookups so it just blows through.

Anyway, this really is a bug in ping.  Because the ideal state for the IPsec route lookup is for it to block, just like ARP.  If ping is going to use connect to do route lookups, it should specify the right protocol (which may be possible through RAW).  Alternatively it should just use netlink to get the information that it needs.

So we should reassign this away from the kernel because it's not doing anything wrong.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Red Hat Enterprise Linux 5 has entered Production 2 phase. For more details see https://access.redhat.com/support/policy/updates/errata/. As this bug is not qualified as critical, it is closed as WONTFIX.