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

Groups > linux.debian.user > #174611 > unrolled thread

iptables question

Back to article view | Back to linux.debian.user

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#174685

Igor Cicimov wrote:

> Run tcpdump and check whats happening

That is strange - I will look into this direction - let me know if you have
any ideas

regards


tcpdump -vvv dst 10.0.0.7
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535
bytes
08:07:11.591763 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has RM696
tell 10.0.0.1, length 28
08:07:12.591729 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has RM696
tell 10.0.0.1, length 28
08:07:13.591686 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has RM696
tell 10.0.0.1, length 28
08:07:14.595695 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has RM696
tell 10.0.0.1, length 28
08:07:15.595632 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has RM696
tell 10.0.0.1, length 28
08:07:16.595620 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has RM696
tell 10.0.0.1, length 28



tcpdump -vvv dst 10.0.0.138
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535
bytes
08:04:55.765744 IP (tos 0x0, ttl 63, id 26002, offset 0, flags [DF], proto
TCP (6), length 60)
    10.0.0.1.52112 > 10.0.0.138.ssh: Flags [S], cksum 0xc2c6 (correct), seq
2408995280, win 29200, options [mss 1460,sackOK,TS val 223296578 ecr
0,nop,wscale 7], length 0
08:04:55.767594 IP (tos 0x0, ttl 63, id 26003, offset 0, flags [DF], proto
TCP (6), length 40)
    10.0.0.1.52112 > 10.0.0.138.ssh: Flags [.], cksum 0x242c (correct), seq
2408995281, ack 3147433360, win 229, length 0
08:04:55.772423 IP (tos 0x0, ttl 63, id 44890, offset 0, flags [none], proto
UDP (17), length 69)
    10.0.0.1.24455 > 10.0.0.138.domain: [udp sum ok] 7454+ PTR?
138.0.0.10.in-addr.arpa. (41)
08:04:55.774778 IP (tos 0x0, ttl 63, id 26004, offset 0, flags [DF], proto
TCP (6), length 79)
    10.0.0.1.52112 > 10.0.0.138.ssh: Flags [P.], cksum 0xfb15 (correct), seq
0:39, ack 1, win 229, length 39
08:04:55.787360 IP (tos 0x0, ttl 63, id 26005, offset 0, flags [DF], proto
TCP (6), length 40)
    10.0.0.1.52112 > 10.0.0.138.ssh: Flags [.], cksum 0x23eb (correct), seq
39, ack 27, win 229, length 0
08:04:55.789504 IP (tos 0x0, ttl 63, id 26006, offset 0, flags [DF], proto
TCP (6), length 1500)
    10.0.0.1.52112 > 10.0.0.138.ssh: Flags [.], cksum 0x7c86 (correct), seq
39:1499, ack 27, win 229, length 1460
08:04:55.789680 IP (tos 0x0, ttl 63, id 26007, offset 0, flags [DF], proto
TCP (6), length 228)
    10.0.0.1.52112 > 10.0.0.138.ssh: Flags [P.], cksum 0x46dd (correct), seq
1499:1687, ack 27, win 229, length 188
08:04:55.791326 IP (tos 0x0, ttl 63, id 26008, offset 0, flags [DF], proto
TCP (6), length 312)
    10.0.0.1.52112 > 10.0.0.138.ssh: Flags [P.], cksum 0xb0d6 (correct), seq
1687:1959, ack 339, win 237, length 272
08:04:55.796226 IP (tos 0x0, ttl 63, id 44893, offset 0, flags [none], proto
UDP (17), length 67)
    10.0.0.1.63625 > 10.0.0.138.domain: [udp sum ok] 17121+ PTR?
1.0.0.10.in-addr.arpa. (39)
08:04:58.223139 IP (tos 0x0, ttl 63, id 26009, offset 0, flags [DF], proto
TCP (6), length 56)
    10.0.0.1.52112 > 10.0.0.138.ssh: Flags [P.], cksum 0x0ea9 (correct), seq
1959:1975, ack 915, win 246, length 16

[toc] | [prev] | [next] | [standalone]

#174687

deloptes wrote:

