Re: how to improve intelligent nat handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Tom,

This is not a real answer to your question but it may help in some cases.
Sorry, I know nothing specific about the Draytek.

When you see only the public address of a NATed client in the RCF, it
indeed means that the NAT box has translated the address in the RRQ, and
if the NAT doesn't translate everything else correctly, it won't work
with gnugk.

First, try defining the endpoint in the [NATedEndpoints] section.

In some cases, the problem is that the NAT knows specially about port 1720;
if you set CallSignalPort=1720 in gnugk it will work fine (NAT doing
all translation correctly).

In other cases, if the client can register using a port other
than 1719, set UnicastRasPort (and the client) to some other value.
Then the NAT doesn't "see" the registration, and gnugk correctly finds
out that the client is behind a NAT.  In this situation, keep
CallSignalPort at other than 1720.

With some NATs, you can turn off the stateful inspection related to
H.323.  This may be in an unexpected menu such as "intrusion detection".

Occasionally, you can avoid trouble by turning on (or off) fast start
and/or H.245 tunneling.

Is you are willing to use a child GK, put another NIC in it and have
it also function as the NAT.  This is pretty sure to work, as long
as the OS is not Windows.  It can also improve performance, if you no
longer need ProxyForNAT on the main GK.

I don't know whether [NATedEndpoints] will work for a child GK.
Presumably it would if the auxiliary GK is configured as an endpoint.

Hardware NATs are so inexpensive these days, it may be simplest just
to replace the troublesome one.

STUN could potentially help, but that solution would be of no use to
the majority of users with hardware endpoints that are almost always
closed-source.

Hope this is useful,

Stewart


----- Original Message ----- From: <supertom64@xxxxxxxxxxx>
To: <openh323gk-users@xxxxxxxxxxxxxxxxxxxxx>
Sent: Friday, January 14, 2005 5:21 PM
Subject: how to improve intelligent nat handling



hi,
i am new to the list and did already a search about the NAT Q&A but couldn´t find an answer for my problem right now.


we use videophones with the gnugk which works really pretty fine except some problems with several NAT Routers.

the most problem we have is that the phone can connect the outside gk with public ip and register correctly but at the channel setup the reply IP is setup as an private IP.

isn´t there a way to rewrite the IP at the channel setup to the correct IP, because the gk already knows the real IP of the phone behind the NAT (from registration) and the private IP´s are also well known. (i know that many SIP Provider will do this to establish connections with broken NATs)

i guess that some broken NAT routers try to rewrite the IP address at translation but don´t do it the right way or as deep as it is necessary for H.323.

e.g.
any phone or also a child gk behind a draytek vigor 2200X register with the public IP instead of the private IP at registration.
gnugk states a NAT=0 (did s.b. know what are the different NAT Types?) at the gk.log file with -ttttt
i assume that gnugk guess that the phone is without NAT or that there is no translation necessary.
as an result at the channel setup the reply IP of the phone behind the draytek router is an private IP which couldn´t obviously work.


it did not matter if i use dmz or portforwarding the result is always the same, the other side can here and see me but i can´t nothing receive at my side.

i could expand the list to some more routers e.g. some zyxel, dlink, netgear, devolo etc.this is because of the upcomming and at the moment mainstream broadband connections over ADSL with one dynamic IP (and a disconnection every 24h) not really a fortune.

also setting up a proxy gk as a child gk behind such a NAT router will bring some improvements.
(can i force the child (proxy) gk to be a NATed Endpoint?

could STUN which is already included in the openh323 protocol bring some improvment? Any hints are warmest welcome :-)

thx in advance
TOM



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

_______________________________________________________

List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549
Homepage: http://www.gnugk.org/

[Index of Archives]     [SIP]     [Open H.323]     [Gnu Gatekeeper]     [Asterisk PBX]     [ISDN Cause Codes]     [Yosemite News]

  Powered by Linux