On Aug 30, 11:23*am, Terry wrote:
> Hi, I am thinking about this problem:
> There are two computers A and B, both of which are behind a firewall
> (let's say, Fa for A, Fb for B) in different LAN's. A and B only have
> internal private IP addr and communicate with the outside thru NAT
> served by their corresponding firewall server. Then, how can A
> communicate with B?
>
> A common method is to use a intermediate server C with public IP addr. A
> and B both connect to C and C exchanges info for A and B. C is involved
> all the time when A communicates with B.

The firewall should be a router. If this router is supporting two IP
subnets behind the router, and a third IP subnet going to the
Internet, then it should know how to route IP packets between the two
internal IP subnets. A communicating with B should be straightforward
IP routing, and I don't see a need for a router C.

But frequently, the two internal ports of a firewall are only switched
at layer 2, rather than being separate IP subnets, so make sure you
know for sure how this firewall is set up. If these are just switched
at layer 2, then "routing" between internal hosts is even simpler.
They simply find each other using ARP, and no IP rotuing is involved
at all.

> But I know there can be a way that only the initial part of connection
> between A and B is done by C. After the initial part, A communicates
> with B with out the help of C. Of course, the processes on A and B that
> want to communicate with each other must use raw level socket package
> manipulation. Here is how I think they will do it:
> * initial part:
> * * * * - A connects with C thru Fa and creates a session Sa
> * * * * - B connects with C thru Fb and creates a session Sb
> * * * * - at this time, C can send data to A and B bypass the firewalls
> * * * * - and A knows the addr of Fb and B knows the addr of Fa
> * * * * - Specific info regarding to both Sa and Sb is known, such as:
> * * * * * * * * * IP sequence number
> * * * * * * * * * IP acknowledge number
> * * * * * * * * * ports if applicable
> * * * * * * * * * marked flags by NAT, etc.
> * now the direct communication part:
> * * * * - A creates package sourced from C's addr and targeting to Fb.
> * * * * * Actually the package must act the same as it's reallysourced
> * * * * * from C and in the session Sa so that it can bypass Fband
> * * * * * reach C.
> * * * * - B sends data to A in the same pattern as above.
> * * * * - and C can be shutdown...(not really actually...:-))
>
> In the whole process, the hard part is to simulate the existing session
> Sa and Sb.
>
> So I am wondering how is NAT carried out exactly? By marking some flags
> of the package? I have done a little bit search on NAT and found not
> much about the details.
> And how is a NAT server make sure a package is in a previous session?
> What specific fields of a IP package that the NAT server will examine?
> Is there any project or people out there researching/implementing this
> kind of pattern?

If it's a NAT you are describing, I suppose it could take different
forms. In the simplest, i.e. basic NAT, all it does is map a public IP
address visible externally to a private IP address visible behind the
NAT. So all it does is change the IP addresses and checksums in the
packets, as required.

If the NAT also uses the TCP Port ID as a way of expanding the address
space, then it must keep track of which Port ID is assigned to each
session. That would be the case where the same public IP address is
shared among many hosts behind the NAT.

If the NAT is also a firewall, then it could examine any number of
fields in the IP packets. The simplest form of firewall is probably
just a packet filter which examines IP addresses, port IDs, and
protocol IDs. But they can certainly go way beyond this, and look at
the data content too.

Bert

Bert, thanks for you quick reply. I apologize if my description misled you.

> The firewall should be a router. If this router is supporting two IP
> subnets behind the router, and a third IP subnet going to the
> Internet, then it should know how to route IP packets between the two
> internal IP subnets. A communicating with B should be straightforward
> IP routing, and I don't see a need for a router C.
>
> But frequently, the two internal ports of a firewall are only switched
> at layer 2, rather than being separate IP subnets, so make sure you
> know for sure how this firewall is set up. If these are just switched
> at layer 2, then "routing" between internal hosts is even simpler.
> They simply find each other using ARP, and no IP rotuing is involved
> at all.

