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 strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

46xxsettings.txt SBC problem 2

Status
Not open for further replies.

m.kozlowski

Systems Engineer
Jan 21, 2021
1
DE
Hey,
maybe some of you guys got some idea.
I got the Problem that in our Company Network you are able to open but from outside our Company Network you are only would get a blank web site.

Firewall -> SBC -> PBX
 
Assuming its an Avaya SBC, you need to go into DMZ Services > Relay and create either an application relay or a reverse proxy. An application relay is just going to forward the entire port. A reverse proxy is generally a better option, as you can specify exactly what you pass through the SBC and you can rewrite urls for remote workers. To use HTTPS and not just HTTP like in your link, you'd need to make sure your certs on the SBC are in order.

I usually create two reverse proxies, one for 80 and one for 443.

on 80 you rewrite urls like this:
server address:x.x.x.x:80, URL: /46xxsettings.txt Replace: /46xxsettings_rw.txt (this will give a custom 46xxsettings_rw.txt to remote workers when the phone requests 46xxsettings.txt)
server address:x.x.x.x:80, URL: /user Replace: /user
server address:x.x.x.x:80, URL: /WebRootCA.pem Replace: /WebRootCA.pem
server address:x.x.x.x:80, URL: /othercerts.pem Replace: /othercerts.pem

on 443:
server address:x.x.x.x:443, URL: /46xxsettings.txt Replace: /46xxsettings_rw.txt
server address:x.x.x.x:443, URL: /user Replace: /user
server address:x.x.x.x:443, URL: /WebRootCA.pem Replace: /WebRootCA.pem
server address:x.x.x.x:443, URL: /othercerts.pem Replace: /othercerts.pem
server address:x.x.x.x:443, URL: /tpkt/mtcti Replace: /tpkt/mtcti (needed for IX Workplace)
 
Just an FYI, we had to use the Application Relay or the presence server for the IX Workplace app would not work.

AJ-
 
I've probably configured a good 5 or 6 SBCs in 2020 with IX Workplace and had presence working on all of them through a reverse proxy. We prefer to do it this way so we aren't exposing the entire 443 port, as well as the ability to rewrite URLs.

I make sure I'm forward these URL's as well as the certificates and provisioning file:
/tpkt/mtcti
/user
In your Reverse Proxy Policy, you have to change Allow Web Socket to yes.
Make sure your certificate profiles on the SBC are in order and you are offering the right certs to the IX client.
If using an FQDN, split DNS has to be setup correctly. I think this is relevant for the application relay as well.
 
Here's what this would look like. The port 80 reverse proxy setup would be the same but change the ports to 80, and there would be no TLS profiles. You could add J100Supgrade.txt for the J series phones.

Untitled_ipwsgl.png

reverse_ffiyij.png
 
Out of interest, what version are your IP Office and SBC systems.

I'm seeing an issue with the latest 8.1.2 ASBCE firmware. Looks like something has changed/is broken in the reverse proxy and the IP Office doesn't like it. I get a "parsing error" response back from the IP Office.

Setting 443 as a relay works OK.

Been duplicated on a brand new install R11.1.1/SBC 8.1.2 (OVA), R11.1.1 SE with SBCE upgraded from working at 8.1.1 to broken at 8.1.2 & also on a another system at our Disty.

Jamie Green

[bold]A[/bold]vaya [bold]R[/bold]egistered [bold]S[/bold]pecialist [bold]E[/bold]ngineer
 
This particular SBC is a portwell running 8.1.2 and IPO 11.0.4.4. It started on 7.2.2.2 and was updated to 8.1.2 to support MS Teams. It was configured for application relay when on 7.2.2.2 but I changed to reverse proxy after the update. I didn't run into any issues like you are describing, but my team lead has definitely had issues with reverse proxy on 8.1.2. I don't know the specifics of his issues. May be specific to the OVA version. I've done the reverse proxy setup on a bunch of 7.2 and 8.0 SBCs, but this was my first 8.1.2.
 
I am working with Avaya Support on this. I also have the parsing error and opened an SR

Freelance Certified Avaya Aura Engineer

 
We have now done the same!!!



Jamie Green

[bold]A[/bold]vaya [bold]R[/bold]egistered [bold]S[/bold]pecialist [bold]E[/bold]ngineer
 
Hello Just for the story. We have the same issue With SBCE 8.1.2. We opened a ticket to AVAYA. and the first reply from the tech that was a configuration problem.
 
we've just finished a session with an ASBCE engineer and he is going to take it to the IP Office team now. Nothing to be done on the SBC.

We are seeing a couple of differences in the http packets being received by the IPO on the different versions of SBC. http version goes from 1.0 to 1.1. Cookies header gets included also and the X-Real_IP header includes a https field which isn't there on older SBCs.

Given the IP Office is giving a parsing error, it will be the syntax of the http packet it doesn't like, so one of these (probably the X-Real I would think) is probably the cause.

I'll update if we get anything.

You can workaround this proxy issue by using application relay it seems.

Jamie Green

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

So there is a difference in how this works on different SBCE versions, the X-Real_IP header is added by the newer SBCE which the IP Office cannot parse, the workaround on the SBCE fixes the issue, but the engineer will take this to the IP Office team? Seems to me the SBCE is the issue!



Freelance Certified Avaya Aura Engineer

 
Hi,
we are facing the same issue at the moment. "Parsing Error"
Ticket is escalated to a higher tier...

I will post updates here.
 
You are welcome. The issue will be solved in a later SBCE release.

Freelance Certified Avaya Aura Engineer

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top