46xxsettings.txt SBC problem 2

[m.kozlowski]

Hey,
maybe some of you guys got some idea.
I got the Problem that in our Company Network you are able to open

https://server.com/46xxsettings.txt

but from outside our Company Network you are only would get a blank web site.

http://WWW ->

Firewall -> SBC -> PBX

 

[John563]

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)

 

[jinxs]

Just an FYI, we had to use the Application Relay or the presence server for the IX Workplace app would not work.

AJ-

 

[derfloh]

I agree with jinxs because I had in one ASBCE release the issue that the reverse Proxy service wouldn't accept the configuration created by the web interface.

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

 

[John563]

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.

 

[John563]

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.

 

[jamie77]

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

 

[John563]

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.

 

[G van Hamburg]

I am working with Avaya Support on this. I also have the parsing error and opened an SR

Freelance Certified Avaya Aura Engineer

 

[jamie77]

We have now done the same!!!



Jamie Green

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

 

[Childebrand]

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.

 

[jamie77]

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

 

[G van Hamburg]

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

 

[IndianaJonas]

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

I will post updates here.

 

[G van Hamburg]

I found a workaround on the SBCE that takes away the parsing error.

https://support.avaya.com/ext/index?page=content&id=SOLN314061

So if you change /usr/local/nginx/conf/proxy.conf and opt-out the X-Real-IP: #proxy_set_header X-Real-IP $remote_addr; then the issue is ‘solved'.

Freelance Certified Avaya Aura Engineer

 

[derfloh]

Thanks for sharing!

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

 

[G van Hamburg]

You are welcome. The issue will be solved in a later SBCE release.

Freelance Certified Avaya Aura Engineer