Fa and Fb is for routing and filtering. They can be a router, or a UNIX
box or any other device that can do routing and filtering. I think what
you are describing is VLAN, which is not applicable in the scenario I am
trying to depict.

For clearness, let's say, A runs an IM client and it's in Beijing, while
B runs the same IM client and it's in New York. A talks to the outside
thru Fa, and B thru Fb. A, Fa and B, Fb are far away from each other and
in totally different network segments. Then think about how the IM
client on A send a message to the IM client on B.



> If it's a NAT you are describing, I suppose it could take different
> forms. In the simplest, i.e. basic NAT, all it does is map a public IP
> address visible externally to a private IP address visible behind the
> NAT. So all it does is change the IP addresses and checksums in the
> packets, as required.
>
> If the NAT also uses the TCP Port ID as a way of expanding the address
> space, then it must keep track of which Port ID is assigned to each
> session. That would be the case where the same public IP address is
> shared among many hosts behind the NAT.

NAT is not only do the change of the source addr of a outgoing package.
It also needs to 'mark' the package in someway so that it can tell if an
incoming package is a response to the previous outgoing package and
which private IP addr the package's dst addr should be changed back to
so that the package knows where to go in the internal network.

You mentioned a way of marking the package by its port number. But what
if there is no port field in the package at all (e.g. ICMP)? There must
be other ways to do the mark.

And if we know what of a package a NAT server marks and examines, we can
simulate a previous session. And then, we can have A directly talk to B
without the help of C.

Thanks,
ET

Hello,