> Igor Cicimov wrote:
> 
>> Run tcpdump and check whats happening
> 
> That is strange - I will look into this direction - let me know if you
> have any ideas
> 
> regards
> 
> 
> tcpdump -vvv dst 10.0.0.7
> tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size
> 65535 bytes
> 08:07:11.591763 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has RM696
> tell 10.0.0.1, length 28
> 08:07:12.591729 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has RM696
> tell 10.0.0.1, length 28
> 08:07:13.591686 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has RM696
> tell 10.0.0.1, length 28
> 08:07:14.595695 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has RM696
> tell 10.0.0.1, length 28
> 08:07:15.595632 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has RM696
> tell 10.0.0.1, length 28
> 08:07:16.595620 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has RM696
> tell 10.0.0.1, length 28
> 
> 
> 
> tcpdump -vvv dst 10.0.0.138
> tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size
> 65535 bytes
> 08:04:55.765744 IP (tos 0x0, ttl 63, id 26002, offset 0, flags [DF], proto
> TCP (6), length 60)
>     10.0.0.1.52112 > 10.0.0.138.ssh: Flags [S], cksum 0xc2c6 (correct),
>     seq
> 2408995280, win 29200, options [mss 1460,sackOK,TS val 223296578 ecr
> 0,nop,wscale 7], length 0
> 08:04:55.767594 IP (tos 0x0, ttl 63, id 26003, offset 0, flags [DF], proto
> TCP (6), length 40)
>     10.0.0.1.52112 > 10.0.0.138.ssh: Flags [.], cksum 0x242c (correct),
>     seq
> 2408995281, ack 3147433360, win 229, length 0
> 08:04:55.772423 IP (tos 0x0, ttl 63, id 44890, offset 0, flags [none],
> proto UDP (17), length 69)
>     10.0.0.1.24455 > 10.0.0.138.domain: [udp sum ok] 7454+ PTR?
> 138.0.0.10.in-addr.arpa. (41)
> 08:04:55.774778 IP (tos 0x0, ttl 63, id 26004, offset 0, flags [DF], proto
> TCP (6), length 79)
>     10.0.0.1.52112 > 10.0.0.138.ssh: Flags [P.], cksum 0xfb15 (correct),
>     seq
> 0:39, ack 1, win 229, length 39
> 08:04:55.787360 IP (tos 0x0, ttl 63, id 26005, offset 0, flags [DF], proto
> TCP (6), length 40)
>     10.0.0.1.52112 > 10.0.0.138.ssh: Flags [.], cksum 0x23eb (correct),
>     seq
> 39, ack 27, win 229, length 0
> 08:04:55.789504 IP (tos 0x0, ttl 63, id 26006, offset 0, flags [DF], proto
> TCP (6), length 1500)
>     10.0.0.1.52112 > 10.0.0.138.ssh: Flags [.], cksum 0x7c86 (correct),
>     seq
> 39:1499, ack 27, win 229, length 1460
> 08:04:55.789680 IP (tos 0x0, ttl 63, id 26007, offset 0, flags [DF], proto
> TCP (6), length 228)
>     10.0.0.1.52112 > 10.0.0.138.ssh: Flags [P.], cksum 0x46dd (correct),
>     seq
> 1499:1687, ack 27, win 229, length 188
> 08:04:55.791326 IP (tos 0x0, ttl 63, id 26008, offset 0, flags [DF], proto
> TCP (6), length 312)
>     10.0.0.1.52112 > 10.0.0.138.ssh: Flags [P.], cksum 0xb0d6 (correct),
>     seq
> 1687:1959, ack 339, win 237, length 272
> 08:04:55.796226 IP (tos 0x0, ttl 63, id 44893, offset 0, flags [none],
> proto UDP (17), length 67)
>     10.0.0.1.63625 > 10.0.0.138.domain: [udp sum ok] 17121+ PTR?
> 1.0.0.10.in-addr.arpa. (39)
> 08:04:58.223139 IP (tos 0x0, ttl 63, id 26009, offset 0, flags [DF], proto
> TCP (6), length 56)
>     10.0.0.1.52112 > 10.0.0.138.ssh: Flags [P.], cksum 0x0ea9 (correct),
>     seq
> 1959:1975, ack 915, win 246, length 16



My wife turned off the wireless

08:59:06.127029 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has RM696
tell 10.0.0.1, length 28
08:59:06.202411 IP (tos 0x0, ttl 63, id 50126, offset 0, flags [DF], proto
TCP (6), length 60)
    10.0.0.1.34912 > RM696.ssh: Flags [S], cksum 0x5a12 (correct), seq
3855619686, win 29200, options [mss 1460,sackOK,TS val 226547112 ecr
0,nop,wscale 7], length 0
08:59:07.172012 IP (tos 0x0, ttl 63, id 50127, offset 0, flags [DF], proto
TCP (6), length 60)
    10.0.0.1.34912 > RM696.ssh: Flags [S], cksum 0x55fa (correct), seq
3855619686, win 29200, options [mss 1460,sackOK,TS val 226548160 ecr
0,nop,wscale 7], length 0
08:59:09.219907 IP (tos 0x0, ttl 63, id 50128, offset 0, flags [DF], proto
TCP (6), length 60)
    10.0.0.1.34912 > RM696.ssh: Flags [S], cksum 0x4dfa (correct), seq
3855619686, win 29200, options [mss 1460,sackOK,TS val 226550208 ecr
0,nop,wscale 7], length 0
08:59:13.251697 IP (tos 0x0, ttl 63, id 50129, offset 0, flags [DF], proto
TCP (6), length 60)
    10.0.0.1.34912 > RM696.ssh: Flags [S], cksum 0x3e3a (correct), seq
3855619686, win 29200, options [mss 1460,sackOK,TS val 226554240 ecr
0,nop,wscale 7], length 0
08:59:21.571248 IP (tos 0x0, ttl 63, id 50130, offset 0, flags [DF], proto
TCP (6), length 60)
    10.0.0.1.34912 > RM696.ssh: Flags [S], cksum 0x1dba (correct), seq
