Remote J169 via SIP without VPN

[EyeHog]

Hey,

I've got a customer with some J169 phones that I've set up to work remotely on IP Office 11.0.4.2.0. I'm using port forwarding on the router using port 5160 external to 5060 internal (so it's not the standard port.) It will connect and work totally fine some of the time, but the other times it doesn't seem to even reach the phone system. Nothing changes between the times that it works, and it doesn't work. In Monitor, I don't see it trying to register at all. I get a message like this, and this is all I get. IP Address aa.aa.a.aa is the IP OFfice private IP address, and bb.bb.bbb.bbb is the public address of the remote location where the J169 is. cc.cc.c.cc is the address of a local B179, I'm not sure it's related, but I left it in here.

88416643mS Sip: SipTCPUser 216 has 0 dialog open (ActivityTimeoutCallback) activity_cnt 0 sip tcp connection {aa.aa.a.aa:5061,bb.bb.bbb.bbb:39349}
88416643mS Sip: SIPPhoneReceiver 218 disconnectIndication from tcp, srcaddress bb.bb.bbb.bbb
88416643mS Sip: SipTCPUser 216 incoming f16c35dc destroyed list size 0
88424152mS SIP Rx: UDP cc.cc.c.cc:5060 -> aa.aa.a.aa:5060
88427760mS Sip: SipTCPUser 217 incoming f16c35dc created local aa.aa.a.aa:5061 remote bb.bb.bbb.bbb:23135 list size 1

Any idea what any of this means? Google isn't doing me much good here. Also, in System Status I get the following alarm for the remote extension.

Protocol Error
Application: VoIP Extension
Telephone Type: Avaya J169 (SIP Feature)
Number: 353
Name: Remote 3




---EyeHog

 

[janni78]

I assume you enabled Remote Extension on the user?

Also you really should use TLS when connecting external devices.

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

 

[EyeHog]

Oh yeah, "Enable Remote Worker" is checked. They work, sometimes.

I'm a phone guy, not a network guy, so I'm struggling to catch up with the networking side of things. I'll give TLS a try.

---EyeHog

 

[janni78]

If you have changed the outside port you need to also configure Remote Port in System -> VoIP.
You might also need to put it Network Topology.

That could affect your SIP trunks tho if you have any.

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

 

[dsm600rr]

I have a J179 working perfectly with TLS

It is mainly setup for IX Workplace however once that is good so is the SIP J100

FQDN to Public IP

Split DNS to IPO

Correct Certificates in place and you should be good to go. I have a long post on eventually getting this to work here.

ACSS

 

[EyeHog]

Finally got back to the site to switch phones to TLS, and I get essentially the same message in System Monitor. The only difference is it's trying to use the TLS port, 5061. I have no idea what's blocking this where.... These phones worked fine the first day or so I had them set up remotely.

184071768mS Sip: SipTCPUser 78 incoming f169f420 created local 10.50.7.101:5061 remote xxx.183.204.65:22573 list size 1
184071928mS Sip: SIPPhoneReceiver 80 disconnectIndication from tcp, srcaddress xxx.183.204.65
184071928mS Sip: SipTCPUser 78 incoming f169f420 destroyed list size 0


---EyeHog

 

[EyeHog]

I also configured the remote Port in System -> VoIP and put it in Network Topology.

Same messages in System Monitor, phone still says acquiring service.


---EyeHog

 

[Travis Harper]

Network topology settings are very important.
When I used do this via port forwarding, I had to constantly change the Firewall Nat type to keep the service running. Like you, it would fine one day then mysteriously stop working the next day. I would switch from Full Cone Nat, to One to One and back and forth. Each time the service would work again for period of time. Sometimes days, and sometimes hours.

Eventually I just put the IP Office directly connected to the internet.
Like you, I use non standard SIP ports. I also use complex passwords and strict Whitelist, Blacklisting rules.
Never had a problem since.

One thing you may want to check in System Status. Check to see if the extension or remote IP has been blacklisted. That's what it sounds like is happening to me.

 

[janni78]

Please don't say you put the IP Office directly on the internet with a public IP ?

The IP Office is not a device built to be connected directly on internet and there are numerous ways to gain access or perform toll fraud with it regardless of how complex your passwords are.
There's even a lot of customer data available through interfaces that don't need passwords.

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

 

[critchey]

As previously stated it could be that the phone is being blacklisted/quarantined which would keep it from connecting. If you do have the IPO on a public it is also possible your system is being hammered so hard that it simply stops responding to requests (have seen this happen before). Public IP should NEVER be used, except in testing to say prove firewall is an issue, and it should be immediately taken off the public IP once the testing is finished and never left that way.

The truth is just an excuse for lack of imagination.

 

[Travis Harper]

I admit, I would not recommend customers put the IP Office directly on the internet, but it is actually a supported configuration using the built in linux IP tables. Those activated under platform view security.. although not recommended if your using non standard ports.

I have had my system directly connected for years, non standard ports, with no issues.

My ARS table is very restrictive. and the sip trunk provider settings I also only allow calls to specific area codes.
I've also changed my SSH ports to non standard ports.
White lists and Blacklists in place.
Within the linux OS I the fail2ban installed, and GeoIP blocking.
I check monitor often, and the only attempt to access my system are from the WebManager interface, and those are far and few between.

I know it sounds scary lol... but like I said no issues.



.

 

[derfloh]

You say it's actually a supported option. But changing the Linux (different SSH port, adjustment of IP tables, installation of additional software) is absolutely not supported by Avaya

IP Office remote service
IP Office certificate check
CLI based call blocking
SCN fallback over PSTN

 

[critchey]

Page 103 of the Avaya Security Guidelines for IP Office R11

9.1 Checks and Tests
Thorough checks and tests should be carried out to ensure the deployment is secure and no previous attacks have
compromised the system:
· Note:
Care must be taken not to inadvertently expose sensitive data as a by-product of testing activities.
· Check LAN1/LAN2 do not have public IP addresses, that is, directly accessible from the internet.
· Check the IP Office for unsecure internet or inbound IP access by identifying the public IP address of the
Firewall (for example, by using

http://whatismyipaddress.com),

then attempting access to the IP Office ports
defined by the Port Matrix document. The following table contains some example ports that should be tested.


I have not seen one single Avaya document stating that public IP is acceptable.


The truth is just an excuse for lack of imagination.

 

[Travis Harper]

Well, maybe I should revise my statement to "it works for me".

Under LAN1 NAT Type, OpenInternet is an option.

Open Internet: No action required. If this mode is selected, settings obtained by STUN lookups are ignored. The IP address used is that of the system LAN interface.

When else would you not require NAT, except for when directly connected to the internet?

 

[janni78]

You don't require NAT when you have a SIP trunk through a private MPLS from the service provider.
We use those solutions a lot and even in those cases we still have a firewall or SBC in between.

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

 

[loki88]

Great tips, thanks.

https://webllena.com/