Terry a écrit :
> There are two computers A and B, both of which are behind a firewall
> (let's say, Fa for A, Fb for B) in different LAN's. A and B only have
> internal private IP addr and communicate with the outside thru NAT
> served by their corresponding firewall server. Then, how can A
> communicate with B?

See NAT traversal

Eric Tao a écrit :
>
> NAT is not only do the change of the source addr of a outgoing package.
> It also needs to 'mark' the package in someway so that it can tell if an
> incoming package is a response to the previous outgoing package and
> which private IP addr the package's dst addr should be changed back to
> so that the package knows where to go in the internal network.

The NAT I know uses connection tracking. It registers a unique set of
characteristics for each outgoing connexion (such as original+new
source+destination address+port) and check whether any incoming packet
matches these characteristics.

> You mentioned a way of marking the package by its port number. But what
> if there is no port field in the package at all (e.g. ICMP)?

An ICMP error message (destination unreachable, time exceeded) carry the
beginning of the original packet which caused it to be sent, usually
including the IP and TCP/UDP/whatever headers. This allows the
connection tracking to identify the registered connection the packet is
related to. The header of ICMP echo (ping) and other request/reply times
contains an ID field that can be used to match the reply and the request.

The NAT of transport protocols without the notion of ports is usually
limited : only one internal host may establish a connection with a giver
external host.

> There must be other ways to do the mark.

AFAIK there is no such "NAT mark", there are no provisions for it in the
IP protocol.

On Aug 31, 12:34*am, Eric Tao wrote:

> Fa and Fb is for routing and filtering. They can be a router, or a UNIX
> box or any other device that can do routing and filtering. I think what
> you are describing is VLAN, which is not applicable in the scenario I am
> trying to depict.

No, actually VLANs never came into my thinking at all. I was only
suggesting that the two internal Ethernet ports of a NAT, assuming you
were talking about a NAT, *could* belong to the same Ethernet LAN, and
same IP subnet. No need for VLANs here, necessarily.

> For clearness, let's say, A runs an IM client and it's in Beijing, while
> B runs the same IM client and it's in New York. A talks to the outside
> thru Fa, and B thru Fb. A, Fa and B, Fb are far away from each other and
> in totally different network segments. Then think about how the IM
> client on A send a message to the IM client on B.

Okay, so the two internal ports are routed. In that case, traffic
between them would follow normal routing rules, and traffic between
any one internal port and the Internet would have to go through the
NAT address and perhaps Port ID translation (and checksum adjustment).

So packets between A and B do not need to have any NAT processing
applied to them. Their addresses and Port IDs stay exactly as they
were set by the sending host. However, since you are saying that this
NAT is also a firewall, and that the two internal networks might also
have to be protected between one another, these packets may have to be
examined by the firewall processing. Maybe even to examine the payload
bytes, looking for patterns that might be offensive in some way.

> NAT is not only do the change of the source addr of a outgoing package.
> It also needs to 'mark' the package in someway so that it can tell if an
> incoming package is a response to the previous outgoing package and
> which private IP addr the package's dst addr should be changed back to
> so that the package knows where to go in the internal network.
>
> You mentioned a way of marking the package by its port number. But what
> if there is no port field in the package at all (e.g. ICMP)? There must
> be other ways to do the mark.

There are any number of ways a NAT keeps track of each session,
assuming it needs to. Again, a basic NAT, one that only maps an
external address to an internal one, 1:1 ratio, would have no problem
in this regard.

Since you mention ICMP specifically, note in RFC 792 that ICMP
messages include the first 64 bits of the original ICMP datagram, in
addition ot the original IP header. Other protocols might include
session IDs consisting of a 32-bit randomly chosen number that could
be used for this. You have to look on a case by case basis. The point
is, though, that there is no convenient, explicit field in the IP
header to make life easier for the NAT, as Pascal already stated.

Bert

> See NAT traversal

Thanks Pascal. I've read this page before but got no details I want. I
guess I will read all those 'see also' links to further examine NAT.

> The NAT I know uses connection tracking. It registers a unique set of
> characteristics for each outgoing connexion (such as original+new
> source+destination address+port) and check whether any incoming packet
> matches these characteristics.

Yes, I believe to track a session is more appropriate than to mark it
when NAT only examines the src, dst addrs and port field without
changing them. Originally, I was intend to ask about what
CHARACTERISTICS NAT examines on a session so that we can simulate one.


> An ICMP error message (destination unreachable, time exceeded) carry the
> beginning of the original packet which caused it to be sent, usually
> including the IP and TCP/UDP/whatever headers. This allows the
> connection tracking to identify the registered connection the packet is
> related to. The header of ICMP echo (ping) and other request/reply times
> contains an ID field that can be used to match the reply and the request.
>
> The NAT of transport protocols without the notion of ports is usually
> limited : only one internal host may establish a connection with a giver
> external host.

I think even if a layer 3 package has the notion of port, it still
preserves the limitations. Pls think about the situation in which there
are more than one internal boxes thru the same src port communicating
with the same port on the same outside server at the same time. How does
NAT deal with this, which is quite a normal scenarios in practice? I
guess tracking some layer 4 package fields with random values(I mean
they have random initial values, so between sessions, they are
different) such as TCP acknowledgment/sequence number etc. might solve
the problem. However, this need NAT experts to confirm.

Would you pls comment on the direct communication thing between A and B
after the initial part with the help of C? I am thinking about the
details of NAT 'cause I want to simulate the session to cheat the NAT
server, thus facilitating the direct communication.

Thanks,
ET

> Okay, so the two internal ports are routed. In that case, traffic
> between them would follow normal routing rules, and traffic between
> any one internal port and the Internet would have to go through the
> NAT address and perhaps Port ID translation (and checksum adjustment).
>
> So packets between A and B do not need to have any NAT processing
> applied to them. Their addresses and Port IDs stay exactly as they
> were set by the sending host. However, since you are saying that this
> NAT is also a firewall, and that the two internal networks might also
> have to be protected between one another, these packets may have to be
> examined by the firewall processing. Maybe even to examine the payload
> bytes, looking for patterns that might be offensive in some way.

Thanks Bert. But I am still not sure you fully understand the scenario
here. A and B only have private internal addrs (I think I mentioned this
in my post) like 10.*.*.* or 192.168.*.* or 172.*... etc, which are not
routeable on the internet. And an IM client on A or B certainly cannot
change the settings on the NAT server, Fa or Fb, to add a static NAT
mapping. Therefore, packages from A and B have to have their src addr
changed to the addr of their NAT server (also as a gateway to the
outside) in order for their response packages to reach back (this is
SNAT). In this situation, neither A or B can initialize a connection
with each other 'cause A and B don't have a public IP addr. That's why
we traditionally need another server C with public IP addr to assist.

And I am thinking about simulating sessions and cheating NAT servers to
enable direct communication between A and B after C does the initial part.

Still open for comments.


Thanks,
ET

On Sep 1, 2:08*pm, Eric Tao wrote:

> Thanks Bert. But I am still not sure you fully understand the scenario
> here. A and B only have private internal addrs (I think I mentioned this
> in my post) like 10.*.*.* or 192.168.*.* or 172.*... etc, which are not
> routeable on the internet. And an IM client on A or B certainly cannot
> change the settings on the NAT server, Fa or Fb, to add a static NAT
> mapping.

I read your original post again. Are these two private IP subnets, Fa
and Fb, connected to a single NAT? Which also connects to the Internet
via a third interface?

That is what I am assuming. If its' true, then I don't see why this
box can't create a route directly between Fa and Fb, without going
through the NAT translation process.

And by the way, "router" can certainly be a unix box, with ports
assigned to different IP subnets. A router is simply a layer 3 box
which is programmed to forward packets between the ports which belong
to different IP subnets. If the box is programmed to do this
forwarding, you should call it router rather than server. NATs are
typically routers, which also do address translation when forwarding
packets to or from a particular interface.

Bert

Eric Tao a écrit :
>
> Yes, I believe to track a session is more appropriate than to mark it
> when NAT only examines the src, dst addrs and port field without
> changing them. Originally, I was intend to ask about what
> CHARACTERISTICS NAT examines on a session so that we can simulate one.

It depends on the way the NAT is performed. Some NAT devices have a pool
of public addresses they can dynamically use to masquerade connections
from private hosts. When a private host initiates a connection, the NAT
device dynamically and temporarily allocates an available public address
from the pool to the host ; it then translates the private host address
into the allocated public address and vice versa. This kind of NAT
mapping involves only the addresses, not the protocol or ports. Of
course it means that the number of internal hosts which can
simultaneously communicate with the outside is limited by the number of
public addresses in the NAT pool.

But most NAT devices only have one public address that must be shared
with all private hosts. This is commonly called "masquerading" and is
done per connection instead of per host. So the NAT device must use more
than the addresses in the mappings. NAT mappings commonly include the
source and destination addresses, the protocol, and, when applicable,
the source and destination ports.

>> The NAT of transport protocols without the notion of ports is usually
>> limited : only one internal host may establish a connection with a
>> giver external host.
>
> I think even if a layer 3 package has the notion of port, it still
> preserves the limitations. Pls think about the situation in which there
> are more than one internal boxes thru the same src port communicating
> with the same port on the same outside server at the same time. How does
> NAT deal with this, which is quite a normal scenarios in practice?

I cannot say about all NAT devices, but Linux can implicitly change the
TCP or UDP source port of subsequent connections in order to avoid
"collisions" with existing mappings.

host1ort1 -> serverort2 -[masquerade]-> publicort1 -> serverort2
host2ort1 -> serverort2 -[masquerade]-> publicort3 -> serverort2

Eric Tao a écrit :
>
> A and B only have private internal addrs (I think I mentioned this
> in my post) like 10.*.*.* or 192.168.*.* or 172.*... etc, which are not
> routeable on the internet. And an IM client on A or B certainly cannot
> change the settings on the NAT server, Fa or Fb, to add a static NAT
> mapping. Therefore, packages from A and B have to have their src addr
> changed to the addr of their NAT server (also as a gateway to the
> outside) in order for their response packages to reach back (this is
> SNAT). In this situation, neither A or B can initialize a connection
> with each other 'cause A and B don't have a public IP addr. That's why
> we traditionally need another server C with public IP addr to assist.

Yes, and that's what NAT traversal techniques such as STUN or "hole
punching" are helping to do. The idea is that both private hosts
initiate an outgoing connection each other's public address in order to
create the mapping on their own NAT device. It works well for UDP which
is a connectionless protocol, but is NAT-dependent for connected
protocols such as TCP.
See for more details.

> Yes, and that's what NAT traversal techniques such as STUN or "hole
> punching" are helping to do. The idea is that both private hosts
> initiate an outgoing connection each other's public address in order to
> create the mapping on their own NAT device. It works well for UDP which
> is a connectionless protocol, but is NAT-dependent for connected
> protocols such as TCP.
> See for more details.

Thanks Pascal, I believe that's what I am seeking for. :-)

> I read your original post again. Are these two private IP subnets, Fa
> and Fb, connected to a single NAT? Which also connects to the Internet
> via a third interface?
>
> That is what I am assuming. If its' true, then I don't see why this
> box can't create a route directly between Fa and Fb, without going
> through the NAT translation process.

Sorry for the confusion. But what I meant was that A and B had their
separate NAT servers/gateways to the outside world (the internet).


> And by the way, "router" can certainly be a unix box, with ports
> assigned to different IP subnets. A router is simply a layer 3 box
> which is programmed to forward packets between the ports which belong
> to different IP subnets. If the box is programmed to do this
> forwarding, you should call it router rather than server. NATs are
> typically routers, which also do address translation when forwarding
> packets to or from a particular interface.

I am not sure about the terminology. I prefer calling a NAT box a server
to a router because it provides NAT services, and a router usually does
its job by looking up on a route table, which is different from a
masquerading service. Anyway, it's not of that importance how it calls.

Thanks Bert! :-)
ET

