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

 

[dsm600rr]

All,

So I entered in the info as such:

I watched in Monitor per derfloh:

STUN - Type=BINDING-REQUEST(0001) plen=0 cookie=00000119 transactionid=0000730a0000284800001a7d
62636mS PRN: +++ START OF ALARM LOG DUMP +++
62636mS PRN: ALARM: 14/11/2019 08:52:29 IP 500 V2 11.0.4.1.0 build 11 <BROWNOUT > CRIT RAISED addr=00000000 d=4 pc=f000b6c8 f000b6c0 f000c178 f0255e44 f0255e18 ffffffff
62636mS PRN: ALARM: 10/03/2020 13:46:48 IP 500 V2 11.0.4.1.0 build 11 <OSBuffer::Alloc Out Of Buffers 1652 > CRIT RAISED addr=f02c8330 d=5 pc=f025bd8c f07080d8 f070938c f06ea158 f06ea1c4 f026165c
62637mS PRN: ALARM: 20/04/2020 10:28:46 IP 500 V2 11.0.4.1.0 build 11 <BROWNOUT > CRIT RAISED addr=00000000 d=4 pc=f000b6c8 f000b6c0 f000c178 f0255e44 f0255e18 ffffffff
62637mS PRN: +++ END OF ALARM LOG DUMP +++
63637mS PRN: +++ START OF TCP MONITOR CLIENT DUMP +++
63637mS PRN: CLIENT: IPAddress= TCPPort=0 LastReceived=59646(3991) LastSent=63637(0) LastOldUpdate=62964(673) SentPackets=1 MissedPackets=0 OldSentPackets=12 OldMissedPackets=0
63637mS PRN: ++++ END OF TCP MONITOR CLIENT DUMP ++++
68834mS StunTx:: v=STUNUdpClient TX: (this=0xf5701cc4) [192.168.1.200:5060]=>[146.101.248.221:3478] ToS:136
p1=0
0000 00 01 00 00 00 00 01 19 00 00 73 0a 00 00 28 48 ..........s...(H
0010 00 00 1a 7d ...}
STUN - Type=BINDING-REQUEST(0001) plen=0 cookie=00000119 transactionid=0000730a0000284800001a7d
84834mS StunTx:: v=STUNUdpClient TX: (this=0xf5701cc4) [192.168.1.200:5060]=>[146.101.248.221:3478] ToS:136
p1=0
0000 00 01 00 00 00 00 01 19 00 00 73 0a 00 00 28 48 ..........s...(H
0010 00 00 1a 7d ...}
STUN - Type=BINDING-REQUEST(0001) plen=0 cookie=00000119 transactionid=0000730a0000284800001a7d

********** SysMonitor v11.0.4.4.0 build 6 [connected to 192.168.1.200 ()] **********
100834mS StunTx:: v=STUNUdpClient TX: (this=0xf5701cc4) [192.168.1.200:5060]=>[146.101.248.221:3478] ToS:136
p1=0
0000 00 01 00 00 00 00 01 19 00 00 73 0a 00 00 28 48 ..........s...(H
0010 00 00 1a 7d ...}
STUN - Type=BINDING-REQUEST(0001) plen=0 cookie=00000119 transactionid=0000730a0000284800001a7d
116834mS StunTx:: v=STUNUdpClient TX: (this=0xf5701cc4) [192.168.1.200:5060]=>[146.101.248.221:3478] ToS:136
p1=0
0000 00 01 00 00 00 00 01 19 00 00 73 0a 00 00 28 48 ..........s...(H
0010 00 00 1a 7d ...}
STUN - Type=BINDING-REQUEST(0001) plen=0 cookie=00000119 transactionid=0000730a0000284800001a7d
132834mS StunTx:: v=STUNUdpClient TX: (this=0xf5701cc4) [192.168.1.200:5060]=>[146.101.248.221:3478] ToS:136
p1=0
0000 00 01 00 00 00 00 01 19 00 00 73 0a 00 00 28 48 ..........s...(H
0010 00 00 1a 7d ...}
STUN - Type=BINDING-REQUEST(0001) plen=0 cookie=00000119 transactionid=0000730a0000284800001a7d


When I logged back into the IPO, everything will still the same - however it did remove my Public IP Address



ACSS

 

[critchey]

That is odd I have never seen a STUN server return the firewall type as unknown it is usually one of the more "complex" types. You could try another STUN server and see if it helps. I know google has one but I don't have the info for it.

I did notice that you do not have the ports specified in your network topology. I would set both UDP and TCP to port 5060 (unless you are using different ports of course).

The truth is just an excuse for lack of imagination.

 

[dsm600rr]

critchey: I set it as "Unknown" and did the reboot. It stayed at "Unknown" however removed my Public IP. So I set it to "Static Port Block" and tried again. It stayed at "Static Port Block".

I have updated the ports - thank you.

ACSS

 

[dsm600rr]

Using google seemed to work:

After the STUN Server selects the firewall/NAT Type, do you remove the STUN Server Address, and Uncheck "Run STUN on Startup"?

ACSS

 

[critchey]

You don't have to you can keep it in there. I don't think contacting a STUN server is real resource intensive and it only does it when it first boots (as far as I know).

Is it still doing the same thing after adding the ports and getting the Full Cone NAT on firewall type?

The truth is just an excuse for lack of imagination.

 

[dsm600rr]

critchey: This is actually on my Demo System. I wanted to try before going live on my customer.

I also have a p2P VPN Setup from my office to my home with the same Watchguard Firewalls. That way or internal Firewall Guy can Test with me rather than the dude they have who is a pain.

One thing I found interesting is I gave the IPO an Open Public IP Address we have, and after running STUN it updated the IP Address to that of the Firewall. I will leave it like that.

I will let you know the results.

ACSS

 

[dsm600rr]

Just as a test, I ran the STUN Server on our in-house PBX, and it also selected Full Cone NAT. My SIP Trunk however did not like this - On test calls there would be a 3-5 second delay and then the call would connect. Put it back to "Static Port Block" and the SIP Trunk was working back to normal. Thoughts?

ACSS

 

[critchey]

Personally I typically try unknown or static port block, and if it doesn't work, try STUN server.

I would try the VPN'ed phone with static port block first and see if it works. If you have issues try unknown, and then finally the STUN server, and see if you can get it registered correctly.

The truth is just an excuse for lack of imagination.

 

[dsm600rr]

Should something be set for the "Binding Refresh Time"?

ACSS

 

[critchey]

Binding refresh is for SIP trunks so it shouldn't matter here. It tells the system to send an OPTIONS to the SIP provider.

The truth is just an excuse for lack of imagination.

 

[dsm600rr]

The system does have a SIP Trunk, If they are working, guess I do not need to adjust the value from 0

ACSS