Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #174651

Re: iptables question

Show all headers | View raw

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.

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

iptables question deloptes <deloptes@gmail.com> - 2016-11-12 22:20 +0100
  Re: iptables question Joe <joe@jretrading.com> - 2016-11-12 23:40 +0100
    Re: iptables question deloptes <deloptes@gmail.com> - 2016-11-13 01:30 +0100
      Re: iptables question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-13 10:50 +0100
      Re: iptables question Michael Milliman <michael.e.milliman@gmail.com> - 2016-11-13 12:40 +0100
        Re: iptables question deloptes <deloptes@gmail.com> - 2016-11-13 16:10 +0100
          Re: iptables question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-13 18:00 +0100
            Re: iptables question deloptes <deloptes@gmail.com> - 2016-11-13 20:50 +0100
              Re: iptables question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-13 21:20 +0100
                Re: iptables question deloptes <deloptes@gmail.com> - 2016-11-13 21:50 +0100
                Re: iptables question Henning <henning@itcfollmann.com> - 2016-11-13 22:50 +0100
                Re: iptables question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-13 23:30 +0100
                Re: iptables question Henning <henning@itcfollmann.com> - 2016-11-14 00:30 +0100
                Re: iptables question deloptes <deloptes@gmail.com> - 2016-11-14 00:50 +0100
                Re: iptables question Henning Follmann <hfollmann@itcfollmann.com> - 2016-11-14 13:10 +0100
                Re: iptables question deloptes <deloptes@gmail.com> - 2016-11-14 20:20 +0100
                Re: iptables question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-13 23:30 +0100
                Re: iptables question deloptes <deloptes@gmail.com> - 2016-11-14 01:00 +0100
                Re: iptables question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-14 23:10 +0100
      Re: iptables question Igor Cicimov <icicimov@gmail.com> - 2016-11-14 03:10 +0100
        Re: iptables question deloptes <deloptes@gmail.com> - 2016-11-14 08:20 +0100
          Re: iptables question deloptes <deloptes@gmail.com> - 2016-11-14 09:10 +0100
    Re: iptables question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-13 10:40 +0100
      Re: iptables question Joe <joe@jretrading.com> - 2016-11-13 11:10 +0100
        Re: iptables question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-13 11:40 +0100
          Re: iptables question Joe <joe@jretrading.com> - 2016-11-13 13:40 +0100
            Re: iptables question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-13 15:00 +0100
              Re: iptables question Igor Cicimov <icicimov@gmail.com> - 2016-11-14 03:00 +0100

csiph-web