7
« on: June 13, 2017, 09:24:25 PM »
Still convinced the ISP is the issue. The issue seems to be packets being modified (sounds slightly crazy) enough that the phones aren't functioning properly. I've captured traffic at a few different points in the path between server and phone and here is what I have:
The following packet samples from 4 different points between phone server and remote phone... (.46 is my public where the phone is, .157 is the public of the server, .106 is the phone private)
From the phone server:
19 0.396725000 10.0.0.210 xx.xx.xx.46 TCP 60 6801→6920 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
From our internal firewall:
5275 2.655164 xx.xx.xx.157 xx.xx.xx.46 TCP 54 6801→6944 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
From the Spirit Adtran:
14 35.041900634 xx.xx.xx.157 xx.xx.xx.46 TCP 64 6801→6988 [RST] Seq=1 Win=0 Len=0
From the phone in my home office:
107 70.391494000 xx.xx.xx.157 192.168.0.106 TCP 60 6801→6924 [RST] Seq=1 Win=0 Len=0
For comparison, here is what the traffic looks like at the phone when the phone is connected to another Mitel server at a different location using a different ISP:
132 59.471738000 xx.xx.xx.243 192.168.0.106 TCP 60 6801→6996 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
So the best I can tell - when 6801 isn't open the phone tries 6802, when 6802 isn't open, it goes to 6800 where the connection works. This is how these phones behave on the LAN too.
So the issue is now with the packets ... being sent from the server with BOTH THE ACK and RST flags set all the way until they leave my firewall. Looks like after they leave the ISP adtran they lose the ACK flag and only the RST flag is sent and this is all the reaches the phone. I don't know, but I'm assuming that the phone is looking for an ACK, RST before attempting the next port.
This is my theory and I'm having a great time trying to convince the ISP.
Show Posts