Avaya IP Office H323 Remote Extension Problem

[Jim Mc]

Hi,

We have configured our IP Office 500 v2 to allow remote extensions for three users to connect remotely to it without the need of a VPN.

We have three extension numbers for the remote users - 2246 (1616i handset), 2247 (9620 handset) and 2248 (9620 handset). The first two extensions are in Remote Office 1 and do not work. The 2248 extension is in Remote Office 2 and works perfectly. There are no VPNs between the Remote Offices and Head Office. Both Remote Offices connect to the Internet through Draytek 2830 routers.

The handsets that do not work show "Discover <WAN IP of Avaya Base Unit>". All handsets are programmed the same in that the only item entered is the call server address and the subnet mask of 255.255.255.0. All other network settings are set to 0.0.0.0. All handsets are receiving valid DHCP settings. We have cleared and reconfigured the handsets several times trying both static and DHCP addressing.

All users are set up correctly and I can log in as any of them on the handset that does work and everything is fine.

In System Monitor we can see the 2246 and 2247 handsets trying to connect in the logs:
1193667592mS H323Evt: Recv GRQ from c3a69b80
1193667593mS H323Evt: e_H225_AliasAddress_dialedDigits alias
1193667593mS H323Evt: found number <2247>
1193668481mS H323Evt: Shared tcp socket for line 20 disconnected
1193669520mS H323Evt: IRCheckTimer: GRQ record deleted (user name=; extn-num=2247)

And for the 2248 we get:
1193728072mS H323Evt: Recv GRQ from 50e5e9ea
1193728072mS H323Evt: e_H225_AliasAddress_dialedDigits alias
1193728073mS H323Evt: found number <2248>
1193728144mS H323Evt: Recv: RegistrationRequest <Remote Office 2 WAN>; Endpoints registered: 5; Endpoints in registration: 0
1193728144mS H323Evt: e_H225_AliasAddress_dialedDigits alias
1193728145mS H323Evt: found number <2248>
1193728145mS H323Evt: RRQ --- CallSigProtocol is H323AnnexL_P. Go for Avaya 4600IP phone
1193728145mS H323Evt: RRQ --- Treat this as a forced login, the phone was probably rebooted (same_cs_addr 0)
1193728145mS H323Evt: GK: Unregister endpoint <system>_5a786c74306073a4 for extension 2248
1193728148mS H323Evt: GK: Send URQ
1193728149mS H323Evt: RRQ --- Register extn 2248 using product IP_Phone, version 3.103S
1193728149mS H323Evt: <2248> registered, ipo behind nat 1, phone behind nat 1

We use a Draytek 3900 firewall in Head Office, and have opened ports 1719 UDP, 1800 TCP (tried 1720 as well but were advised to use 1800) and 49152-53246 for TCP/UDP and have restricted access to these ports for both static WAN addresses of the Remote Offices.

We can see in the logs in the Draytek 3900 that handsets in Remote Office 1 try to connect to port 1719 from a variety of legitimate ports in the range for approximately 30 seconds before trying the next port up in the range. So we can see them connecting from Remote.Office.1.WAN:50204 then 50205, 50206 etc. From the handset that successfully connects from Remote Office 2, it shows an established connection to port 1800 on the Avaya Base Unit.

On the base unit we use LAN1 to connect to our main office network with IP address 10.1.0.20, and LAN2 for the phones, on its own VLAN, with a 10.10.11.1 IP address acting as a DHCP server. STUN works on LAN2 and returns "Port Restricted Cone NAT". We have an IP route of 0.0.0.0 on LAN2 with the gateway set as 10.10.11.254. We also have four other Avaya IP phones across the Head Office LAN and they all work fine. The rest of the phones are digital. We also have plenty free licenses.

Anyone have any ideas why the Remote Office 1 handsets won't connect?

Many thanks,

Jim.

 

[Westi]

The 1600 phones do not work as remote users.
Only the 9600 series works

Joe W.

FHandw, just expired ACSS (SME)


"This is the end of the world, make sure to buy your T-shirt before it is too late"
Original expression of my daughter

 

[Jim Mc]

Hi Westi,

Thanks for taking the time to reply. Yes, I read that too. However, I can confirm that we have used the 1616i successfully remotely before connecting in the same way. We used to have one in Remote Office 1 but only require one handset there now. Our supplier said that technically the 1616i should work but wasn't supported, so we tried it and it worked fine. Call quality was excellent. The problem affects both handsets in Remote Office 1 though.

Thanks,

Jim.

 

[Pepp77]

You would be better off creating a VPN between the two locations and running the phones over that.

| ACSS SME |

 

[Westi]

For testing I have a remote user setup in my home system and if I have issues on a customer site I register to my system instead.
If that works I know the issue is on the main site if not it is on the remote.
Then you are not guessing which site is to blame and can start at the culprit.

Joe W.

FHandw, just expired ACSS (SME)


"This is the end of the world, make sure to buy your T-shirt before it is too late"
Original expression of my daughter

 

[IPGuru]

NAT traversal remote handsets are a bad idea because of the security implications.
To attempt this with unsupported handsets is simply asking for trouble.

Follow Pepp77's advice and configure a Router to router VPN between the sites & save both your customer & yourself a lot of headaches



Do things on the cheap & it will cost you dear

 

[Jim Mc]

Hi,

Thanks to all who responded. I wish we had a test system!

We have routed the connection through a second Internet connection that was available and the handsets now work. However, they do both seem to reboot every minute or so, both at the same time, so we are setting up a VPN as suggested.

In our Avaya System Monitor, we can currently see the four onsite IP extensions that we have continually showing Registration Requests. They seem to do this every 10 seconds or so. Is this normal? (The two remote extensions are unplugged pending VPN setup and test)

Example:
1423596419mS H323Evt: Recv: RegistrationRequest 10.10.11.10; Endpoints registered: 4; Endpoints in registration: 0
1423602869mS H323Tx: dst=192.168.1.254:1720
H323 Pcol=0D(UNK) Reflen=0 ref=(Remote)
0000 0d 00 1f 01 01 00 00 00 0f 00 00 00 08 00 00 00 ................
0010 00 00 00 00 2c 49 50 20 35 30 30 20 56 32 00 ....,IP 500 V2.

Regarding the "dst=192.168.1.254:1720" line, we do not use that subnet anywhere on our network either locally or remotely so wondered where it came from?

Thanks again,

Jim.

 

[derfloh]

You can run IPO anywhere as a test system for up to seven extensions.

 

[Westi]

look into the firewall logs
looks kinda like Monitor and will show you if there is any traffic coming from the phones and what it does with it

Joe W.

FHandw, just expired ACSS (SME)


"This is the end of the world, make sure to buy your T-shirt before it is too late"
Original expression of my daughter

 

[teletechman]

try running a STUN test for the interface you are using. This has worked for the company I am now working with. I always suggest VPN phones so the was new to me.
Mike

 

[Jim Mc]

Thanks again for your responses.

We have now set up the Remote Office on a VPN and it works fine. The registration line keeps coming up but it seems to be part of what the phone system does as there's no adverse affect on the remote extensions. On the original connection, STUN resolved correctly. I will certainly look at IPO Anywhere when I have the time.

Remote Office 1 is in a shared office environment and has a WAN IP address assigned it from the block that the office owners have through a Cisco router. I think this Cisco device must be what is causing the problem, even though we were assured that our port on it was essentially a DMZ port.

All good now though with the VPN.

 

[janni78]

You didn't mention anything about a Cisco device =)
They can mess with H.323 traffic if it's not disabled.

"Trying is the first step to failure..." - Homer