H323 TLS Errors (local only) 3

[EricMcS]

I have an IP Office V2 500 11.x. We are running a mix of end-points: SIP Apps, 54XX, 96XX, J169s. Except for the SIP, the rest are on-site and also remote using IPSec VPN.

All are working except the on-site J169s. We are running them in H.323 mode. The VPN versions are working perfectly, they VPN, download config from the PBX and connect to the call server. The local versions boot, download config from PBX, then fail at login with "Authentication Failure". On the back-end I am getting:

11:12:53 2216231960mS H323Evt: Recv GRQ from 10.1.1.1:49302
11:12:53 2216231961mS H323Evt: e_H225_AliasAddress_dialedDigits alias
11:12:53 2216231961mS H323Evt: found number <4000>
11:12:53 2216231978mS H323Evt: H323PhoneUser Operational: Src=10.1.1.1:48140 Dst=10.1.0.1:1300
11:12:54 2216232012mS PRN: TLS:Alert Src=10.1.0.1:1300 Dst=10.1.1.1:48140 Code=48 Level=Fatal
11:12:54 2216232012mS ERR: TLS:Fatal Error on connection Src=10.1.0.1:1300 Dst=10.1.1.1:48140

Media Security is set to disabled on the PBX and as far as I can tell, the only thing that should be using a certificate is the SIP phones running over TLS. I can't see why the J169 local won't work but the 5610s work and the J169s running over VPN work.

To troubleshoot, I also tried a brand new phone out of the box, reverted to the H323FW and got the same issue; but I brought it home, changed the config to connect to VPN first and it worked.

 

[Okkie26]

Why do you run them on H323 in the first place?

 

[jamie77]

J1XX in H.323 is only for the later versions of 10.1. R11+ you should have these in SIP mode.

Jamie Green

[bold]A[/bold]vaya [bold]R[/bold]egistered [bold]S[/bold]pecialist [bold]E[/bold]ngineer

 

[EricMcS]

Yes, the phones should run in SIP mode. Now, does anyone know why in H323 mode they are happy when running over VPN with restrictive firewall rules, but when they are local on the same subnet they don't work?

 

[jamie77]

Nobody will know, as they should be in SIP mode as it says in the tech bulletins:

Can't expect something to be fixed when it isn't installed correctly! Sorry to be blunt!

Jamie Green

[bold]A[/bold]vaya [bold]R[/bold]egistered [bold]S[/bold]pecialist [bold]E[/bold]ngineer

 

[EricMcS]

I can accept this; it's hard to expect someone else to have encountered the same issue I am having when then vendor no longer supports or recommends the method. Honestly I want to switch to SIP and have taken multiple runs at it, but the hard phones have not worked yet (app on iOS and Android took all of 15 minutes to get firewall rules in line.)

The part about this that makes my brain itch is simply that they work away from the office (where presumably they shouldn't) but not next to the PBX. This is like saying the car won't start when it's warm in the garage, you have to push it into the driveway in a snowstorm for it start - just seems counter-intuitive.

I wish it hadn't worked either way, then I just would have solved the SIP issue out of the gate. I had kept them all the same so that the deployment method regardless of device is very similar from phone to phone. If you can setup a 9608, you use the same config on the J169...

 

[EricMcS]

Switched to SIP and getting same TLS Code=48 error.

14:02:44 2399238774mS Sip: TCP packet known set owner
14:02:44 2399238775mS Sip: (f18e76f8) Process SIP response dialog f18e76f8, method NOTIFY, CodeNum 200 in state SIPDialog::INITIAL(0)
14:02:44 2399238775mS Sip: (f18e76f8) ProcessInboundSIPResponse CheckUnIntTransactionConditionForMatch for saved (0 == 2) , ignoring saved CSeq0 == 0) - result:0
14:02:44 2399238775mS Sip: (f18e76f8) UpdateSIPCallState SIPDialog::INITIAL(0) -> SIPDialog::FINAL(28)
14:02:45 2399239011mS Sip: SipTCPUser 5146 incoming f18ab784 created local 10.1.0.1:5061 remote 67.1.5.2:1987 list size 3
14:02:45 2399239012mS Sip: SIPPhoneReceiver 70682 (f18db328) tcp created, srcaddress 67.1.5.2, list size 5

14:02:45 2399239142mS PRN: TLS:Alert Src=10.1.0.1:5061 Dst=67.1.5.2:1987 Code=48 Level=Fatal

14:02:45 2399239158mS Sip: SIPPhoneReceiver 70682 disconnectIndication from tcp, srcaddress 67.1.5.2
14:02:45 2399239158mS Sip: SipTCPUser 5146 incoming f18ab784 destroyed list size 2
14:02:45 2399239159mS Sip: SIPPhoneReceiver 70682 (f18db328) destroyed, list size 4


New issue to Google; maybe this one has a more readily identifiable solution.

 

[critchey]

