noel at familie-kuntze.de
Tue Oct 18 21:29:27 CEST 2016
On 18.10.2016 21:27, Noel Kuntze wrote:
> Hello Brian,
> On 18.10.2016 21:05, Brian O'Connor wrote:
>> > 1. Where in the diagram is NAT-T de-capsulation performed?
> XFRM lookup.
Err actually xfrm decode.
>> > 2. Where in the diagram is NAT-T encapsulation performed?
> XFRM lookup.
actually xfrm encode.
>> > 3. Does the NAT-T UDP header have to be removed so the iptables IPsec policy module can operate?
> Nope. This question sound suspiciously like you want to check if an ESP/NAT-T packet has a matching policy.
> XFRM does that for you. IPsec policies also work the other way around. They don't just only allow protected traffic
> to or from an IP address, they also implicitely drop unprotected matching datagrams. The kernel will and does also efficiently drop
> spoofed ESP packets. The system design is sound. There's no reason to try to protect the kernel from invalid ESP packets.
>> > 4. Traffic from the topmost "local process" block flows to a "routing decision" block. Is this to prevent
>> > a local IPsec connection (to loopback address, possibly ) from being encrypted?
> No, it's just there to fill in required routing information into the skb in the kernel.
> XFRM is disabled on loopback via a sysctl value. You can enable it, if you want, but that makes no sense
> and there's no need for that.
>> >  http://inai.de/images/nf-packet-flow.png
>> > TIA,
>> > Brian
> -- Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
> Users mailing list
> Users at lists.strongswan.org
Mit freundlichen Grüßen/Kind Regards,
GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the Users