Patton M-ATA-1A and NAT issue

[Georges Buisson]

Hello,

Seeking advice here.
We have a new customer on a hosted Debian 3CX (3CX and customer are therefore not on the same LAN).
Problem is with a Patton ATA which is NATed behind customer firewall. Everything works fine with the desk phones however.

Trying for the first time a Patton M-ATA as an ATA for some legacy fax machines.

Problem is with the SIP registration. The Contact header is simply "*" and I noticed there is no advanced NAT features offered by this product (none, UPnP and outbound proxy).

Anyhow, the REGISTER from the ATA hits 3CX coming with source port UDP/1027. However the reply from 3CX (401 Unauthorized) is sent to port 5060 instead of 1027. Here's what the REGISTER looks like:

UDP 10.9.8.7:1027 -> 12.13.14.15:5060
REGISTER sip:blah.com SIP/2.0
From: <sip[email protected];user=phone>;tag=gVr5h1-mgYqF
To: <sip[email protected];user=phone>
Call-ID: [email protected]
CSeq: 9 REGISTER
Via: SIP/2.0/UDP 172.22.0.115:5060;branch=z9hG4bKsFW5h1-NiLflFiv
Contact: *
Max-Forwards: 70
User-Agent: Patton Smartlink MATA <4.02.0A1 MS VR CS (0015)><00a0ba0c89cd>
Expires: 0
Content-Length: 0

Anyone encountered this situation with Patton M-ATA ?
I don't think this Contact header should be set like this. At worst it should be set with the internal network IP and let 3CX deal with a NAT situation an send the reply to the port request was received. There is not even an option to set rport parameter in the ATA.

Not really impressed with the quality of that Patton ATA software so far.
Next in line is to test T.38 robustness, but I need to get past this NAT issue.

Thanks any help provided.

 

[leejor]

If you have set the ATA to register as a 3CX Fax extension, then it will not register outside the local LAN, unless over VPN. That is the only way remote Fax is supported.

https://www.3cx.com/community/threads/old-school-fax-machine-on-new-school-3cx-server-cloud.50499/

 

[YiannisH_3CX]

Hello @Georges Buisson

Please note that ATAs and gateways are only supported for local registration by 3CX. As @leejor mentioned the best option is to use a VPN connection so you can register the PAtton device as local. Also trying to manually register the Patton device to a FAX extension remotely will not work as the phone system will accept remote registration requests for FAX extensions.

 

[Georges Buisson]

First, thanks to @leejor for the explanation and link. Very helpful.

@YiannisH_3CX :
Understood. However I find it unfortunate this limitation of completely disallowing either FXS or FAX extensions outside the LAN. There should be a on/off (advanced?) option to allow this with default setting off.
In the current case, it is not possible to install an SBC on premises, nor have a VPN tunnel. This is due to corporate IT policies.

In fact, I would be comfortable, security-wise, to allow the ATA to connect to the hosted 3CX server since the 3CX ports are protected at ingress by a firewall on the hosting side and allowing only specific traffic sources.

Looks like I have no other option for now but to hooks the fax ATAs to another platform

 

[cobaltit]

@Georges Buisson

So corporate IT policies are ok with a random device on your network and the requisite port forwarding but not ok with a VPN? Doesn't pass the sniff test. In fact your exact logic as to what you would be comfortable with also applies to a VPN setup so it really makes no sense.

That being said we don't ever advocate the use of ATA's with either 3CX or our hosted platform. We push customer to either a POTS line or our store and forward fax service.

 

[eddv123]

I have got plenty of ATA and FXS Gateway devices (supported and un-supported) setup to 3CX in the cloud using STUN (and direct SIP) as well as SBC - for standard analogue phones only.

FAX (as already pointed out) is not going to work in any other setup than local/locally routed Subnet to 3CX - you would be best opting for an online FAX service in my view.

 

[leejor]

A Fax extension over a remote ATA (not using VPN) is far too unreliable. That is the only thing that is disallowed (registration). Using a regular extension, while the ATA may not be supported, is not disallowed, and does work just fine.

 

[Georges Buisson]

@cobaltit

Yes you got that right sir. The corporate firewall is set to allow internal IPs on the trusted side to communicate to specific external IPs over certain ports (SIP + RTP).
However an IPSEC tunnel to a cloud vendor having one leg on that specific trusted network vlan is prohibited.

Connecting the ATA on our main hosted PBX platform supporting T.38 was tested OK today.
Just like many others customers we have which are mostly using Audiocodes MP gateways.

 

[cobaltit]

So your voice should be on it's on VLAN first of all. And if they are really that paranoid then make a VLAN just for the ATA and then VPN that back to the cloud vendor. Many ways to handle it securely if one is so inclined.