3855619686, win 29200, options [mss 1460,sackOK,TS val 226562560 ecr
0,nop,wscale 7], length 0
08:59:37.954393 IP (tos 0x0, ttl 63, id 50131, offset 0, flags [DF], proto
TCP (6), length 60)
    10.0.0.1.34912 > RM696.ssh: Flags [S], cksum 0xddb9 (correct), seq
3855619686, win 29200, options [mss 1460,sackOK,TS val 226578944 ecr
0,nop,wscale 7], length 0
09:00:10.208566 IP (tos 0x0, ttl 63, id 50132, offset 0, flags [DF], proto
TCP (6), length 60)
    10.0.0.1.34912 > RM696.ssh: Flags [S], cksum 0x5fb9 (correct), seq
3855619686, win 29200, options [mss 1460,sackOK,TS val 226611200 ecr
0,nop,wscale 7], length 0
09:00:15.205453 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has RM696
tell 10.0.0.1, length 28

[toc] | [prev] | [next] | [standalone]

#174628

Le 12/11/2016 à 23:32, Joe a écrit :
>
> The SNAT should not be an issue, it can handle all protocols
> transparently

No it cannot. NAT is not possible with some IP protocols. Plain IPSec 
(without NAT-T encapsulation) is the first one that comes in mind.

Also many complex protocols such as FTP or SIP (nothing exotic here) 
require special support and this is not transparent as it requires 
messing with the payload, not only with the packet headers. Use of 
encryption with these protocoles may come in the way and defeat NAT 
handling.

[toc] | [prev] | [next] | [standalone]

#174631

On Sun, 13 Nov 2016 10:35:29 +0100
Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:

> Le 12/11/2016 à 23:32, Joe a écrit :
> >
> > The SNAT should not be an issue, it can handle all protocols
> > transparently  
> 
> No it cannot. NAT is not possible with some IP protocols. Plain IPSec 
> (without NAT-T encapsulation) is the first one that comes in mind.

I used to have a fair bit to do with PPTP through three or four NATs,
which sometimes involved guessing what Windows equivalents of conntrack
were up to.

> 
> Also many complex protocols such as FTP or SIP (nothing exotic here) 
> require special support and this is not transparent as it requires 
> messing with the payload, not only with the packet headers. Use of 
> encryption with these protocoles may come in the way and defeat NAT 
> handling.

Is ssh really a more difficult protocol to handle than http? In the
context of this question, I would suggest not. I'm using 'protocol' in
the small-p sense, not referring specifically to Internet Protocols.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#174633

Le 13/11/2016 à 11:09, Joe a écrit :
> Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
>
>> Le 12/11/2016 à 23:32, Joe a écrit :
>>>
>>> The SNAT should not be an issue, it can handle all protocols
>>> transparently
>>
>> No it cannot. NAT is not possible with some IP protocols. Plain IPSec
>> (without NAT-T encapsulation) is the first one that comes in mind.
>
> I used to have a fair bit to do with PPTP through three or four NATs,

PPTP rather falls into the "complex protocols" described below.

>> Also many complex protocols such as FTP or SIP (nothing exotic here)
>> require special support and this is not transparent as it requires
>> messing with the payload, not only with the packet headers. Use of
>> encryption with these protocoles may come in the way and defeat NAT
>> handling.
>
> Is ssh really a more difficult protocol to handle than http?

No. SSH relies on a single TCP connection, like TCP and other "simple" 
protocols. I reacted to you writing "NAT can handle *all* protocols 
*transparently*".

> I'm using 'protocol' in
> the small-p sense, not referring specifically to Internet Protocols.

What is the "small-p sense" ?

[toc] | [prev] | [next] | [standalone]

#174642

On Sun, 13 Nov 2016 11:29:48 +0100
Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:

> Le 13/11/2016 à 11:09, Joe a écrit :
> > Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> >  
> >> Le 12/11/2016 à 23:32, Joe a écrit :  
> >>>
> >>> The SNAT should not be an issue, it can handle all protocols
> >>> transparently  
> >>
> >> No it cannot. NAT is not possible with some IP protocols. Plain
> >> IPSec (without NAT-T encapsulation) is the first one that comes in
> >> mind.  
> >
> > I used to have a fair bit to do with PPTP through three or four
> > NATs,  
> 
> 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
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. 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.

> 
> >> Also many complex protocols such as FTP or SIP (nothing exotic
> >> here) require special support and this is not transparent as it
> >> requires messing with the payload, not only with the packet
> >> headers. Use of encryption with these protocoles may come in the
> >> way and defeat NAT handling.  
> >
> > Is ssh really a more difficult protocol to handle than http?  
> 
> No. SSH relies on a single TCP connection, like TCP and other
> "simple" protocols. I reacted to you writing "NAT can handle *all*
> protocols *transparently*".
> 
> > I'm using 'protocol' in
> > the small-p sense, not referring specifically to Internet
> > Protocols.  
> 
> 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. Many people used to confuse tcp port 47 with IP 47, to the
extent that some router firmware would forward IP 47 if asked for
tcp/47, which only perpetuated the confusion.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#174651

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.

[toc] | [prev] | [next] | [standalone]

#174682

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web