NAT hole punching
in [Linux Networking]
|
Prev: what does "::ffff" mean in netstat output?
Next: Google wants to see client addresses in DNS queries
From: David Schwartz on 30 Jan 2010 14:42 On Jan 30, 6:02 am, Tobias Nissen <t...(a)movb.de> wrote: > I know I didn't strictly follow the procedure in [2], but I'd still > like to know why it didn't work. Could someone enlighten me? You never punched a hole. You simply tried to reach A from B, which won't work because of B's NAT -- and you tried to reach B from A, which won't work because of A' s NAT. If you tried both at the same time, it could work if both B and A's NAT preserve source ports. But the usual approach is to get both B and A to establish a connection to a computer that is not behind NAT and then use the NAT entries thus established to allow B and A to connect to each other directly. DS
From: Tobias Nissen on 31 Jan 2010 06:51 David Schwartz wrote: > On Jan 30, 6:02Â am, Tobias Nissen <t...(a)movb.de> wrote: >> I know I didn't strictly follow the procedure in [2], but I'd still >> like to know why it didn't work. Could someone enlighten me? > > You never punched a hole. You simply tried to reach A from B, which > won't work because of B's NAT -- and you tried to reach B from A, > which won't work because of A' s NAT. I don't remember where, but I read somewhere, that by doing so the NAT devies learn of A's and B's intentions to communicate with each other. So if let's say A's NAT sees A trying to connect to B:5679 from A:5678, it assumes that it is OK for B to connect to A. But this doesn't seem to be the way at least my NAT-devices work. Or is it generally out of the question that this could work? > If you tried both at the same > time, it could work if both B and A's NAT preserve source ports. But > the usual approach is to get both B and A to establish a connection to > a computer that is not behind NAT and then use the NAT entries thus > established to allow B and A to connect to each other directly. With that SO_REUSEADDR magic? IOW I can't do it with netcat, right?
From: David Schwartz on 31 Jan 2010 08:33 On Jan 31, 3:51 am, Tobias Nissen <t...(a)movb.de> wrote: > I don't remember where, but I read somewhere, that by doing so the NAT > devies learn of A's and B's intentions to communicate with each other. > So if let's say A's NAT sees A trying to connect to B:5679 from A:5678, > it assumes that it is OK for B to connect to A. Right, but how does A learn B's source port? How does B learn A's source port? You need some common intermediary that both A and B connect to. > But this doesn't seem to be the way at least my NAT-devices work. Or > is it generally out of the question that this could work? See if your NAT devices change the source ports. > > If you tried both at the same > > time, it could work if both B and A's NAT preserve source ports. But > > the usual approach is to get both B and A to establish a connection to > > a computer that is not behind NAT and then use the NAT entries thus > > established to allow B and A to connect to each other directly. > With that SO_REUSEADDR magic? IOW I can't do it with netcat, right? You have to actually do that NAT traversal or hole punching, and you need an intermediary to do it in most cases. Otherwise, A and B have on way to learn their own source ports. DS
From: Tobias Nissen on 31 Jan 2010 11:07 David Schwartz wrote: > On Jan 31, 3:51Â am, Tobias Nissen <t...(a)movb.de> wrote: >> I don't remember where, but I read somewhere, that by doing so the >> NAT devies learn of A's and B's intentions to communicate with each >> other. So if let's say A's NAT sees A trying to connect to B:5679 >> from A:5678, it assumes that it is OK for B to connect to A. > > Right, but how does A learn B's source port? How does B learn A's > source port? You need some common intermediary that both A and B > connect to. I know, that's why I have an intermediary. It's called B (other B than yours), see my original posting. >> But this doesn't seem to be the way at least my NAT-devices work. Or >> is it generally out of the question that this could work? > > See if your NAT devices change the source ports. They don't, see my OP :-) >>> If you tried both at the same >>> time, it could work if both B and A's NAT preserve source ports. >>> But the usual approach is to get both B and A to establish a >>> connection to a computer that is not behind NAT and then use the >>> NAT entries thus established to allow B and A to connect to each >>> other directly. > >> With that SO_REUSEADDR magic? IOW I can't do it with netcat, right? > > You have to actually do that NAT traversal or hole punching, and you > need an intermediary to do it in most cases. Otherwise, A and B have > on way to learn their own source ports. I know my OP is a bit hard to read with all the involved ports and hosts, but it's all in there. My main question is: Why doesn't the hole punching work with netcat? Does it always have to be the same socket that is reused again and again (for the connection to the intermediary, for the hole punching and for the direct connection)?
From: H.Janssen on 6 Feb 2010 11:02
Dear All, I'm afraid I missed one essential thing in the discussion concerning NAT hole punching, but may be I'm wrong: you need UDP packets. TCP connections have to be opened and closed, so as soon netcat did it's job, the connection is put into state closed and the connection is forgotten. UDP is stateless, as soon A sends an UDP packet, there is an open channel from the router to A waiting for response, until it times out. Assume that hosts A and B are behind NAT, but want to communicate, and a public intermediate host C is available. A sends an UDP packet to C, and creates an open channel on the router waiting for response. C informs B about the parameters of this A-channel, and B uses this open channel to send packets to A. C informs A about the parameters of B, and now A en B can communicate directly via the holes on both routers. So I think you definitively need "-u" as additional option in your netcat tests. Kind Regards, Tobias Nissen wrote: > David Schwartz wrote: >> On Jan 31, 3:51 am, Tobias Nissen <t...(a)movb.de> wrote: >>> I don't remember where, but I read somewhere, that by doing so the >>> NAT devies learn of A's and B's intentions to communicate with each >>> other. So if let's say A's NAT sees A trying to connect to B:5679 >>> from A:5678, it assumes that it is OK for B to connect to A. >> >> Right, but how does A learn B's source port? How does B learn A's >> source port? You need some common intermediary that both A and B >> connect to. > > I know, that's why I have an intermediary. It's called B (other B than > yours), see my original posting. > >>> But this doesn't seem to be the way at least my NAT-devices work. Or >>> is it generally out of the question that this could work? >> >> See if your NAT devices change the source ports. > > They don't, see my OP :-) > >>>> If you tried both at the same >>>> time, it could work if both B and A's NAT preserve source ports. >>>> But the usual approach is to get both B and A to establish a >>>> connection to a computer that is not behind NAT and then use the >>>> NAT entries thus established to allow B and A to connect to each >>>> other directly. >> >>> With that SO_REUSEADDR magic? IOW I can't do it with netcat, right? >> >> You have to actually do that NAT traversal or hole punching, and you >> need an intermediary to do it in most cases. Otherwise, A and B have >> on way to learn their own source ports. > > I know my OP is a bit hard to read with all the involved ports and > hosts, but it's all in there. > > My main question is: Why doesn't the hole punching work with netcat? > Does it always have to be the same socket that is reused again and > again (for the connection to the intermediary, for the hole punching and > for the direct connection)? |