Peter Bieringer wrote:
Does this patch fix the problem ?
Yes, this patch fix the problem on the incoming side:
Thanks.
I ping6 to a remote host via IPsec in transport mode:
IPv6 INPUT chain:
0 0 ACCEPT icmpv6 * * ::/0 ::/0
ipv6-icmp type 128
0 0 ACCEPT icmpv6 * * ::/0 ::/0
ipv6-icmp type 129
1 156 ACCEPT esp * * remote/128 local/128
0 0 ACCEPT all * * remote/128 local/128
So the proper chain matches.
But I wonder a little bit because of the result of the OUTPUT chain:
0 0 ACCEPT icmpv6 * * ::/0 ::/0
ipv6-icmp type 129
1 104 ACCEPT icmpv6 * * ::/0 ::/0
ipv6-icmp type 128
0 0 ACCEPT esp * * local/128 remote/128
0 0 ACCEPT all * * local/128 remote/128
Here, the ICMPv6 rule matches.
This means for me that the traffic goes like this:
OUTPUT: ping6 -> netfilter -> encryption -> ESP
INPUT : ESP -> netfilter -> decryption -> ping6
More specific, with transport mode it goes:
OUTPUT: ping6 -> LOCAL_OUT -> encryption -> POST_ROUTING
INPUT: ESP -> PRE_ROUTING -> LOCAL_IN -> decryption -> ping6
Filtering for IPv6 happens on LOCAL_IN/LOCAL_OUT (and FORWARD).
Is this logical?
Not very. Patches to improve this for IPv4 will be submitted
next week, but IPv6 still needs some work.
BTW: how to filter incoming traffic after decryption?
Use tunnel-mode. The decrypted packets will hit PRE_ROUTING
and LOCAL_IN again.
Regards
Patrick
|