It is a strange problem. I haven't been able to isolate what
exactly it takes to cause it. My hunch is that the presence of
extra interfaces, and/or a longer than usual routing table has
something to do with it. As I mentioned before, if I flip back to
GnuGk 2.3.5, the problem goes away. For now I have a work around
where I specify the "ExternalIP", which isn't meant for our type of
setup, in the configuration to be the local public interface IP.
I'll try latest CVS version, and if that doesn't work, we'll
probably get a support package and have Jan look into the problem
for us.
Cheers,
Abes
On 12-03-22 02:31 PM, Gabriel Georgescu wrote:
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/
|
