full_cone_nat

full_cone_nat

[Hugo Miguel Mendes]

Dear all,
I'm going to try to develop a Full Cone NAT feature to iptables.
Can you tell me where can I find in the source code the function or functions responsible for checking the matching table of active connections present in the file ip_conntrack.

Best Regards

Hugo Mendes

Re: full_cone_nat

[Jan Engelhardt]

On Tuesday 2009-04-07 16:42, Hugo Miguel Mendes wrote:

>Dear all,
>I'm going to try to develop a Full Cone NAT feature to iptables.


Another?

RE: full_cone_nat

[Hugo Miguel Mendes]

What do you mean with "Another?"

Hugo Mendes

IAD - Investigação Aplicada e Difusão do Conhecimento.
PT Inovação S.A.
Rua Engº José Fereira Pinto Basto 3810-106 Aveiro
Telefone: +351964400206
E-mail: est-h-mendes@ptinovacao.pt
________________________________________
De: jengelh@sovereign.computergmbh.de [jengelh@sovereign.computergmbh.de] Em Nome De Jan Engelhardt [jengelh@medozas.de]
Enviado: terça-feira, 7 de Abril de 2009 16:27
Para: Hugo Miguel Mendes
Cc: netfilter-devel@vger.kernel.org
Assunto: Re: full_cone_nat

On Tuesday 2009-04-07 16:42, Hugo Miguel Mendes wrote:

>Dear all,
>I'm going to try to develop a Full Cone NAT feature to iptables.


Another?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: full_cone_nat

[Jan Engelhardt]

On Tuesday 2009-04-07 17:28, Hugo Miguel Mendes wrote:

>What do you mean with "Another?"


You can already do full cone with Netfilter.

RE: full_cone_nat

[Hugo Miguel Mendes]

As long as I know iptables is port-restricted NAT, how can you do full cone nat on that?

Hugo Mendes
________________________________________
De: jengelh@sovereign.computergmbh.de [jengelh@sovereign.computergmbh.de] Em Nome De Jan Engelhardt [jengelh@medozas.de]
Enviado: terça-feira, 7 de Abril de 2009 16:31
Para: Hugo Miguel Mendes
Cc: netfilter-devel@vger.kernel.org
Assunto: RE: full_cone_nat

On Tuesday 2009-04-07 17:28, Hugo Miguel Mendes wrote:

>What do you mean with "Another?"


You can already do full cone with Netfilter.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: full_cone_nat

[Hugo Miguel Mendes]

What I mean with Full Cone NAT is the following:

1. A packet is sent from a machine in the LAN from Address1:port100 to a machine in the WAN with Address3:port200, the NAT converts the local Address1:port100 to Address2:port100 which is the address assigned to the home router by the ISP. So this packet is sent with source: Address2:port100 and destination: Address3:port200.
2. The packet received by the machine in the WAN in 1) is processed and then the answer comes from a different machine with a different address but using the same ports. So the response packet is sent by Address4:port200 to Address2:port100. So this packet has source: Address4:port200 and destination: Address2:port100.
3. When the home router receives the response packet it has to ignore the sending address in the matching table, so that all traffic received in Address2:port100 is simply forward to Address1:port100. This is just a Full Cone NAT.

I have read some tutorials about iptables and the only way I have found to do this is make rule that forwards all traffic that arrives in Address2:port100 to Address1:port100. This does the work for just one machine on the LAN which has a static ip and will always contact the same machine on the WAN.
What I really want to do is implement a Full Cone NAT in which a packet sent from Address1:port100 which is translated to Address2:port100 by the NAT and goes to Address3:port200, activates port100 in the home router so that any packets arriving in port100 will be forwarded to Address1:por100. And this would just work for any number of machines.

Best Regards

Hugo Mendes
________________________________________
De: netfilter-devel-owner@vger.kernel.org [netfilter-devel-owner@vger.kernel.org] Em Nome De Hugo Miguel Mendes
Enviado: terça-feira, 7 de Abril de 2009 16:32
Para: Jan Engelhardt
Cc: netfilter-devel@vger.kernel.org
Assunto: RE: full_cone_nat

As long as I know iptables is port-restricted NAT, how can you do full cone nat on that?

Hugo Mendes
________________________________________
De: jengelh@sovereign.computergmbh.de [jengelh@sovereign.computergmbh.de] Em Nome De Jan Engelhardt [jengelh@medozas.de]
Enviado: terça-feira, 7 de Abril de 2009 16:31
Para: Hugo Miguel Mendes
Cc: netfilter-devel@vger.kernel.org
Assunto: RE: full_cone_nat

On Tuesday 2009-04-07 17:28, Hugo Miguel Mendes wrote:

>What do you mean with "Another?"


You can already do full cone with Netfilter.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: full_cone_nat

[Jozsef Kadlecsik]

On Tue, 7 Apr 2009, Hugo Miguel Mendes wrote:

