On 14 Nov 2016 12:50 am, "Pascal Hambourg" <pascal@plouf.fr.eu.org> wrote:
>
> Le 13/11/2016 à 13:37, Joe a écrit :
>>>
>>>
>>> PPTP rather falls into the "complex protocols" described below.
>>
>>
>> Exactly so. You wouldn't believe how many routers of ten years ago or
>> so didn't handle it properly, at least with their initial firmware. But
>
>
> Why wouldn't I ? Knowing how NAT is tricky, I am not surprised at all that the handling of "non standard" protocols (read : other than a single TCP or UDP connection) by many NAT systems is broken.
>
>
>> it still doesn't need any additional NAT rules in iptables, the single
>> SNAT rule handles it, as well as tcp, udp etc. Other rules are needed
>> for correct *operation*, but not for NAT.
>
>
> Proper NAT handling of a non standard protocol requires proper connection tracking, and both require additionnal conntrack/NAT helper modules.
> A security change in the conntrack/NAT helper management of recent kernels requires additionnal iptables rule to explicitly attach a helper to a connection. See the CT target.
>
> Without this, only simples cases may be handled correctly, when no more than one host behind the NAT communicates with the same outside host. Please read below.
>
>
>> Yes, I'm aware that NAT stops
>> plain IPSec working, as the endpoint IP addresses are involved in the
>> encryption. That isn't an iptables rule issue, and our single SNAT
>> rule will forward Protocol 47 and 50 just as easily as Protocol 6.
>
>
> Not as easily. IPSec protocols don't have ports, so SNAT cannot handle communications from several hosts behind the NAT device to the same host outside. The same applies to GRE without specific GRE handler support.
>
> Typical failure scenario :
>
> 1) Hosts A and B are behind the NAT router D and want to communicate with outside host C.
>
> 2) Host A sends a packet to host C through NAT router D. D changes the source address to its own and forwards the packet to C.
>
> 3) Host B sends a packet to host C through NAT router D. D changes the source address to its own and forwards the packet to C.
>
> 4) Host C sends a reply packet to NAT router D. Problem : there is nothing in the packet to tell D if it belongs to the connection initiated by A or B and if it must forward the packet to A or B. Communication failure. Actually netfilter conntrack detects the clash at stage 2) when B sends the initial packet to C, and discards the packet.
>
One can use NAT-T in that case.
> With protocols such as TCP or UDP, the conntrack/NAT can use source and destination ports to associate a packet with a known connection. But GRE or IPSec don't have ports. GRE packets have some kind of connection ID, but the standard netfilter NAT does not use it. So to avoid the failure in the above scenario, you must use the GRE conntrack/NAT helper modules. However there is no luck with IPSec.
>
>
>>> What is the "small-p sense" ?
>>
>>
>> In the sense of 'a defined system for data transfer', as opposed to the
>> Internet Protocols of tcp, udp, gre etc. http is spoken of as a
>> 'protocol', small-p, although it is a tiny subset of the tcp Internet
>> Protocol.
>
>
> I guess you mean "application layer protocol" such as HTTP or SSH as opposed to "network layer protocol" such as IP or ICMP and "transport layer protocol" such as TCP or UDP. I had never read this _expression_ before.
>