: Netfilter IPsec support
Subsystems (3)
cover : Netfilter IPsec support
This is the latest set patches for netfilter IPsec support. The use of netif_rx for the innermost SA if it used transport mode has been replaced by explicit NF_HOOK calls in xfrm{4,6}_input.c.
[NETFILTER]: Remove okfn usage in ip_vs_core.c
[NETFILTER]: Defer fragmentation in ip_output when connection tracking is used [IPV4]: Replace dst_output by ip_dst_output
[IPV6]: Replace dst_output by ip6_dst_output
[IPV4/6]: Netfilter IPsec output hooks
[IPV4/6]: Make input netfilter IPsec processing symetrical to output [NETFILTER]: Fix xfrm lookup in ip_route_me_harder
[NETFILTER]: Use conntrack information to determine if packet was NATed [NETFILTER]: Redo policy lookups after NAT when neccessary [NETFILTER]: Handle NAT in IPsec policy checks
David S. Miller
maintainerFrom: Patrick McHardy <[email protected]>
Date: Fri, 11 Nov 2005 04:18:52 +0100
Quoted 4 lines
This is the latest set patches for netfilter IPsec support. The use of
netif_rxfor the innermost SA if it used transport mode has been replaced by explicitNF_HOOKcalls in xfrm{4,6}_input.c.
Note that I consider this stuff 2.6.16 material.
We do have a lot of networking changes in 2.6.15 as it is, and also it would be good for these changes to get some review and discussion time.
Quoted 5 lines · David S. Miller
Note that I consider this stuff 2.6.16 material.
We do have a lot of networking changes in 2.6.15 as it is, and also it would be good for these changes to get some review and discussion time.
Sure, they will probably also need some changes for nf_conntrack. For now I'm happy if we can just agree on the way transport mode is handled.
Hi,
Quoted 4 lines
This is the latest set patches for netfilter IPsec support. The use of
netif_rxfor the innermost SA if it used transport mode has been replaced by explicitNF_HOOKcalls in xfrm{4,6}_input.c.
Could you please describe the solution you implemented a bit more? There was just so many back and forth that I'm confused now.
If I use it with iptables, do the transport mode packets go through INPUT and OUTPUT twice, decrypted and encrypted?
If I use it with iptables, do the tunnel mode packets go through FORWARD or INPUT and OUTPUT twice, decrypted and encrypted?
Can I do NAT in tunnel and transport mode?
what about the policy match patches, why are they only posted "for completeness" and as 11/12 of 10? Aren't they ready yet?
Thanks for enlightment.
Kind regards,
Gerd
Quoted 9 lines · Gerd v. Egidy
Hi,
Quoted 4 lines
This is the latest set patches for netfilter IPsec support. The use of
netif_rxfor the innermost SA if it used transport mode has been replaced by explicitNF_HOOKcalls in xfrm{4,6}_input.c.Could you please describe the solution you implemented a bit more? There was just so many back and forth that I'm confused now.
OK, some explanation. In tunnel mode, packets go through the stack again after decapsulation and hit the PRE_ROUTING and LOCAL_IN or FORWARD hook, depending on if it is a local packet or is forwarded. For symetry, there are now some additional hooks on the output path which pass the packet through LOCAL_OUT and POST_ROUTING after tunnel mode transforms. This part behaves just as any other tunnel. Transport mode is special, we usually don't want to see packets before or after transport mode transforms except if it was the plain text packet (the transport mode SA is the innermost SA of the bundle). On the output path this already works because packets always hit netfilter before reaching the transforms, on the input path packets are manually passed through PRE_ROUTING and INPUT in this case. For NAT we do two things:
when a packet is NATed after already beeing routed (including the xfrm lookup), it is routed again. If an incoming packet is NATed before the policy check, the policy check reconstructs how the packet looked before NAT.
Quoted 3 lines
If I use it with iptables, do the transport mode packets go through INPUT and OUTPUT twice, decrypted and encrypted?
Yes, if the transport mode transform in the innermost transform of the bundle (or the only one).
Quoted 3 lines
If I use it with iptables, do the tunnel mode packets go through FORWARD or INPUT and OUTPUT twice, decrypted and encrypted?
Yes.
Quoted 1 line
Can I do NAT in tunnel and transport mode?
Yes, even NATing forwarded packets and protecting them using a transport mode SA works.
Quoted 2 lines
what about the policy match patches, why are they only posted "for completeness" and as 11/12 of 10? Aren't they ready yet?
They should be fine.
How are handled NAT-T packets (udp/4500) with these patches?
Quoted 53 lines · Patrick McHardy
Quoted 9 lines · Gerd v. Egidy
Hi,
Quoted 4 lines
This is the latest set patches for netfilter IPsec support. The use of
netif_rxfor the innermost SA if it used transport mode has been replaced by explicitNF_HOOKcalls in xfrm{4,6}_input.c.Could you please describe the solution you implemented a bit more? There was just so many back and forth that I'm confused now.
OK, some explanation. In tunnel mode, packets go through the stack again after decapsulation and hit the
PRE_ROUTINGandLOCAL_INor FORWARD hook, depending on if it is a local packet or is forwarded. For symetry, there are now some additional hooks on the output path which pass the packet throughLOCAL_OUTandPOST_ROUTINGafter tunnel mode transforms. This part behaves just as any other tunnel. Transport mode is special, we usually don't want to see packets before or after transport mode transforms except if it was the plain text packet (the transport mode SA is the innermost SA of the bundle). On the output path this already works because packets always hit netfilter before reaching the transforms, on the input path packets are manually passed throughPRE_ROUTINGand INPUT in this case. For NAT we do two things:
when a packet is NATed after already beeing routed (including the xfrm lookup), it is routed again. If an incoming packet is NATed before the policy check, the policy check reconstructs how the packet looked before NAT.Quoted 3 lines
If I use it with iptables, do the transport mode packets go through INPUT and OUTPUT twice, decrypted and encrypted?
Yes, if the transport mode transform in the innermost transform of the bundle (or the only one).
Quoted 3 lines
If I use it with iptables, do the tunnel mode packets go through FORWARD or INPUT and OUTPUT twice, decrypted and encrypted?
Yes.
Quoted 1 line
Can I do NAT in tunnel and transport mode?
Yes, even NATing forwarded packets and protecting them using a transport mode SA works.
Quoted 2 lines
what about the policy match patches, why are they only posted "for completeness" and as 11/12 of 10? Aren't they ready yet?
They should be fine.
Quoted 1 line · Marco Berizzi
How are handled NAT-T packets (udp/4500) with these patches?
Instead of ESP packets you see the encapsulated UDP packets on the netfilter hooks:
(none):~# ping 10.0.0.1 -c 1 PING 10.0.0.1 (10.0.0.1): 56 data bytes OUTPUT IN= OUT=eth0 SRC=10.0.0.2 DST=10.0.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=16899 SEQ=0 POSTROUTING IN= OUT=eth0 SRC=10.0.0.2 DST=10.0.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=16899 SEQ=0
OUTPUT IN= OUT=eth0 SRC=10.0.0.2 DST=10.0.0.1 LEN=160 TOS=0x00 PREC=0x00 TTL=64 ID=256 DF PROTO=UDP SPT=4500 DPT=4500 LEN=140
POSTROUTING IN= OUT=eth0 SRC=10.0.0.2 DST=10.0.0.1 LEN=160 TOS=0x00 PREC=0x00 TTL=64 ID=256 DF PROTO=UDP SPT=4500 DPT=4500 LEN=140
PREROUTING IN=eth0 OUT= MAC=fe:fd:0a:00:00:02:36:ec:4f:25:dc:68:08:00 SRC=10.0.0.1 DST=10.0.0.2 LEN=160 TOS=0x00 PREC=0x00 TTL=64 ID=19709 PROTO=UDP SPT=4500 DPT=4500 LEN=140
INPUT IN=eth0 OUT= MAC=fe:fd:0a:00:00:02:36:ec:4f:25:dc:68:08:00 SRC=10.0.0.1 DST=10.0.0.2 LEN=160 TOS=0x00 PREC=0x00 TTL=64 ID=19709 PROTO=UDP SPT=4500 DPT=4500 LEN=140
PREROUTING IN=eth0 OUT= MAC=fe:fd:0a:00:00:02:36:ec:4f:25:dc:68:08:00 SRC=10.0.0.1 DST=10.0.0.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=19708 PROTO=ICMP TYPE=0 CODE=0 ID=16899 SEQ=0
INPUT IN=eth0 OUT= MAC=fe:fd:0a:00:00:02:36:ec:4f:25:dc:68:08:00 SRC=10.0.0.1 DST=10.0.0.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=19708 PROTO=ICMP TYPE=0 CODE=0 ID=16899 SEQ=0
64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=25.9 ms