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

Re: Using GnuGK as Transversal Gatekeeper



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
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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/
>>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure

------------------------------

_______________________________________________
Openh323gk-users mailing list
Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openh323gk-users


End of Openh323gk-users Digest, Vol 70, Issue 9
***********************************************

________________________________

----- 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.


------------------------------------------------------------------------------
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/


[SIP]     [Open H.323]     [Gnu Gatekeeper]     [Asterisk PBX]     [ISDN Cause Codes]     [Singles Community]     [Yosemite News]

Add to Google Powered by Linux