Ken; I don't think you said what the external endpoint was? Tandberg Endpoints that support H.460.18 do it automatically, Polycom endpoints that support H.460.18 need to have it toggled on. Not all Polycom or Tandberg endpoints support H.460.18, and just because a call works one way doesn't mean H.460.18 is actually working. Your setup is more complex than mine, I tend to put the H.460.18 gateway not nat'd, keeps the problem solving with NAT to a single piece. I do know that my setup does work (for the most part, there are some leaky packets that try to go to the actual non-public IP of the endpoint, but they don't actually appear to affect the call in anyway, least so far). Andrew Ken Tucker wrote: > Simon and all, > > I just compiled the latest CVS version and I still have the same problem. I'll relook at my entire config to see if I'm missing anything. Until then, here's an attempt at a text diagram of my setup. > > External endpoint (private IP) <- NAT <- Internet <-NAT <- GnuGK (private IP) <- Internal endpoint > > -External endpoint is registered to the external NAT of GnuGK > -Internal endpoint is registered to the actual private IP of GnuGK > > During calls from Internal to external, the internal endpoint begins communications with the private IP of GnuGK (since that's where it's registered), then what looks like during H245 tries to communicate with GnuGK's external/NAT IP. I know this from both GnuGK logs and a packet sniff of the network. It therefore fails due to confusion between the two IPs (Ext/int of same GnuGK). The internal endpoint should always just talk to GnuGK's private IP since it's all on the LAN side, shouldn't it? Just like the external endpoint should only talk to the NAT/external IP of GnuGK. > > Here's my latest config file: > [Gatekeeper::Main] > Fortytwo=42 > TimeToLive=600 > Home=10.1.1.1 > ExternalIP=1.1.1.1 > > [RoutedMode] > GKRouted=1 > H245Routed=0 > CallSignalPort=1720 > RemoveH245AddressOnTunneling=1 > DropCallsByReleaseComplete=1 > SupportNATedEndpoints=1 > SupportCallingNATedEndpoints=1 > Q931PortRange=30000-30999 > H245PortRange=31000-31999 > EnableH46018=1 > NATStdMin=18 > > [Proxy] > Enable=1 > ProxyAlways=1 > T120PortRange=50000-59999 > RTPPortRange=50000-59999 > InternalNetwork=10.0.0.0/8 > > [GkStatus::Auth] > rule=allow > > ;[RasSrv::RRQFeatures] > SupportDynamicIP=1 > > > Anyone have any other thoughts? Is double-NAT (endpoint + gnugk server) too much for GnuGK, is this a bug, is this related to Tandberg & H460.18, or do you see any config issues? I've tried every combo of Home, ExternalIP, InternalNetwork etc that I can think of and I always get the same results.... > > Sorry if I keep spamming with this, I just find it hard to believe that I'm the only one with this same configuration having this issue unless it's just something I'm doing wrong, in which case I'd hope it's be obvious. ;) > > Ken > > > -----Original Message----- > From: Simon Horne [mailto:s.horne@xxxxxxxxxxxxxx] > Sent: Friday, May 07, 2010 5:56 PM > To: 'GNU Gatekeeper Users' > Subject: Re: NAT woes > > > Ken > > There is a bug and the bug has been fixed in the CVS version. I will be doing some testing and ensure that it works for the next release. > > Simon > > -----Original Message----- > From: Ken Tucker [mailto:ken.tucker@xxxxxxxxx] > Sent: Saturday, 8 May 2010 6:40 AM > To: GNU Gatekeeper Users > Subject: Re: NAT woes > > All, > > Gnugk has/had full outbound access. It is also statically NATed. > > I ran a packet trace and now know the issue but so far have been unable to fix it. Calls from external to internal endpoints work perfectly through gnugk. Same goes for internal to internal. However, internal to fails. > > Here's the setup: > Gnugk server: physical IP: 10.1.1.1, external NAT: 1.1.1.1 (NATed-static, all required ports open on both sides) External endpoint: gatekeeper registered to 1.1.1.1 Internal endpoint: gatekeeper registered to 10.1.1.1 > > When internal calls external, I can see in the packet trace that the internal endpoint is trying to hit 1.1.1.1 instead of 10.1.1.1. In other words, it's trying to go out to the NAT/external address instead of the internal address that it's registered to. > > > I suspect it's something to do with home IP / external IP / internalnetwork, but no matter how much I tinker with them, either calls don't even start to work, or it just doesn't connect (and I see the issue below). > > Here's my config, and again I'm running 2.3.1: > > [Gatekeeper::Main] > Fortytwo=42 > TimeToLive=600 > Home=10.1.1.1 > ExternalIP=1.1.1.1 > > [RoutedMode] > GKRouted=1 > H245Routed=1 > CallSignalPort=1720 > RemoveH245AddressOnTunneling=1 > DropCallsByReleaseComplete=1 > SupportNATedEndpoints=1 > SupportCallingNATedEndpoints=1 > Q931PortRange=30000-30999 > H245PortRange=31000-31999 > EnableH46018=1 > > [Proxy] > Enable=1 > ProxyAlways=1 > T120PortRange=40000-40999 > RTPPortRange=50000-59999 > InternalNetwork=10.0.0.0/8 > > [GkStatus::Auth] > rule=allow > > [RasSrv::RRQFeatures] > SupportDynamicIP=1 > > > Thanks for any other ideas you have... ! > Ken > > -----Original Message----- > From: Siem Smit [mailto:ssmit@xxxxxxxxxxxxxxxxx] > Sent: Wednesday, May 05, 2010 1:38 PM > To: GNU Gatekeeper Users > Subject: Re: NAT woes > > Hi Ken, > > Try to allow the gnugk to access any any outbound on the cisco ASA. > Also you have to make sure the NAT ports are not mapped dynamical but static so port localip:40001 get translated into externalip:40001 > > Also Tandberg has a few demands on firewall ports to open but since you are using gnugk this should be proxied by gnugk. > > > > Siem > > -----Original Message----- > From: Ken Tucker [mailto:ken.tucker@xxxxxxxxx] > Sent: woensdag 5 mei 2010 19:30 > To: GNU Gatekeeper Users > Subject: Re: NAT woes > > Our firewall is a Cisco ASA. I have turned off all H323 inspection. > Calling from external endpoint to internal endpoint works and I now have full audio/video. Internal to external fails, it just rings and rings. > > Also, an internal to internal connection works, but only if I set the Tandberg to use static H323 ports. I still need to update the code on that endpoint which may help. > > Still testing... ;) > > Thanks! > > -----Original Message----- > From: Andrew Herdman [mailto:andrew@xxxxxxxxx] > Sent: Wednesday, May 05, 2010 11:43 AM > To: GNU Gatekeeper Users > Subject: Re: NAT woes > > Ken; > > Glad things are moving forward. The other questions, we'll need to know > > more about your environment, the firewall, while things may be open, if it's a state full inspection firewall it may be blocking things anyway, smart is not always better. You also don't mention which way works, and > > which way does not. > > Andrew > > > Ken Tucker wrote: > >> Thanks, Andrew. That instantly helped. I'm still having some issues >> > but I'm light-years further than I was. Any other settings you or anyone recommend for having the gatekeeper NATed and external endpoints NATed? > I still have some issues were I can call one way but not the other. > Thanks! > >> Ken >> >> -----Original Message----- >> From: Andrew Herdman [mailto:andrew@xxxxxxxxx] >> Sent: Wednesday, May 05, 2010 6:24 AM >> To: GNU Gatekeeper Users >> Subject: Re: NAT woes >> >> Ken; >> >> Try adding this to [Gatekeeper::Main] >> >> Home=IP Address of Ethernet >> ExternalIP=IP Address that is NAT to Outside >> >> I've had better luck with things. >> >> As well, not sure about your entire setup, but if you add to [Proxy] >> >> ProxyAlways=1 >> >> might help simplify your debugging, as all calls will be proxied. It >> > may > >> however cause issues if you have several inside endpoints calling each >> > > >> other. >> >> Andrew >> >> >> Ken Tucker wrote: >> >> >>> Hi all, >>> >>> I've been banging my head against a wall for several days and after >>> numerous attempts at ini changes and google searches, I figured it >>> > was > >>> time to come begging for help... >>> >>> I have a single gnugk system (2.3.1) behind my firewall. It only has >>> one (private IP) interface. It is NATed to the Internet and all the >>> appropriate ports are allowed in. I have endpoints in other VLANs >>> behind the firewall (with full IP access to/from gnugk for now). I >>> also have external endpoints on different networks that are NATed >>> > out. > >>> Note that ALL endpoints are Tandbergs. >>> >>> All units register fine, either to the private IP or the NATed IP of >>> gnugk. However, I cannot get a call to connect from external to >>> internal endpoint or vice-versa. If I call from ext to int, it rings, >>> > > >>> and as soon as the other side connects, the ext shows call >>> cleared/disconnected. Here's a chunk of the logs (using -ttttt) when >>> > I > >>> call from the external unit to the internal unit (via alias): (all >>> > IPs > >>> have been changed J ) >>> >>> ------------------------------------------------------------------ >>> >>> 2010/05/04 23:39:29.332 3 RasSrv.cxx(2569) GK ARQ will request >>> bandwith of 10240 >>> >>> 2010/05/04 23:39:29.332 5 Routing.h(177) ROUTING Checking policy >>> Explicit for the request ARQ 2572 >>> >>> 2010/05/04 23:39:29.332 5 Routing.h(177) ROUTING Checking policy >>> Internal for the request ARQ 2572 >>> >>> 2010/05/04 23:39:29.332 4 RasTbl.cxx(1697) Alias match for EP >>> 10.1.1.1:1719 >>> >>> 2010/05/04 23:39:29.332 5 Routing.h(183) ROUTING Policy Internal >>> applied to the request ARQ 2572 >>> >>> 2010/05/04 23:39:29.332 2 RasTbl.cxx(3321) CallTable::Insert(CALL) >>> Call No. 1, total sessions : 1 >>> >>> 2010/05/04 23:39:29.332 5 RasTbl.cxx(3087) RAS >>> >>> NAT Offload (H460.23/.24) calculation inputs for Call No: 1 >>> >>> Rule : Must Proxy Media >>> >>> Calling Endpoint: >>> >>> Proxy IP: 22.22.22.22 >>> >>> Called Endpoint: >>> >>> Proxy IP: 10.1.1.1 >>> >>> 2010/05/04 23:39:29.332 4 RasTbl.cxx(3092) RAS Disable H.460.24 >>> Offload as neither party supports it. >>> >>> 2010/05/04 23:39:29.332 4 RasSrv.cxx(2744) RAS NAT strategy for Call >>> No: 1 set to Unknown Strategy >>> >>> 2010/05/04 23:39:29.332 2 RasSrv.cxx(394) >>> >>> > ACF|22.22.22.22:1719|5423_endp|16845|222:dialedDigits|224:dialedDigits|f > alse|02-b2-8b-0e-26-8e-19-50-34-48-00-50-60-01-25-4a; > >>> 2010/05/04 23:39:29.332 3 RasSrv.cxx(236) RAS Send to >>> > 22.22.22.22:1719 > >>> ..... >>> >>> 2010/05/04 23:39:39.786 1 ProxyChannel.cxx(4536) H245d Could not >>> open/connect H.245 socket at 0.0.0.0:31001 - error 12/1073751885: >>> Connection refused >>> >>> 2010/05/04 23:39:39.786 3 ProxyChannel.cxx(4538) H245 10.1.1.1:11025 >>> DIDN'T ACCEPT THE CALL >>> >>> >>> > ------------------------------------------------------------------------ > - > >>> Few things... Why would NAT strategy be set to "Unknown Strategy"? >>> > Also > >>> what does the connection refused for 0.0.0.0 signify? >>> >>> Here's my config: >>> >>> [Gatekeeper::Main] >>> >>> Fortytwo=42 >>> >>> TimeToLive=600 >>> >>> ExternalIP=[nated external IP of gnugk] >>> >>> ExternalIsDynamic=0 >>> >>> [RoutedMode] >>> >>> GKRouted=1 >>> >>> H245Routed=1 >>> >>> CallSignalPort=1720 >>> >>> RemoveH245AddressOnTunneling=1 >>> >>> DropCallsByReleaseComplete=1 >>> >>> SupportNATedEndpoints=1 >>> >>> ;SupportCallingNATedEndpoints=1 >>> >>> Q931PortRange=30000-30999 >>> >>> H245PortRange=31000-31999 >>> >>> EnableH46018=1 <----- without this, I got immediate route errors >>> >>> NATStdMin=18 >>> >>> [Proxy] >>> >>> Enable=1 >>> >>> T120PortRange=50000-59999 >>> >>> RTPPortRange=50000-59999 >>> >>> InternalNetwork=[various endpoint vlans behind firewall],127.0.0.0/8 >>> <----- without the internal vlans, I couldn't get a call to even >>> > start > >>> [GkStatus::Auth] >>> >>> rule=allow >>> >>> [RasSrv::RRQFeatures] >>> >>> SupportDynamicIP=1 >>> >>> Thank you for any hints you have for me...! >>> >>> Ken >>> >>> >>> > ------------------------------------------------------------------------ > >>> > ------------------------------------------------------------------------ > ------ > >>> >>> >>> > ------------------------------------------------------------------------ > >>> _______________________________________________________ >>> >>> Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx >>> Archive: >>> > http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users > >>> Unsubscribe: >>> > http://lists.sourceforge.net/lists/listinfo/openh323gk-users > >>> Homepage: http://www.gnugk.org/ >>> >>> >> >> > ------------------------------------------------------------------------ > ------ > >> _______________________________________________________ >> >> Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx >> Archive: >> > http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users > >> Unsubscribe: >> > http://lists.sourceforge.net/lists/listinfo/openh323gk-users > >> Homepage: http://www.gnugk.org/ >> >> >> > ------------------------------------------------------------------------ > ------ > >> _______________________________________________________ >> >> Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx >> Archive: >> > http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users > >> Unsubscribe: >> > http://lists.sourceforge.net/lists/listinfo/openh323gk-users > >> Homepage: http://www.gnugk.org/ >> >> > > > ------------------------------------------------------------------------ > ------ > _______________________________________________________ > > Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx > Archive: > http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users > Unsubscribe: > http://lists.sourceforge.net/lists/listinfo/openh323gk-users > Homepage: http://www.gnugk.org/ > > ------------------------------------------------------------------------ > ------ > _______________________________________________________ > > Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx > Archive: > http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users > Unsubscribe: > http://lists.sourceforge.net/lists/listinfo/openh323gk-users > Homepage: http://www.gnugk.org/ > > ---------------------------------------------------------------------------- > -- > _______________________________________________________ > > Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx > Archive: > http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users > Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users > Homepage: http://www.gnugk.org/ > > ---------------------------------------------------------------------------- > -- > > _______________________________________________________ > > Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx > Archive: > http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users > Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users > Homepage: http://www.gnugk.org/ > > > ------------------------------------------------------------------------------ > > _______________________________________________________ > > Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx > Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users > Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users > Homepage: http://www.gnugk.org/ > > ------------------------------------------------------------------------------ > > _______________________________________________________ > > Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx > Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users > Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users > Homepage: http://www.gnugk.org/ > ------------------------------------------------------------------------------ _______________________________________________________ Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/