> What I mean with Full Cone NAT is the following:
> 
> 1. A packet is sent from a machine in the LAN from Address1:port100 to a 
> machine in the WAN with Address3:port200, the NAT converts the local 
> Address1:port100 to Address2:port100 which is the address assigned to 
> the home router by the ISP. So this packet is sent with source: 
> Address2:port100 and destination: Address3:port200.
> 2. The packet received by the machine in the WAN in 1) is processed and 
> then the answer comes from a different machine with a different address 
> but using the same ports. So the response packet is sent by 
> Address4:port200 to Address2:port100. So this packet has source: 
> Address4:port200 and destination: Address2:port100.
> 3. When the home router receives the response packet it has to ignore 
> the sending address in the matching table, so that all traffic received 
> in Address2:port100 is simply forward to Address1:port100. This is just 
> a Full Cone NAT.

I answered you on Thu, 2 Apr 2009 when you asked the same question on
the netfilter mailing list. The answer hasn't changed since then: 
currently there's no way to create full cone NAT.

It might be possible to write a new full cone NAT target by creating 
wildcard expectations.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

RE: full_cone_nat

[Jan Engelhardt]

On Tuesday 2009-04-07 20:16, Jozsef Kadlecsik wrote:
>On Tue, 7 Apr 2009, Hugo Miguel Mendes wrote:
>
>> What I mean with Full Cone NAT is the following:
>>[...]
>
>I answered you on Thu, 2 Apr 2009 when you asked the same question on
>the netfilter mailing list. The answer hasn't changed since then: 
>currently there's no way to create full cone NAT.
>
>It might be possible to write a new full cone NAT target by creating 
>wildcard expectations.

Yeah there is a case where cone nat does not quite work. Assuming there
are the following mappings:

origsrc=192.168.17.2 origdst=80.10.20.30 replsrc=134.98.76.54 repldst=80.10.20.30
origsrc=192.168.17.3 origdst=80.20.30.40 replsrc=134.98.76.54 repldst=80.20.30.40

Then there is no way to ambiguously map incoming IP_CT_NEW connections
for 134.98.76.54 to an origsrc.

RE: full_cone_nat

[Jozsef Kadlecsik]

On Tue, 7 Apr 2009, Jan Engelhardt wrote:

> 
> On Tuesday 2009-04-07 20:16, Jozsef Kadlecsik wrote:
> >On Tue, 7 Apr 2009, Hugo Miguel Mendes wrote:
> >
> >> What I mean with Full Cone NAT is the following:
> >>[...]
> >
> >I answered you on Thu, 2 Apr 2009 when you asked the same question on
> >the netfilter mailing list. The answer hasn't changed since then: 
> >currently there's no way to create full cone NAT.
> >
> >It might be possible to write a new full cone NAT target by creating 
> >wildcard expectations.
> 
> Yeah there is a case where cone nat does not quite work. Assuming there
> are the following mappings:
> 
> origsrc=192.168.17.2 origdst=80.10.20.30 replsrc=134.98.76.54 repldst=80.10.20.30
> origsrc=192.168.17.3 origdst=80.20.30.40 replsrc=134.98.76.54 repldst=80.20.30.40
> 
> Then there is no way to ambiguously map incoming IP_CT_NEW connections
> for 134.98.76.54 to an origsrc.

Yes, full cone NAT can easily break connections or at least is should 
reject the second, overlapping connection for the joy of the user. But if 
someone insists and want to shoot himself in the foot, then by creating 
expectations it might be create full cone NAT.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

RE: full_cone_nat

[Hugo Miguel Mendes]

Thanks for the tip :) I hadn't seen your answe in the other mailing list.
My original question in this mailing list is:

Can you tell me where can I find in the source code the function or functions responsible for checking the matching table of active connections present in the file ip_conntrack.

Hugo Mendes
________________________________________
De: Jozsef Kadlecsik [kadlec@blackhole.kfki.hu]
Enviado: terça-feira, 7 de Abril de 2009 19:32
Para: Jan Engelhardt
Cc: Hugo Miguel Mendes; netfilter-devel@vger.kernel.org
Assunto: RE: full_cone_nat

On Tue, 7 Apr 2009, Jan Engelhardt wrote:

>
> On Tuesday 2009-04-07 20:16, Jozsef Kadlecsik wrote:
> >On Tue, 7 Apr 2009, Hugo Miguel Mendes wrote:
> >
> >> What I mean with Full Cone NAT is the following:
> >>[...]
> >
> >I answered you on Thu, 2 Apr 2009 when you asked the same question on
> >the netfilter mailing list. The answer hasn't changed since then:
> >currently there's no way to create full cone NAT.
> >
> >It might be possible to write a new full cone NAT target by creating
> >wildcard expectations.
>
> Yeah there is a case where cone nat does not quite work. Assuming there
> are the following mappings:
>
> origsrc=192.168.17.2 origdst=80.10.20.30 replsrc=134.98.76.54 repldst=80.10.20.30
> origsrc=192.168.17.3 origdst=80.20.30.40 replsrc=134.98.76.54 repldst=80.20.30.40
>
> Then there is no way to ambiguously map incoming IP_CT_NEW connections
> for 134.98.76.54 to an origsrc.

