Remote J179's over P2P VPN "Aquiring Service" 1

[dsm600rr]

Hello all,

I have a remote J179 phone at a clients shop that is connected via a P2P VPN using Watchguard Firewalls

The phones will update their firmware and load the company logo on the phones screen however when I go to log in I get "Verifying Credentials" and then "Acquiring Service"

thoughts?

ACSS

 

[critchey]

So that 46xxsettings.txt is pointing to 172.30.20.1 as the SIP server which makes sense. If you can get a 46xxsettings.txt from the LAN interface and see if it is properly pointing to the other interface.

Also I see now on the network topology you are using static port block. I use to use this as well but it seems like starting with R11 it just doesn't seem to work right. I have started using unknown instead of static port block with more success on R11. Could try that as well. Could also try running through a STUN server and let it set the firewall type.

The truth is just an excuse for lack of imagination.

 

[dsm600rr]

critchey: Is there a way to get the 192.168.1.200/46xxsettings.txt without physically having a PC on that VLAN?

Perhaps I can get someone locally to do a TeamViewer with me

ACSS

 

[critchey]

If the subnets are routed together then you could see it from the side you are connected from but if not I don't think so. Ya I would see if you can get into someone's computer remotely it should only take a minute or two.

The truth is just an excuse for lack of imagination.

 

[dsm600rr]

critchey: I have been using Static Port Block on R11 systems for my SIP trunks with no issues. What issues have you experienced?

I contacted their firewall guy to see if he could watch a trace on his end as the phone reboots. He’s not my favorite to deal with. Below is his response:

“ I can, but it likely would not be until some time next week. I am not sure if I will see anything helpful as the VPN is already set to allow any traffic on any port to go to any ip on any port at both ends. If the firewall blocks something, it adds it to the log. So far in the history of the firewalls there, there have been zero entries in the log for blocked traffic on the VPN.

I hate to keep saying that, but I feel like I am spinning my wheels looking for an issue on the firewall that just isn’t there”

ACSS

 

[critchey]

That is typical IT response. They never think it is in their firewall or their network so just keep hammering him till he does his job. Every IT guy ever says its not them blocking it... fine make him prove it. You need to see logs of the information passing through the firewall not just what is blocked. I have seen in the past It guys say its not being blocked its not in the logs and come to find out they had it routed in such a way that it wasn't technically blocked but it also wasn't going anywhere.

He should see the phone making connections on multiple ports. Do not tell him what ports ask him to tell you what ports. This is how I treat all SIP providers and IT guys I request them to tell me what they see not what I am looking for otherwise they will just say yup I see that...

The truth is just an excuse for lack of imagination.

 

[dsm600rr]

Oh I know, it’s never their issue. The problem is I don’t know enough about that side of things to tell him what to look for.

Are you able to tell me what ports he should see the phone attempting to connect to?

I am running out of ideas on my end to try. If the log shows no attempted registration, is there possibly anything on my end that could cause the phone to not attempt to register?

ACSS

 

[critchey]

The only thing I can see causing the phone not to attempt to register, outside of port/networking, would be SIP registrar disabled(this might still kick some kind of error though) or the settings on the phone telling it to register to the wrong interface that is not routable.

The way the phone is acting sure seems like a routing issue one way or another.

The truth is just an excuse for lack of imagination.

 

[dsm600rr]

I know I can take the phone over to the Main Location, throw it on the data VLAN, update it’s HTTP server to 192.168.1.200 and it logs right in

ACSS

 

[critchey]

I have been using Static Port Block on R11 systems for my SIP trunks with no issues. What issues have you experienced?

Typically we got no audio path with static port block and switching to unknown with no other changes worked. Could try running through a STUN server just to make sure though.

The truth is just an excuse for lack of imagination.

 

[dsm600rr]

I have never done anything with STUN

ACSS

 

[critchey]

I know I can take the phone over to the Main Location, throw it on the data VLAN, update it’s HTTP server to 192.168.1.200 and it logs right in

That is what leads me to believe its a routing issue. Onsite phone connects right away but over VPN it never even attempts to connect. Something, most likely routing, is causing the phone's registration attempt never reach the phone system. There are a few things in IPO that could cause that (network topology and IP route) otherwise it simply has to be related to the firewalls.

I think this was talked about earlier but did you find out if the firewall has SIP_ALG (or transformations or whatever they want to call it) was enabled? That will typically kill IPO IP phones connection. If you have not asked your firewall guy I would state it as "Is SIP_ALG/Transformations enabled or disabled?". Don't let him know which way you want it to be.

The truth is just an excuse for lack of imagination.

 

[critchey]

STUN server is pretty straight forward. You enter in a STUN server IP, check the run STUN at startup, and reboot the system. When the system boots it will send a packet to the STUN server which will return to the IPO and then tell it what the firewall type should be set to. I think 146.101.248.221 still works but it has been a while since I used it.

The truth is just an excuse for lack of imagination.

 

[dsm600rr]

Well that sounds pretty easy. Appreciate it. Are the servers just out there on the Internet? Nothing needed internally?

Side note I just sent the client an email to navigate to 192.168.1.200/46xxsettings.txt and to copy the text to me. Once I receive I will post.

ACSS

 

[dsm600rr]

I will run STUN after hours and see what that returns back.

Only IP route I have is 192.168.1.1 and I know all is good there as they use my SIP trunk. What I don’t know is when the IPO sees the phone come in at 192.168.2.39 is it routing it properly to 192.168.1.200

I can see 192.168.2.39 in my trace so I would assume so

After you run STUN do you uncheck the box and remove the STUN server IP? Before I run STUN should I set it to something aside from the Static Port Block it is currently at or will it change it if need be?
ACSS

 

[critchey]

Ya STUN servers are just sitting out there waiting for a packet that they will send back. Based on that traversal it automatically sets the firewall type.

The truth is just an excuse for lack of imagination.

 

[dsm600rr]

When I am back to the office I will check the email string for SIP_ALG/Transformations. I believe he said it was off.

ACSS

 

[dsm600rr]

Attached is the 46xxsettings.txt from:

192.168.1.200/46xxsettings.txt

ACSS

 

[critchey]

That looks good to me it is pointing to the correct interface. Provided the phone gets the files from that interface it should point at it correctly.

Other then the STUN server I think you are back to thinking there is an issue with the firewall/VPN.

The truth is just an excuse for lack of imagination.

 

[dsm600rr]

critchey: Thank you for reviewing it. Is there a way I can confirm the STUN Server 146.101.248.221 is working before I do the reboot?

ACSS

 

[derfloh]

You can watch STUN in Monitor if you enable it as filter in the SIP tab.

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