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.
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.