> It depends on the way the NAT is performed. Some NAT devices have a pool
> of public addresses they can dynamically use to masquerade connections
> from private hosts. When a private host initiates a connection, the NAT
> device dynamically and temporarily allocates an available public address
> from the pool to the host ; it then translates the private host address
> into the allocated public address and vice versa. This kind of NAT
> mapping involves only the addresses, not the protocol or ports. Of
> course it means that the number of internal hosts which can
> simultaneously communicate with the outside is limited by the number of
> public addresses in the NAT pool.
>
> But most NAT devices only have one public address that must be shared
> with all private hosts. This is commonly called "masquerading" and is
> done per connection instead of per host. So the NAT device must use more
> than the addresses in the mappings. NAT mappings commonly include the
> source and destination addresses, the protocol, and, when applicable,
> the source and destination ports.

The NAT pool thing is something new to me. And thanks for the above
info. It's of great help.


> host1ort1 -> serverort2 -[masquerade]-> publicort1 -> serverort2
> host2ort1 -> serverort2 -[masquerade]-> publicort3 -> serverort2

This rocks!

Again, thanks Pascal. :-)
ET

On 2008-08-30 11:23:50 -0400, Terry said:

> Hi, I am thinking about this problem:
> There are two computers A and B, both of which are behind a firewall
> (let's say, Fa for A, Fb for B) in different LAN's. A and B only have
> internal private IP addr and communicate with the outside thru NAT
> served by their corresponding firewall server. Then, how can A
> communicate with B?

I'm not sure if the point of your exercise is to try solving this
problem with NAT, because that's something you need to do. If not,
consider connecting the two machines with OpenVPN point-to-point, and
have them communicate over that tunnel interface. A static key
configuration is very easy and quick to do.

/dmfh

--
_ __ _
__| |_ __ / _| |_ 01100100 01101101
/ _` | ' \| _| ' \ 01100110 01101000
\__,_|_|_|_|_| |_||_| dmfh(-2)dmfh.cx