NAT question?

GRE or IPSEC, MPLS, (VPN) can do the job.

You need to setup static nat on both Gateway1 & Gateway2 such that PC1(192.168.0.10) is mapped to say (100.100.100.101) on Gateway1 and

192.168.0.20 is mapped to say (200.200.200.201) on Gateway2. I am assuming that you have more than one public IP address on each gateways; otherwise, port forwarding (or IP forwarding) is your only solution.

Doan

In article , Alex wrote: :On Tue, 21 Jun 2005 02:14:40 -0700, Truong2D wrote: :> My question is: Is there any way to establish a direct connection :> between my PC at home and my PC at office WITHOUT any manual :> configuration with two Gateways (such as IP forwarding, etc.)? I mean, :> "programmatically".

:> PC1(192.168.0.10)Gateway1(Global IP1)Gateway2(Global :> IP2)PC1(192.168.0.20) -> direct connection possible without any :> manual configuration in two Gateways?

:GRE or IPSEC, MPLS, (VPN) can do the job.

GRE, IPSec, MLPS all require manual configuration of the IP of the remote security gateway (though if you are going MLPS then the ISP is probably going to do the work on your behalf, and you are going to pay heartily for their work.) "Metro Ethernet" would be like MLPS in that regard.

If one requires that there be "no manual configuration" of the IP addresses, then a service such as gotomypc.com might be what is desired.

On the other hand, I did not quite catch what the aversion is to "manually" configuring a pair of IP addresses once. I wonder if there was an omitted fact in this question, such as the possibility that the residential end has a dynamic IP address rather than a static IP address. If that's all there is to it, and if it is acceptable that the office side won't always be able to initiate connections to the residential (dynamic IP) side, then IPSec becomes a possibility... even if it does require manually configuring -one- of the IP addresses.

I th>>...; otherwise, port forwarding (or IP forwarding) is your only solution.

I took a test with SkyPE with my two PCs and I could hear the voice. Is the connection between the two SkyPE Clients direct? If yes, then how they could do this? It sounds interesting, may I be able to follow their way?

Thanks in advance, Truong2D,

In article , wrote: :I think if I use gotomypc service in this case then my two PCs will :connect to each other via a gotomypc server, is this correct? It means :"not directly".

Right.

:I took a test with SkyPE with my two PCs and I could hear the voice. Is :the connection between the two SkyPE Clients direct? If yes, then how :they could do this? It sounds interesting, may I be able to follow :their way?

Skype will cross connect via the Skype servers if necessary, but it prefers to use random other PCs on the net to act as switchboards. It gets the IP addresses and ports of those PCs from the Skype servers and tries outgoing connections to them. Because the ports are the ones that those PCs connected to the Skype servers with, those port numbers were outgoing relative to those other PCs -- post Network Address Translation -- so those are the port numbers on the destination suitable for your system to connect to them on. And the port numbers that those systems will see coming from you will be post NAT, so the port number they get from you will be suitable for sending back replies.

This Skype process works as long as people are using NAT devices that do not check source addresses on inward UDP packets -- which is common for consumer level "firewalls". A device such as the Cisco PIX

*does* check source addresses, so those other random PCs can't connect inward, so a PC protected by Skype can't be transformed into a Skype server, but it can still act as a passive node, talking to other random PCs that don't have source-address protection.

My head just exploded!

|> Skype will cross connect via the Skype servers if necessary, but |> it prefers to use random other PCs on the net to act as switchboards. |> It gets the IP addresses and ports of those PCs from the Skype servers |> and tries outgoing connections to them. Because the ports are the |> ones that those PCs connected to the Skype servers with, those |> port numbers were outgoing relative to those other PCs -- post |> Network Address Translation -- so those are the port numbers on the |> destination suitable for your system to connect to them on. And the |> port numbers that those systems will see coming from you will be |> post NAT, so the port number they get from you will be suitable for |> sending back replies.

|My head just exploded!

Hey, I re-read my explanation and it still made sense to me, so it can't be -entirely- bad ;-)

If you read the Skype user agreement you will find that you agree that your machine might be used as a Skype server -- if you have a nice fast connection, and Skype can figure out how to get new inward connections from other people over to your machine, then your machine is probably going to end up doing call management (and possibly acting as the switchboard for other people who can't connect directly to each other.) Skype is an outgrowth of KaZaa -- the person who developed that went on to Skype. Yeah, that -does- mean that if you watch your security logs while you have Skype turned on, that you'll likely freak out at first :-(

But how does it actually work? It's mostly just a situation in which it is important to pay attention to the difference between internal port numbers and external (NAT'd) port numbers. You connect outward, the Skype servers read off the port number as -they- see it, and they blab that port number around. Other hosts try to connect to that port number. If you are using a consumer-level NAT device or firewall, your device/firewall is likely going to allow those udp packets inwards from all over the world, not checking to be sure that the packets are from the IP that it build the outgoing translation to...

Hi All, Thank you for your more replies to this toppic!

I also found good topics about NAT -

and SkyPE - How ever I am a novice so I am unable to understand all. And I have one more question with SkyPE: When A and B wants to talk to each other they will establish a connection via C (C is named "Super Node") (A and B are behind a NAT device, C has a global IP). When A talks, it will send pakages to C by using TCP protocol, and then C will send ("forward"?) these packages to B by UDP protocol. What I am wondering is that: how could these UDP packages from C go through NAT device to come to B?

A=192.168.0.10, A's NAT device=global=100.100.100.100 B=192.168.0.20, B's NAT device=global=200.200.200.200 C=global=300.300.300.300

Many more thanks, Truong2D,

In article , wrote: :And I have one more question with SkyPE: :When A and B wants to talk to each other they will establish a :connection via C (C is named "Super Node") (A and B are behind a NAT :device, C has a global IP). :When A talks, it will send pakages to C by using TCP protocol, and then :C will send ("forward"?) these packages to B by UDP protocol. What I am :wondering is that: how could these UDP packages from C go through NAT :device to come to B?

B has formed an outgoing UDP connection to C, so the UDP packets from C to B are considered "reply" packets and so allowed through the firewall.

:Walter Roberson wrote: :B has formed an outgoing UDP connection to C, so the UDP packets :from C to B are considered "reply" packets and so allowed through :the firewall.

But I know that UDP is connectionless protocol, there is no handshaking, no connection establishment, no connection state, is that right? Could you please give me some more hints?

Thanks, Truong2D,

In article , wrote: |:Walter Roberson wrote: |:B has formed an outgoing UDP connection to C, so the UDP packets |:from C to B are considered "reply" packets and so allowed through |:the firewall.

|But I know that UDP is connectionless protocol, there is no |handshaking, no connection establishment, no connection state, is that |right?

Yes.

|Could you please give me some more hints?

Timeouts.

NAT devices often remove UDP translations after the connection has been idle for a preset time.

Without something like this, either many many things would break (e.g., DNS is usually UDP based; if DNS broke then -lots- would break); or else UDP translations would have to stay in existance indefinitely, until the NAT device was rebooted... but that would quickly use up all available UDP port numbers.