Lucas, take a look at the manual how routing policies are configured: They form a chain and you can define which routing methods are used and in which order. The call will be passed from one policy to the next until one policy decides it knows how to handle the call. Regards, Jan Lucas Phelps wrote: > Jan, > > Thanks for the tip. I will neighbor the two and do they automatically search each other for calls that they cannot route? > > For endpoints on my internal network that are registered to my internal gatekeeper, how do I force them to go through BOTH gatekeepers when making a call to the Internet? > > On the DMZ gatekeeper, how does it know to try all calls to the Internet? > > Confused on how all this works with dual gatekeepers and call routing..thanks so much > > -Lucas > > -----Original Message----- > From: openh323gk-users-request@xxxxxxxxxxxxxxxxxxxxx [mailto:openh323gk-users-request@xxxxxxxxxxxxxxxxxxxxx] > Sent: Thursday, March 22, 2012 1:32 PM > To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx > Subject: Openh323gk-users Digest, Vol 70, Issue 9 > > Send Openh323gk-users mailing list submissions to > openh323gk-users@xxxxxxxxxxxxxxxxxxxxx > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/openh323gk-users > or, via email, send a message with subject or body 'help' to > openh323gk-users-request@xxxxxxxxxxxxxxxxxxxxx > > You can reach the person managing the list at > openh323gk-users-owner@xxxxxxxxxxxxxxxxxxxxx > > When replying, please edit your Subject line so it is more specific than "Re: Contents of Openh323gk-users digest..." > > > Today's Topics: > > 1. Using GnuGK as Transversal Gatekeeper (Lucas Phelps) > 2. Re: gk security issue (Jan Willamowius) > 3. Re: Using GnuGK as Transversal Gatekeeper (Jan Willamowius) > 4. Re: gk security issue (Bruno Richard) > 5. Re: Proxy mode putting wrong interface IP in OLC message > (Gabriel Georgescu) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 22 Mar 2012 14:43:05 +0000 > From: "Lucas Phelps" <lphelps@xxxxxxxx> > Subject: Using GnuGK as Transversal Gatekeeper > To: <openh323gk-users@xxxxxxxxxxxxxxxxxxxxx> > Message-ID: > <C8CE2105FFC3074EA6A802375D6E888C2C25B904@xxxxxxxxxxxxxxxxxxxx> > Content-Type: text/plain; charset="us-ascii" > > Hi all, in the past I've used GnuGK as our internal VC gatekeeper and it was worked well. I now want to add a GnuGK box into our DMZ that would communicate with our internal GnuGK. Hopefully to give Internet users the ability to call into our system. > > Does anybody have a sample configuration for each of the boxes? How do I publish my internal E.164 addresses to the DMZ GnuGK box? My config is below, thanks for any help. > > [Gatekeeper::Main] > FortyTwo=42 > EndpointSuffix=_gnugk > ; change this to 1 or 2, if you want CDRs and RAS messages to be printed on the status port > StatusTraceLevel=2 > ; enable these options if your endpoints use broadcast and/or multicast to discover the gatekeeper > UseMulticastListener=0 > TimeToLive=120 > > [RoutedMode] > ; enable gatekeeper signaling routed mode, route H.245 channel only if neccessary (for NATed endpoints) > GKRouted=1 > H245Routed=1 > AcceptNeighborCalls=1 > AcceptUnregisteredCalls=1 > RemoveH245AddressOnTunneling=1 > 1RemoveCallOnDRQ=1 > DropCallsByReleaseComplete=1 > 1SendReleaseCompleteOnDRQ=1 > SupportNATedEndpoints=1 > TranslateFacility=1 > SocketCleanupTimeout=1000 > ;GenerateCallProceeding=1 > > ; proxy calls only for NATed endpoints > [Proxy] > Enable=0 > ; if port forwarding is correctly configured for each endpoint, you can disable ProxyForNAT > ProxyForNAT=1 > ProxyForSameNAT=0 > > [RasSrv::RRQFeatures] > ; endpoint identifiers are assigned by the gatekeeper > AcceptEndpointIdentifier=0 > ; you may want to disable this, if you want to control gateway prefixes from the config > AcceptGatewayPrefixes=1 > SupportDynamicIP=1 > > [CallTable] > ; don't print CDRs for neighbor calls to the status port > GenerateNBCDR=1 > ; print CDRs for unconnected calls to the status port > GenerateUCCDR=1 > ;Limit the maximum call duration (seconds), set to 0 to disable. > 432000=12 hours > DefaultCallDurationLimit=43200 > > [RasSrv::Neighbors] > GK2=192.168.1.10;* > > [Endpoint] > Gatekeeper=192.168.1.10 > Type=Gateway > RRQRetryInterval=10 > Prefix=* > TimeToLive=900 > Discovery=0 > > [LogFile] > Rotate=Daily > RotateTime=00:01 > > [CTI::Agents] > > ________________________________ > > ----- IRS CIRCULAR 230 NOTICE ----- > IRS Circular 230 regulates written tax communications between tax advisors and clients. In compliance with these IRS requirements, we are required to inform you that any tax advice contained in this communication (including any attachments) is not intended or written to be used, and cannot be used, for the purpose of avoiding penalties imposed by any governmental taxing authority or agency. If you would like us to provide written tax advice to protect against penalties, please contact us. > > In addition, any tax advice contained in this communication (including any attachments) cannot be used for promoting, marketing or recommending to another party any transaction or matter addressed. Any taxpayer who is not the addressee of this letter should seek specific advice based on that taxpayer's particular circumstances from an independent tax advisor. > > ******** Internet Email Confidentiality Notice ******** > > Privileged / Confidential Information may be contained in this message. > If you are not the addressee indicated in this message (or responsible for delivery of the message to such person) you may not copy or deliver this message to anyone. In such case, you should destroy this message (and attachments) and kindly notify the sender by reply email. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to official business of my firm shall be understood as neither given nor endorsed by it. > > > > > ------------------------------ > > Message: 2 > Date: Thu, 22 Mar 2012 16:27:41 +0100 > From: Jan Willamowius <jan@xxxxxxxxxxxxxx> > Subject: Re: gk security issue > To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx > Message-ID: <20120322162741.4ec50043@xxxxxxxxxxx> > Content-Type: text/plain; charset=US-ASCII > > Hi Bruno, > > the InternalNetwork switch is only meant to be used for the decision when to proxy a call. You want to use an authentication policy like FileIPAuth to decide who may use your gatekeeper. > http://www.gnugk.org/gnugk-manual-8.html#ss8.2 > > Regards, > Jan > > Bruno Richard wrote: > > Hi all, > > > > I use two clients to get h323 communications via gk : M100 and EVO (http://evo.caltech.edu/evoGate/). > > - M100 could registered on the gk, no pb with it. > > - but EVO could not. > > > > So if I want to use EVO with gk, I have to set the param : "AcceptUnregisteredCalls=1". > > For obvious security reasons I want to restrict the IP range that can acces my gk. > > I thought that I could restrict it with the param InternalNetwork > > (proxy is enable on my gk) However even with the config bellow, I can connect to the gk with an EVO client that has the IP 172.16.7.... > > > > [Proxy] > > Enable=1 > > ProxyAlways=1 > > InternalNetwork=192.168.0.0/255.255.0.0 > > > > > > I hope I'm clear !! > > Thanks in advance. > > Bruno > > > > > > > > > > > -- > Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/ > > > > ------------------------------ > > Message: 3 > Date: Thu, 22 Mar 2012 16:37:11 +0100 > From: Jan Willamowius <jan@xxxxxxxxxxxxxx> > Subject: Re: Using GnuGK as Transversal Gatekeeper > To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx > Message-ID: <20120322163711.4214d207@xxxxxxxxxxx> > Content-Type: text/plain; charset=US-ASCII > > Hi Lucas, > > one way is to make the internal gatekeeper the child of the external > gatekeeper as you already seem to be doing, but it is usually better to > make them both neighbors. Then they will query each other for each call > they can't resolve locally. > > Regards, > Jan > > Lucas Phelps wrote: > > Hi all, in the past I've used GnuGK as our internal VC gatekeeper and it was worked well. I now want to add a GnuGK box into our DMZ that would communicate with our internal GnuGK. Hopefully to give Internet users the ability to call into our system. > > > > Does anybody have a sample configuration for each of the boxes? How do I publish my internal E.164 addresses to the DMZ GnuGK box? My config is below, thanks for any help. > > > > [Gatekeeper::Main] > > FortyTwo=42 > > EndpointSuffix=_gnugk > > ; change this to 1 or 2, if you want CDRs and RAS messages to be printed on the status port > > StatusTraceLevel=2 > > ; enable these options if your endpoints use broadcast and/or multicast to discover the gatekeeper > > UseMulticastListener=0 > > TimeToLive=120 > > > > [RoutedMode] > > ; enable gatekeeper signaling routed mode, route H.245 channel only if neccessary (for NATed endpoints) > > GKRouted=1 > > H245Routed=1 > > AcceptNeighborCalls=1 > > AcceptUnregisteredCalls=1 > > RemoveH245AddressOnTunneling=1 > > 1RemoveCallOnDRQ=1 > > DropCallsByReleaseComplete=1 > > 1SendReleaseCompleteOnDRQ=1 > > SupportNATedEndpoints=1 > > TranslateFacility=1 > > SocketCleanupTimeout=1000 > > ;GenerateCallProceeding=1 > > > > ; proxy calls only for NATed endpoints > > [Proxy] > > Enable=0 > > ; if port forwarding is correctly configured for each endpoint, you can disable ProxyForNAT > > ProxyForNAT=1 > > ProxyForSameNAT=0 > > > > [RasSrv::RRQFeatures] > > ; endpoint identifiers are assigned by the gatekeeper > > AcceptEndpointIdentifier=0 > > ; you may want to disable this, if you want to control gateway prefixes from the config > > AcceptGatewayPrefixes=1 > > SupportDynamicIP=1 > > > > [CallTable] > > ; don't print CDRs for neighbor calls to the status port > > GenerateNBCDR=1 > > ; print CDRs for unconnected calls to the status port > > GenerateUCCDR=1 > > ;Limit the maximum call duration (seconds), set to 0 to disable. > > 432000=12 hours > > DefaultCallDurationLimit=43200 > > > > [RasSrv::Neighbors] > > GK2=192.168.1.10;* > > > > [Endpoint] > > Gatekeeper=192.168.1.10 > > Type=Gateway > > RRQRetryInterval=10 > > Prefix=* > > TimeToLive=900 > > Discovery=0 > > > > [LogFile] > > Rotate=Daily > > RotateTime=00:01 > > > > [CTI::Agents] > > -- > Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/ > > > > ------------------------------ > > Message: 4 > Date: Thu, 22 Mar 2012 16:38:18 +0100 > From: Bruno Richard <bruno.richard@xxxxxxxxxxxxxx> > Subject: Re: gk security issue > To: GNU Gatekeeper Users <openh323gk-users@xxxxxxxxxxxxxxxxxxxxx> > Message-ID: <0A05DA37-02EC-42F9-95CF-48A0D6C15F8A@xxxxxxxxxxxxxx> > Content-Type: text/plain; charset="iso-8859-1" > > thanks and sorry for the disturb... > (it's a shame to miss such section !!!) > Best regards, > Bruno > Le 22 mars 2012 ? 16:27, Jan Willamowius a ?crit : > > > Hi Bruno, > > > > the InternalNetwork switch is only meant to be used for the decision > > when to proxy a call. You want to use an authentication policy like > > FileIPAuth to decide who may use your gatekeeper. > > http://www.gnugk.org/gnugk-manual-8.html#ss8.2 > > > > Regards, > > Jan > > > > Bruno Richard wrote: > >> Hi all, > >> > >> I use two clients to get h323 communications via gk : M100 and EVO (http://evo.caltech.edu/evoGate/). > >> - M100 could registered on the gk, no pb with it. > >> - but EVO could not. > >> > >> So if I want to use EVO with gk, I have to set the param : "AcceptUnregisteredCalls=1". > >> For obvious security reasons I want to restrict the IP range that can acces my gk. > >> I thought that I could restrict it with the param InternalNetwork (proxy is enable on my gk) > >> However even with the config bellow, I can connect to the gk with an EVO client that has the IP 172.16.7.... > >> > >> [Proxy] > >> Enable=1 > >> ProxyAlways=1 > >> InternalNetwork=192.168.0.0/255.255.0.0 > >> > >> > >> I hope I'm clear !! > >> Thanks in advance. > >> Bruno > >> > >> > >> > >> > > > > > > -- > > Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/ > > > > ------------------------------------------------------------------------------ > > This SF email is sponsosred by: > > Try Windows Azure free for 90 days Click Here > > http://p.sf.net/sfu/sfd2d-msazure > > _______________________________________________________ > > > > 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/ > > --------------------------------------------------------------------- > Bruno RICHARD > Division des Syst?mes d'Information > Universit? du Maine > Av. O. MESSIAEN 72085 LE MANS CEDEX 9 > email : Bruno.Richard@xxxxxxxxxxxxxx > T?l. : +33 2.43.83.27.79 Fax : +33 2 43 83 38 01 > --------------------------------------------------------------------- > > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 5 > Date: Thu, 22 Mar 2012 20:31:32 +0200 > From: Gabriel Georgescu <gabigeo@xxxxxxxxxxx> > Subject: Re: Proxy mode putting wrong interface IP > in OLC message > To: Abes Dabir <abes.dabir@xxxxxxxxxxxxx> > Cc: GNU Gatekeeper Users <openh323gk-users@xxxxxxxxxxxxxxxxxxxxx> > Message-ID: <4F6B7004.8090004@xxxxxxxxxxx> > Content-Type: text/plain; charset="iso-8859-1" > > I'm sorry Abes, I hoped for a quick solution. > It is odd that your other 3.0.1 box is not having this problem. Are you > sure that the settings are identical? > > Regards, > Gabriel > > On 20/03/2012 16:42, Abes Dabir wrote: > > Hi Gabriel, > > > > Thanks for the response. The "192.168.53.1" address is the GnuGk > > private IP address. The system running GnuGk is the gateway for the > > private network attached to it. 192.168.53.44 is the address of an > > endpoint on the private network that is being called. > > > > Abes > > > > On 12-03-20 04:17 AM, Gabriel Georgescu wrote: > >> Hi, > >> > >> I think you should specify GnuGK's private IP address in Home not the > >> gateway .1. > >> > >> Home=80.241.68.122,192.168.53*.44*,127.0.0.1 > >> Regards, > >> Gabriel > >> > >> > >> On 19/03/2012 23:40, Abes Dabir wrote: > >>> Hi, > >>> > >>> I'm noticing an issue in GnuGk 3.0.1 in Proxy mode that isn't there in > >>> 2.3.5. My organization uses GnuGk for NAT traversal. We run GnuGk on > >>> the NAT gateway box in Proxy mode so that it has one interface on the > >>> private network, and one on the public network. > >>> > >>> In a reproducible scenario: > >>> > >>> 1. A call comes in from the public Internet > >>> 2. GnuGk routes it to the proper endpoint on the private network > >>> (192.168.53.44) > >>> 3. When the private endpoint sends an OLC out, GnuGk re-writes the media > >>> control IP before sending it out the public interface, but, it puts the > >>> private network interface IP (192.168.53.1) in the outgoing message > >>> instead of the public interface IP (80.241.68.122). > >>> > >>> I swapped GnuGk 3.0.1 with 2.3.5, and the issue went away. We have > >>> another GnuGk 3.0.1 box that is setup similar to the problematic one, > >>> with practically identical configuration, but the problem isn't present > >>> on it. I would appreciate any help you could provide. I've included > >>> our GnuGk configuration in this post. I can also provide wireshark > >>> traces and GnuGk logs if needed. > >>> > >>> Thanks, > >>> > >>> Abes Dabir > >>> > >>> > >>> > >>> GnuGk configuration: > >>> ----------------------------- > >>> > >>> [Gatekeeper::Main] > >>> Fourtytwo=42 > >>> Name=MagorH323GK > >>> TimeToLive=100 > >>> StatusPort=7000 > >>> TraceLevel=3 > >>> Home=80.241.68.122,192.168.53.1,127.0.0.1 > >>> # TotalBandwidth=128000 > >>> # > >>> # each G.723.1 call consume 1280 Bps. > >>> > >>> > >>> [RoutedMode] > >>> GKRouted=1 > >>> H245Routed=1 > >>> AcceptUnregisteredCalls=1 > >>> AcceptNeighborsCalls=1 > >>> CallSignalPort=1720 > >>> CallSignalHandlerNumber=1 > >>> RemoveH245AddressOnTunneling=1 > >>> DropCallsByReleaseComplete=1 > >>> SupportNATedEndpoints=1 > >>> SupportCallingNATedEndpoints=1 > >>> Q931PortRange=20000-20099 > >>> H245PortRange=30000-30099 > >>> SendReleaseCompleteOnDRQ=1 > >>> > >>> [Proxy] > >>> Enable=1 > >>> # InternalNetwork can be a comma separated, CIDR format, list > >>> InternalNetwork=192.168.53.1/255.255.255.0 > >>> T120PortRange=40000-49999 > >>> RTPPortRange=40000-49999 > >>> ProxyForNAT=1 > >>> ProxyForSameNAT=0 > >>> ProxyAlways=1 > >>> > >>> [RasSrv::LRQFeatures] > >>> NeighborTimeout=6 > >>> ForwardHopCount=8 > >>> AlwaysForwardLRQ=1 > >>> IncludeDestinationInfoInLCF=1 > >>> CiscoGKCompatible=1 > >>> > >>> [RoutingPolicy] > >>> default=explicit,internal,enum,srv,dns > >>> > >>> [GkStatus::Auth] > >>> rule=explicit > >>> DelayReject=5 > >>> 127.0.0.1=allow > >>> > >>> [LogFile] > >>> Rotate=Weekly > >>> RotateDay=Sun > >>> RotateTime=00:59 > >>> Filename=/var/log/magor/gnugk/gnugk.log > >>> > >>> [PortNotifications] > >>> Q931PortOpen=/opt/magor/util/scripts/firewall/gnugk/open-pinhole-inbound-gnugk.sh > >>> %p %n %i > >>> Q931PortClose=/opt/magor/util/scripts/firewall/gnugk/close-pinhole-inbound-gnugk.sh > >>> %p %n %i > >>> H245PortOpen=/opt/magor/util/scripts/firewall/gnugk/open-pinhole-inbound-gnugk.sh > >>> %p %n %i > >>> H245PortClose=/opt/magor/util/scripts/firewall/gnugk/close-pinhole-inbound-gnugk.sh > >>> %p %n %i > >>> RTPPortOpen=/opt/magor/util/scripts/firewall/gnugk/open-pinhole-inbound-gnugk.sh > >>> %p %n %i > >>> RTPPortClose=/opt/magor/util/scripts/firewall/gnugk/close-pinhole-inbound-gnugk.sh > >>> %p %n %i > >>> > >>> > >>> > >>> ifconfig output: > >>> --------------------- > >>> > >>> > >>> eth0 Link encap:Ethernet HWaddr b8:ac:6f:97:bd:df > >>> inet addr:80.241.68.122 Bcast:80.241.68.123 > >>> Mask:255.255.255.252 > >>> inet6 addr: fe80::baac:6fff:fe97:bddf/64 Scope:Link > >>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > >>> RX packets:45819933 errors:0 dropped:0 overruns:0 frame:0 > >>> TX packets:42573664 errors:0 dropped:0 overruns:0 carrier:0 > >>> collisions:0 txqueuelen:1000 > >>> RX bytes:38553184779 (38.5 GB) TX bytes:23574871690 (23.5 GB) > >>> Interrupt:16 Memory:da000000-da012800 > >>> > >>> eth1 Link encap:Ethernet HWaddr b8:ac:6f:97:bd:e0 > >>> inet addr:192.168.53.1 Bcast:192.168.53.255 Mask:255.255.255.0 > >>> inet6 addr: fe80::baac:6fff:fe97:bde0/64 Scope:Link > >>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > >>> RX packets:42636374 errors:0 dropped:0 overruns:0 frame:0 > >>> TX packets:45361672 errors:0 dropped:0 overruns:0 carrier:0 > >>> collisions:0 txqueuelen:1000 > >>> RX bytes:23556913740 (23.5 GB) TX bytes:38301753151 (38.3 GB) > >>> Interrupt:17 Memory:dc000000-dc012800 > >>> > >>> lo Link encap:Local Loopback > >>> inet addr:127.0.0.1 Mask:255.0.0.0 > >>> inet6 addr: ::1/128 Scope:Host > >>> UP LOOPBACK RUNNING MTU:16436 Metric:1 > >>> RX packets:5140965 errors:0 dropped:0 overruns:0 frame:0 > >>> TX packets:5140965 errors:0 dropped:0 overruns:0 carrier:0 > >>> collisions:0 txqueuelen:0 > >>> RX bytes:486955198 (486.9 MB) TX bytes:486955198 (486.9 MB) > >>> > >>> Plus 3 OpenVpn tunnel interfaces -- Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/ ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________________ 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/