Yes, full cone NAT can easily break connections or at least is should
reject the second, overlapping connection for the joy of the user. But if
someone insists and want to shoot himself in the foot, then by creating
expectations it might be create full cone NAT.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: full_cone_nat

[Amos Jeffries]

Jan Engelhardt wrote:
> On Tuesday 2009-04-07 20:16, Jozsef Kadlecsik wrote:
>> On Tue, 7 Apr 2009, Hugo Miguel Mendes wrote:
>>
>>> What I mean with Full Cone NAT is the following:
>>> [...]
>> I answered you on Thu, 2 Apr 2009 when you asked the same question on
>> the netfilter mailing list. The answer hasn't changed since then: 
>> currently there's no way to create full cone NAT.
>>
>> It might be possible to write a new full cone NAT target by creating 
>> wildcard expectations.
> 
> Yeah there is a case where cone nat does not quite work. Assuming there
> are the following mappings:
> 
> origsrc=192.168.17.2 origdst=80.10.20.30 replsrc=134.98.76.54 repldst=80.10.20.30
> origsrc=192.168.17.3 origdst=80.20.30.40 replsrc=134.98.76.54 repldst=80.20.30.40
> 
> Then there is no way to ambiguously map incoming IP_CT_NEW connections
> for 134.98.76.54 to an origsrc.

You are right when IP-only tests are considered. The joy of full cone 
NAT requires ports to be added to that equation.

The NAT algorithm must be adapted to ensure every outbound 
src-ip:src-port combo sent to the Net is completely unique and replies 
from any ip to that particular sending port cone back to the unique 
internal machine that opened it.

For your case origsrc-ip:origdst-ip:origdst-port tuplets are different.

/2c

AYJ

RE: full_cone_nat

[Jozsef Kadlecsik]

On Tue, 7 Apr 2009, Hugo Miguel Mendes wrote:

> Can you tell me where can I find in the source code the function or 
> functions responsible for checking the matching table of active 
> connections present in the file ip_conntrack.

You should first understand the internals of how netfilter connection 
tracking and NAT handle the packets and the connections. You should 
probably read the "Netfilter Hacking HOWTO" - it's outdated but still 
contains valuable information - and should definitely read the 'Writing 
netfilter modules' by Jan. Then you can easily find the relevant parts in 
net/netfilter/nf_conntrack_[standalone|core|expect].c and 
net/ipv4/netfilter/nf_nat_[standalone|core].c. Of course you should check 
out how expectations are created and used looking at the existing 
protocol helper modules.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

RE: full_cone_nat

[Hugo Miguel Mendes]

Hi,
I had been on vacation and I have just seen your answer.
Thanks for the help, I'm just going to start reading what you suggested.

Best Regards

Hugo Mendes
___
De: Jozsef Kadlecsik [kadlec@blackhole.kfki.hu]
Enviado: quarta-feira, 8 de Abril de 2009 19:44
Para: Hugo Miguel Mendes
Cc: Jan Engelhardt; netfilter-devel@vger.kernel.org
Assunto: RE: full_cone_nat

On Tue, 7 Apr 2009, Hugo Miguel Mendes wrote:

> Can you tell me where can I find in the source code the function or
> functions responsible for checking the matching table of active
> connections present in the file ip_conntrack.

You should first understand the internals of how netfilter connection
tracking and NAT handle the packets and the connections. You should
probably read the "Netfilter Hacking HOWTO" - it's outdated but still
contains valuable information - and should definitely read the 'Writing
netfilter modules' by Jan. Then you can easily find the relevant parts in
net/netfilter/nf_conntrack_[standalone|core|expect].c and
net/ipv4/netfilter/nf_nat_[standalone|core].c. Of course you should check
out how expectations are created and used looking at the existing
protocol helper modules.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: full_cone_nat

[Changli Gao]

On Wed, Apr 22, 2009 at 12:41 AM, Hugo Miguel Mendes
<est-h-mendes@ptinovacao.pt> wrote:
> Hi,
> I had been on vacation and I have just seen your answer.
> Thanks for the help, I'm just going to start reading what you suggested.
>
> Best Regards
>

It likes Port Trigger. Maybe you can refer to its source code, and you
can get the code from DD-WRT via
http://www.dd-wrt.com/dd-wrtv2/downloads/others/sourcecode/v23/dd-wrt.v23.SP1-Final.src.tar.bz2
.



-- 
Regards，
Changli Gao(xiaosuo@gmail.com)