Since you are using TLS I am assuming you have a valid certificate? If so how is the certificate setup? Do you have a SIP domain and SIP FQDN setup? Is the FQDN resolvable to the public IP externally but the local IP internally?

The truth is just an excuse for lack of imagination.

 

[EricMcS]

The common theme for all my issues seems to be TLS; but I can't find anything wrong with the cert.

It is a publicly generated UCC certificate from Sectigo, all root and intermeditate certs are posted to PBX Security app and are available. The SANs include the parent domain as well as the FQDN to the PBX. The DNS resolved properly relative to internal/external. Everything I have read has shown new versions of iOS and Android are usually much more stringent than the J169 for cert validate yet the Avaya Workplace is working on both with TLS and no issues.

 

[EricMcS]

Everyone insisted I switch from H323 (that at least it was working for remote workers,) to SIP. Now I have a SIP phone that doesn't work Local or Remote, but has the exact same issue as H323.

Now that I switched from H323, anyone able to help with the exact same issue? "Sorry to be blunt"

I expect it's a problem with the cert, but I don't see anything wrong with it, and followed multiple guides to ensure it was setup correctly - attached is the results from SSL Checker... Hopefully someone else can spot what I can't.

 

[critchey]

If you turn off TLS does it connect? I obviously wouldn't keep it that way but it would be a good test just to see if it works or not.

Also what specific version of R11 are you running? R11.1 is just garbage imo and R11.0 only has a few versions I think are decent (I have found R11.0.4.1 to be the most stable).

The truth is just an excuse for lack of imagination.

 

[EricMcS]

I honestly don't remember anymore; I will try again tonight to see. As for version, we are running R11.0.4.4.

 

[EricMcS]

I can confirm that the phone works in SIP using TCP (5060.) Once firewall rule is removed and phone is set to use TLS 5061, goes back to "Acquiring Service" after logging in with the TLS Fatal error in the Avaya logs. I've check firewall and there aren't any packets being blocked from my IP.

 

[EricMcS]

Seems very similar to

https://www.tek-tips.com/viewthread.cfm?qid=1791638.

But it looks like they settled on the cert not being a correct UCC and went with using the phones over TCP.

 

[derfloh]

You have to create a WebRootCA.pem containing the root and intermediate certificate of Sectigo and upload it to the IPO. Then reset the phone and let it download 46xxsettings.txt and WebRootCA.pem.

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

 

[EricMcS]

I had not created a WebRootCA.pem file since I thought the system would do that when I uploaded the certs through the interface (all certs are uploads and offer chain is enabled.)

I've created the PEM, tested that the chain is valid an uploaded as WebRootCA.pem and have uploaded to IPO. I'm working remotely, so I am trying to set the phone to login as TCP first (since TLS won't currently download the 46xxsettings.txt file because of cert problems.) Not sure if it will download the PEM if it's TCP mode. Might be a case where I have to take the phone to the office to provision it.

 

[EricMcS]

No go. I'm in the office next Wednesday, I will try a device in the office to see if it' works from local... Any other thoughts until then?

 

[derfloh]

Use a local http server to provide 46xxsettings.txt and WebRootCA.pem. Enter the fine server address manually.

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

 

[jamie77]

I've done loads of TLS setups on J1xx phones and have never had to upload and but the .pfx through Manager or Web Manager Security.

J1xx install using TLS:
Cert with FQDN and Domain in the SANs. Uploaded to system as a .pfx or .p12 (root and inter certs will be added automatically, if needed)
DNS server in use has an A record for the system added.
Browse to http://[FQDN to check DNS and cert installation.
If using DHCP then add TLSSRVR=[FQDN] to 242. If no 242 option in DHCP, then manually program https server as FQDN into the handset, and let everythign else be picked up from DHCP.
No DHCP: set IP, DNS, etc. in the phone as normal.
Enable TLS on system and add FQDN/SIP Domain.
Add and IP routes to the system if phones are on a different subnet.
Autogenerated settings files in use.

Assuming you have uploaded the files as needed to the SD, then all works as it should. From the above, your cert looks good and DNS from internet OK at least.

One the phoen is up, make sure the SIP server address has been populated.

We've installed 1000's of J1XX and never had an issue if the above is done.

For a SIP phone to work remote, you will either NAT traversal setup (which I wouldn't suggest with a 500), an SBC or a site to site VPN. These phones won't do VPN onboard like the H.323 do.

I do wonder if the system thinks these are 3rd party phones and not Avaya J1xx for some reason. Maybe something in the conversion went screwy. I've never converted one of these phones. Enable everything in monitor while you connect one and see if anything stands out. Desparate time mean desparate tracing!!!!

Jamie Green

[bold]A[/bold]vaya [bold]R[/bold]egistered [bold]S[/bold]pecialist [bold]E[/bold]ngineer

 

[TouchToneTommy]

Silly question, when you switched your on site phone from H.323 to SIP, did you delete the H.323 extension, create a SIP Extension, and check SIP Registrar on the LAN port serving them?