Hi Jan, thanks for the pointer, though the solution still is a bit perplexing to me. I wonder, did the behavior of SupportNATedEndpoints change in the last few versions (my previous version was 2.2.2). We are currently intentionally setting SupportNATedEndpoints to discourage our users from attempting to use endpoints from behind NAT without converting their sourceCallSignalAddress to their public address using either the endpoints software or H.323 compatible firewalls. I understand that the SupportNATedEndpoints feature identifies endpoints that are behind NAT by seeing that the IP in the IP header does not match the IP in the Q.931. It then translates the IP address in the Q.931 to match the IP in the IP header. That is a useful feature, however, what happens in the case of calls being received from the neighbor gatekeeper? It detects the setup message as originating from behind NAT, because the IP in the Q.931 is the IP of the endpoint (public not behind NAT), but is different than the IP in the header since that is from the neighbor gatekeeper. If I switch on SupportNATedEndpoints to yes, then it would replace the IP of the gatekeeper in the sourceCallSignalAddress. Wouldn't this cause the called endpoint to then send H.245 packets to the neighbor gatekeeper instead of directly to the calling endpoints. I know that for our gatekeeper, we do not tunnel H.245 through the GK, and I believe that's true for many of our neighbored institutions (which use a myriad of various gk manufacturers). I'm worried that sending them the H.245 traffic may not work since they wouldn't be expecting it from us. In addition, we've noticed that simply replacing the IP in Q.931 doesn't always work in terms of getting past firewalls that are not H.323 enabled. Having the SupportNATedEndpoints helps enormously in troubleshooting endpoint users at the beginning when they are attempting to register, rather than at the last second as they are trying to call into their conference. IP Mismatches are much easier to troubleshoot than blanks screens or one way audio/video. Essentially, what it looks like is that there has been a change in behavior in the SupportNATedEndpoints feature that now not only blocks NATed registrations, but also attempted setup messages forwarded from neighbor gatekeepers in which the IP in the Q.931 necessarily differs from the IP of the header. Is there any way to allow those types of calls, while still keeping the SupportNATedEndpoints feature disabled like it used to work in 2.2.2? Would changing H245Routed to 0 help? Thanks, -Jeremy ---------------------------------------------------------------------- Message: 1 Date: Sat, 17 Jan 2009 09:40:16 +0100 From: Jan Willamowius <jan@xxxxxxxxxxxxxx> Subject: Re: No Longer Accepting Calls from Neighbor GK on 2.2.7 To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Message-ID: <20090117094016.6c6511e8@xxxxxxxxxxx> Content-Type: text/plain; charset=US-ASCII Hi Jeremy, you can avoid that particular error message by setting [RoutedMode] SupportNATedEndpoints=1 Regards, Jan Jeremy Wu wrote: > Hi Michal, > > I was able to gather a level 5 trace of the neighbor gatekeeper failed call. It looks like the issue is with the error that I get "Q931s Unregistered party is NATed. Not supported by policy. > > > 2009/01/15 15:22:14.185 4 ProxyChannel.cxx(1627) Q931s GWRewrite source for 72.233.250.179:1220: neighbor or explicit IP > 2009/01/15 15:22:14.185 3 gkauth.cxx(1067) GKAUTH default Setup check ok > 2009/01/15 15:22:14.185 5 Routing.cxx(201) ROUTING Checking policy Explicit for request Setup CRV=22781 > 2009/01/15 15:22:14.185 5 Routing.cxx(201) ROUTING Checking policy Internal for request Setup CRV=22781 > 2009/01/15 15:22:14.185 4 RasTbl.cxx(1416) Alias match for EP 69.91.223.144:1720 > 2009/01/15 15:22:14.185 5 Routing.cxx(207) ROUTING Policy Internal applied to the request Setup CRV=22781 > 2009/01/15 15:22:14.185 4 ProxyChannel.cxx(1948) Q931s Unregistered party is NATed. Not supported by policy. > 2009/01/15 15:22:14.185 2 RasTbl.cxx(2656) CallTable::Insert(CALL) Call No. 458, total sessions : 13 > 2009/01/15 15:22:14.185 2 gkacct.cxx(1028) GKACCT Successfully logged event 1 for call no. 458 > 2009/01/15 15:22:14.185 2 RasTbl.cxx(3063) CDR ignore not connected call > 2009/01/15 15:22:14.185 5 gkacct.cxx(806) GKACCT FileAcct - CDR string for event 2, call no. 458: CDR|458|02 2c 82 c5 4d 82 f7 15 3f 40 58 b1 96 17 04 ed|0|unconnected|Thu, 15 Jan 2009 15:22:14 -0800|72.233.250.179:1220| |69.91.223.144:1720|5068_gk2|0554444:dialedDigits|DougSR:h323_ID=2981232:dialedDigits|wa-k20-gk2; > 2009/01/15 15:22:14.185 3 gkacct.cxx(988) GKACCT FileAcct logged event 2 for call no. 458 > 2009/01/15 15:22:14.185 2 gkacct.cxx(1028) GKACCT Successfully logged event 2 for call no. 458 > 2009/01/15 15:22:14.186 4 ProxyChannel.cxx(842) Q931 Send to 72.233.250.179:1220 > > > I have the following settings on my GK: > > ;############################################################################ > ;# K20 Gatekeeper 2 configuration > ;############################################################################ > [Gatekeeper::Main] > Fourtytwo=42 > Name=wa-k20-gk2 > TimeToLive=60 > ;Home=216.186.94.5 > StatusPort=7000 > EndpointIDSuffix=_gk2 > > [RoutedMode] > GKRouted=1 > H245Routed=0 > CallSignalPort=1720 > AcceptUnregisteredCalls=1 > > AcceptNeighborsCalls=1 > RemoveH245AddressOnTunneling=1 > DropCallsByReleaseComplete=1 > SendReleaseCompleteOnDRQ=1 > > [RasSrv::LRQFeatures] > AcceptForwardedLRQ=1 > > > [RasSrv::Neighbors] > CWU=GnuGK > SeaGK=GnuGK > > [Neighbor::CWU] > GatekeeperIdentifier=CWU > Host=72.233.250.179 > SendPrefixes=298,0011479298 > AcceptPrefixes=* > > [RasSrv::LRQFeatures] > AlwaysForwardLRQ=1 > IncludeDestinationInfoInLCF=1 > CiscoGKCompatible=1 > ForwardHopCount=10 > > [RasSrv::RRQFeatures] > AliasTypeFilter=gateway;h323id > > [RasSrv::ARQFeatures] > ;Allows dialing the IP of an unregisterd endpoint > CallUnregisteredEndpoints=1 > RoundRobinGateways=1 > > [Gatekeeper::Auth] > ;use the PrefixAuth rules below to authorize all ARQs and LRQs. > PrefixAuth=required;ARQ,LRQ > default=allow > > > [PrefixAuth] > ALL=allow ipv4:ALL > > Any ideas on what parameters I'm missing that would lead it to reject the call based on the unregistered party being NAT'ed? > > Thanks, > -Jeremy > > > Jeremy Wu > Network Engineer, Customer Services > UW Technology Services > University of Washington > Box 355675 > Seattle, WA 98105-5675 > (Tel) 206-543-1981 (Fax) 206-685-7755 > > > > > > -----Original Message----- > From: Jeremy Wu > Sent: Friday, January 09, 2009 10:18 AM > To: 'openh323gk-users@xxxxxxxxxxxxxxxxxxxxx' > Subject: No Longer Accepting Calls from Neighbor GK on 2.2.7 > > So I tried using the following syntax: > > [RasSrv::LRQFeatures] > AcceptForwardedLRQ=1 > > [RasSrv::Neighbors] > CWU=GnuGK > > [Neighbor::CWU] > GatekeeperIdentifier=CWU > Host=72.233.250.179 > SendPrefixes=298,0011479298 > AcceptPrefixes=* > > And a call from the CWU gatekeeper (GK_C) to mine is still following the pattern where the setup message is received from GK_C, and my gatekeeper (GK_B) is sending back a ReleaseComplete. > > Any other ideas? > > Thanks, > -Jeremy > > -----Original Message----- > From: Jeremy Wu > Sent: Friday, January 09, 2009 8:58 AM > To: 'openh323gk-users@xxxxxxxxxxxxxxxxxxxxx' > Subject: RE: Openh323gk-users Digest, Vol 32, Issue 4 > > Thanks Michal, I was looking at that. My one question was in the [RasSrv::Neighbors] section, there are only 4 options for types of gatekeeper (GnuGK, CiscoGK, ClarentGK, GlonetGK). Do I just use GnuGK to identify Polycom neighbor gatekeepers as shown in your example? > > Thanks, > -Jeremy > ------------------------------ > > Message: 5 > Date: Fri, 9 Jan 2009 08:59:23 +0100 > From: "Zygmuntowicz Michal" <m.zygmuntowicz@xxxxxxx> > Subject: Re: No Longer Accepting Calls from > Neighbor GK on2.2.7 > To: "GNU Gatekeeper Users" <openh323gk-users@xxxxxxxxxxxxxxxxxxxxx> > Message-ID: <F99113EBC934431BB9BF014E0C33DD2E@treasure> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=original > > Please check the new syntax for neighbor configuration - it should look like: > > [RasSrv::Neighbors] > GK_C=GnuGk > > [Neighbor::GK_C] > Host=72.233.250.179 > AcceptPrefixes=298,0011479298 > ... > > ----- Original Message ----- > From: "Jeremy Wu" <doctorwu@xxxxxxxxxxxxxxxx> > To: <Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx> > Sent: Friday, January 09, 2009 2:09 AM > Subject: No Longer Accepting Calls from Neighbor GK on2.2.7 > > > > I'm wondering if someone can help me figure out what I'm missing. I've been running an GnuGK on 2.2.2 for many years, and have > > recently implemented a secondary GnuGK on 2.2.7. > > > > I've used pretty much the same config file for both GK. However, I am currently unable to receive calls from neighbored GKs on > > the gatekeeper running 2.2.7. So if my GK_A is my 2.2.2 gatekeeper, and GK_B is my 2.2.7 gatekeeper, I have a colleague running a > > GK_C that is a Polycom Path Navigator. GK_C is neighbored to both GK_A and GK_B with different prefixes. > > > > Using Wireshark I can see that calls from GK_C to GK_A process fine. But on calls from GK_C to GK_B, the 2.2.7 gatekeeper replies > > to his Setup message with a ReleaseComplete. I can make calls between endpoints registered on GK_B fine, and I can actually call > > from an endpoint on GK_B to GK_C successfully. I can also make calls between GK_A and GK_B successfully. > > > > I believe that I have the basic peering configurations set appropriately. > > > > [RoutedMode] > > AcceptNeighborsCalls=1 > > > > [RasSrv::Neighbors] > > GK_C=72.233.250.179;298,0011479298 > > > > And the fact that this same configuration works on my GnuGK running 2.2.2 confuses me. Am I missing a new parameter that was > > introduced in later revs? > > > > Thanks, > > -Jeremy -- Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/ ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________________ 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/
