Re: [PATCH]Re: NAT before IPsec with 2.6

[Patrick McHardy <kaber@trash.net>]

Patrick McHardy wrote:

>I see two problems with this approach. The dummy devices don't have
>  
>
>any ip config, so f.e. REDIRECT will fail. The bigger problem is
>  
>
>hooking in output routines that return NET_XMIT_BYPASS. dst_output
>  
>
>loops until the return code of skb->dst->output != NET_XMIT_BYPASS.
>  
>
>These output routines replace skb->dst when finished by calling dst_pop.
>  
>
>If we pass the packet through netfilter in between, the dst_entry
>  
>
>might get replaced in ip_route_me_harder or elsewhere and not all
>  
>
>transformations will be applied. If NAT is used,
>  
>
>ip_route_{input,output} might even return a different policy bundle.
>

Bad news, I've tested the hook part (using skb->dev instead of ah4/esp4
devices), this is how the traces look:

IN= OUT=eth0 SRC=172.20.0.3 DST=192.168.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=28443 SEQ=1
IN= OUT= SRC=172.20.0.3 DST=192.168.0.1 LEN=152 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ESP SPI=0xb9f7900
IN= OUT= SRC=172.20.0.3 DST=192.168.0.1 LEN=176 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=AH SPI=0xc46e27

After applying a MARK rule to the first packet (causing rerouting):

IN= OUT=eth0 SRC=172.20.0.3 DST=192.168.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=51484 SEQ=1

Sniffing in between shows the unencrypted packet.

>Regards,
>  
>
>Patrick
>  
>
>  
>
>