Re: [strongSwan] Diagram
On 18.10.2016 22:11, Brian O'Connor wrote: > > So, for forwarded traffic (as distinct from locally source packets), I > understand the packet to > flow through the mangle and nat postrouting chains twice, and the other > iptables > output chains for raw, mangle, nat and filter tables only once after > encryption. That depends on where the packet originally came from. If it comes in an ESP/NAT-T packet, it circulates through the INPUT PATH two times (Once as ESP/NAT-T packet and once as unprotected packet). If it is an unprotected packet, it only goes through INPUT path once (as unproteced packet). > On the first pass through the mangle and nat postrouting chains, iptables > rules would > operate on the unencrypted payload packet and on the second pass on the IP > headers of > the encrypted IPsec packet. If the packet matches an IPsec policy with OUTPUT flag set, then yes. We need to strongly differentiate in this discussion where the packet actually comes from and where it goes to (If it was/is in an ESP/NAT-T/AH packet, if there is a matching INPUT policy for it in the SAD and SPD and analog if it's a packet that is going to protected with IPsec (that is, if there's a matching policy in the SPD for it with the correct mode and if it's a policy that has the correct mode). A packet that goes through netfilter *4* times would be a packet that is received as an ESP/NAT-T/AH packet, has a matching SA and SP, is allowed by your netfilter rules, is locally decapsulated, routed, encapsulated and allowed again and then sent to another host again. -- Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 signature.asc Description: OpenPGP digital signature ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Diagram
Noel, I note your last message clearly emphasised that packets from a local process are processed twice via the output path of the graphic. So, for forwarded traffic (as distinct from locally source packets), I understand the packet to flow through the mangle and nat postrouting chains twice, and the other iptables output chains for raw, mangle, nat and filter tables only once after encryption. On the first pass through the mangle and nat postrouting chains, iptables rules would operate on the unencrypted payload packet and on the second pass on the IP headers of the encrypted IPsec packet. Am I headed in the right direction please? Brian ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Diagram
On 18.10.2016 21:43, Brian O'Connor wrote: > I think I have the decryption process clear but was not clear on the iptables > processing for > encrypted packets. From what you said, it looks like the NAT-T header is > added after the > iptables processing of an outbound encrypted packet, on the second pass by the > outbound XFRM lookup. Is my understanding correct? ESP encapsulation and NAT-T are applied in a single step when the packet is processed in xfrm encode. Generally, a packet that is sent *from a local process* and is to be protected with IPsec makes two passes through the OUTPUT PATH part of the graphic: 1) When it is sent by the process and passed through the chains and other parts of Netfilter in the path, until it is catched by xfrm lookup and is fed into xfrm encode. 2) When it is passed from xfrm encode into *raw OUTPUT. When that happens, the original packet that was sent by the kernel is transformed by xfrm into an ESP or NAT-T packet (That is simply ESP in a UDP shell. Nothing fancy about that.) It then traverses through the Netfilter chains as an ESP or UDP packet through the chains and other parts of Netfilter until it reaches egress (qdisc). -- Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 signature.asc Description: OpenPGP digital signature ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Diagram
Thank you, Noel. I am trying to understand how the inner and outer IP headers for tunneled IPsec packets are processed by iptables, to help troubleshoot an anomalous situation I found. I think I have the decryption process clear but was not clear on the iptables processing for encrypted packets. From what you said, it looks like the NAT-T header is added after the iptables processing of an outbound encrypted packet, on the second pass by the outbound XFRM lookup. Is my understanding correct? TIA, Brian ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Diagram
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. > >> > >> > [1] 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@lists.strongswan.org > https://lists.strongswan.org/mailman/listinfo/users > -- Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 signature.asc Description: OpenPGP digital signature ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Diagram
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. > > 2. Where in the diagram is NAT-T encapsulation performed? XFRM lookup. > > 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. > > [1] 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 signature.asc Description: OpenPGP digital signature ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Diagram
Hello, The commonly quoted packet flow diagram at [1] does not show where NAT-T is implemented for IPsec MOBIKE. Questions are: 1. Where in the diagram is NAT-T de-capsulation performed? 2. Where in the diagram is NAT-T encapsulation performed? 3. Does the NAT-T UDP header have to be removed so the iptables IPsec policy module can operate? 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? [1] http://inai.de/images/nf-packet-flow.png TIA, Brian ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
