Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations John Tel on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Routers that don't work for Remote workers 1

Status
Not open for further replies.

amriddle01

Programmer
May 2, 2007
23,938
GB
To save your hair [hairpull3] don't send the 96xx handsets (56xx work too btw) to remote workers using NAT'd phones if they have a Draytek router or a DLink Sky broadband router, when testing from home (on the DLink) I got one way audio, so I took it to the office and it sat at discover, I needed to put it on DMZ on the Draytek to "see" the system and then you got no audio.....basically stay away from the 2 routers I mentioned, there may be more though.

They run happily on crappy £30 Thomson routers btw :)

 
I have seen this happening on Cisco 8XX serie routers.
They do work on DSL 2640B


BAZINGA!

I'm not insane, my mother had me tested!

 
it is probably a safe rule of thumb that the more expensive the home router the more likely it is to try to be 'helpfull' with the VoIP traffic & stuff (Tech Term) things over.



A Maintenance contract is essential, not a Luxury.
Do things on the cheap & it will cost you dear
 
It seems to be mainly Avaya's issue from what I can see, I have just tried Avaya remote phones and Mitel remote phones on the same Dlink, Cisco, Draytek and Thomson routers, the Mitel's are setup exactly the same way as the Avaya ones so just port forwarding at system side, nothing home side. The Mitel works on every router the Avaya either gets no audio or one way audio on the first 3 mentioned, only the thomson router lets it through. Avaya must be doing something non compliant or silly at some point :)

 
Andy, we used a dlink and it worked.
see my first post for the type.


BAZINGA!

I'm not insane, my mother had me tested!

 
Doesn't matter what type really, we were hoping to do what we do with Mitel phones, fire them up, put firmware on correct level, enter the external ip and send them out...done. What we need to do here is make sure they don't have a certain Dlink router or Draytek or Cisco 800's and probably more and if they do swap the router out for one that does work. That is not possible in many cases and when it is possible it's an extra expense to an already expensive solution. It seems to be a poor implementation of the process when it works fine with another vendors equipment on the same site :)

 
Add BT Homehubs to the list of non-workers :)

 
Don't quite understand the OP - are you talking about VPN phones here, or using a 'normal' IP phone over public internet?
 
In R8 there is a remote worker option (remote h323 extension), where you send a normal 96xx handset out (no vpn) and it uses NAT traversal to connect to the system, you just enter the external address of the office router (which has some port forwarding on) and your'e away.....unless the remote user has one of the routers I have listed :)

 
Andy, what router does do the port forwarding?


BAZINGA!

I'm not insane, my mother had me tested!

 
Draytek 2820 (using open ports with ALG's off etc), I was thinking that maybe this was at fault but why would it work with any at all? Again a Mitel behind the same router works no problem, I hate comparing to a Mitel all the time but it just works :)

 
Obviously I'm out of date on IPO, but I've heard about this on Mitel for years, and CM has had a similiar feature for a long time too (but I've never used it).

AFAIK on a basic level this feature takes the NAT address from the header and uses it to replace the internal address in the H323 packet, so the RTP is at least direct back to the user's public IP. From looking at the KB it will only work with certain types of NAT on the home router side. I guess the Mitel implementation has better NAT traversal methods.

I guess this is appealing due to low cost, but IMO putting any kind of business traffic over unencrypted internet connection is a terrible idea. Maybe Avaya will do something interesting for IPO with Sipera for remote connectivity over TLS.
 
The security aspect is the customers decision, if they want to do it we make them aware of the risks. Avaya must see benefit in it as they would not have spent time/money developing it. The benefit is you don't have loads of VPN's to administer, you don't need special firmware on handsets (this can be troublesome in itself) and many routers block VPN passthrough anyway.

In truth though the process involved in intercepting the traffic from a remote worker to the system (and they would need to know it was happening to begin with) and the motivation to even try it means it's fairly safe anyway. If someone goes to that trouble I don't think the company selling turf to Mrs Miggins would be too bothered if the conversation was overheard by a geek with a laptop anyway :)

 
> If someone goes to that trouble I don't think the company selling turf to Mrs Miggins would be too bothered if the conversation was overheard by a geek with a laptop anyway

I'd be concerned that if the call can be listened to, a new call can be generated...

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.
 
I think Matt's concern is the biggest, I'm not sure what (if any) security is used for the H323 login, so if someone can capture a login session then they are free to login and generate calls.

I agree that VPNs are a pain, that's why things like Sipera products are gonna be big in the future (IMO at least).
 
People suggest things wihout considering what's actually required to accomplish what you are suggesting, it isn't as easy as sitting on the web with wireshark running, you need motivation and know how to do it and if you have that a VPN is easy enough to break too :)

 
Andy, have you tried changing the draytek in your office? And are you using the latest build, they have load of by fixes for Nat.
 
>People suggest things wihout considering what's actually required to accomplish what you are suggesting

Once the exploit has been found, it is really no great amount of work to scan internet facing addresses looking for that vulnerability. The internet is a full of people/hacker/script kiddies looking for a chink in the armour. Personally, I'd rather use a VPN - I'd challenge the assertion that they are easy to break (assuming people don't use simple passwords)

I offer a couple of examples - our firewalls at work are probed virtually every minute on port 5060 (and yes I appreciate the difference between SIP and H.323)

Likewise, have you tried putting an un-patched exchange server exposed on port 25... I reckon you'd be relaying spam inside 12 hours.

I may not know precisely how to exploit a NAT traversal phone, but I am aware that it is not entirely risk free.



Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.
 
Funny enough, Draytek is basically all we use, Remote Extensions work like a charm, mostly :)

Our own IPO is behind a Draytek, R.E. works like a charm.
One of our client's IPO is also behind a Draytek, and so is our office data network btw (other than IPO), tested their R.E. from our office, no problem, phone came right up.

Then the client took the phone home, behind his ISP's router-modem, big no no. Phone is stuck on a screen that only says 'Phone', I can see the phone, but monitor says the phone model is 'No Phone', but with the IP adress of the client's home.

So it's not that black n'white I'm afraid :)
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top