Cisco ASA 5505 Reset-I Problem with TCP State Bypass

[i2techsupport]

Hello,

I have a Cisco ASA 5505 that functions as my primary firewall and a Mitel 5000 controller behind it. I have two external phone users that have been connecting through the firewall with no issues for six months until about two weeks ago. I am now seeing the following log entry on the phone trying to connect to the Mitel Controller.

6

May 16 2014

14:52:52

302014

72.135.115.37

6915

192.168.20.2

6801

Teardown TCP connection 1203584 for outside:72.135.115.37/6915 to inside:192.168.20.2/6801 duration 0:00:00 bytes 0 TCP Reset-I

My phones are designed to work with the Mitel 5000 and Mitel 3300 phone controllers. The 5000 will only use port 6800 for call control, while the 3300 will use 6801 (Secured Minet), 6802 (Minet SSH), and if those fail, port 6800 (Minet Unsecured). When the phones initiate a connection, they try 6801 first. If 6801 is unavailable, the phone controller adds the RST flag to the ACK packet. When the phone sees the RST flag, it is supposed to reset and use the next port (6802). The same process happens again for port 6802, then the phone knows to try 6800. The problem is that the ASA sees the RST flag now and terminates the connection at the firewall. Therefore, the phones never see the RST flag, and continue to try the connection with port 6801.

I have tried to use the TCP State Bypass feature to correct the situation, but the log shows that the connection is still being terminated immediately by the firewall. I am a novice when it comes to configuring the ASA. Any help would be greatly appreciated, as the company that I bought the phone system from is out of troubleshooting options. I do not think that I have made any changes to the firewall around this time. I have packet captures and logs from my ASA and I have wireshark data on the inside of my network. I need to figure out how to configure the ASA so that it ignores the RST flag and sends the packet back to the source.

Any help would be greatly appreciated!

[danman4884]

Did you get a solution to this?  We literally just started having the EXACT same problem. Nothing changed on our end. Out of the blue our remote user phones went down and we're having this exact same log messages.

[Rishabh Seth]

Hi,

The syslog shows that ASA observed a Reset from INSIDE ( higher security interface) side.

Now this can happen due to many reasons,but you can try investigating devices on the internal side and search if there is some device that might block the connection or if the end host itself is resetting connection due to some application related issue.

Hope this help !!!!

R.Seth

[danman4884]

We've been investigating on both sides of the connection. And based on OPs description it could be that our ISP isn't sending the RST, ACK flag back out to phone. With my packet capture I'm seeing our outside IP send a packet back to the external phones IP with the RST, ACK flag. So it would lead me to believe that it's not getting to the phone but it is getting through the ASA.

We have Telepacific as our ISP and I've run into older devices (adtran) that they deploy not having the most current firmware. I had Telepacific pull the uptime logs and working backwards, the outside phones went out around the last time this device had zero uptime. So around Monday night the device rebooted and we lost phones. I'm confirming this with Telepacific now. I believe the RST, ACK entry is correct, it's just not getting to the remote phone in order for it to cycle to port 6800 and connect. So my hypothesis is that our ISPs Adtran is dropping the packet. Will report back once I talk to a second level tech.

We're going to test a cheap consumer router plugged into the Telepacific connection with the proper ports forwarded to see if phone will come up. But I'm guessing that it won't. Will report back.

[Rishabh Seth]

Sure, let us know your findings.

Thanks,

R.Seth

[danman4884]

I was correct! Telepacific's firewall somehow was blocking the port 6801 traffic. It took some doing to get a Telepacific Tier 2 tech on the phone on a Sunday, but a supervisor called me back and while they did say it was on the newest firmware they were showing the traffic being dropped in their log file.

So there it is. Whenever you don't think it could possibly be your ISPs equipment doing filtering...it is indeed your ISPs firewall on their router dropping the traffic as suspicious. The second he disabled the firewall, the phone switched to port 6802 then 6800 just as OP stated.

[Rishabh Seth]

Nice!!!