ASA SunRPC problems with IP phones.

Unanswered Question
May 3rd, 2007

We have a client using an IWATSU phone systems with IP cards int it. The clients config is like this;

(Remote Site)

Phone Switch


Ethernet Switch


Cisco 2811 (VPN Tunnel)




Cisco 2821


Cisco ASA 5540 (VPN Tunnel), (NO IDS inspection on VPN Tunnel)




Primary Phone Switch

Our communication path from one phone switch to the other is clean. Clients in the same vlan as the remote phone switch can ping the Primary phone switch and vise versa with the Primary to the remote. We were having trouble getting the phone switches to see each other and sync up. The vendor provided port 7000 destination as the only ports that needed to be open. When this failed to work we opened IP any between the Phone switches and still had no success. What we did see were a large number of retransmits in our packet captures along with resets which appeared to be coming form the Primary (in reality it was our ASA). To troubleshoot this problem we started looking for enabled inspect.policies (protocol fixups) that were enabled. By process of elimination we turned off SunRPC and bang the two Phone switches sync'd and started passing traffic.

Postmortem of this appears to show that Source port: 7000 and Destination port: 1024 on one switch and Source port: 1024 and Destination port: 7000 from the other switch always.

So now to my question. Why would my SunRPC inspect policy break this type of traffic? Also I find it a bit odd that the vendor is hard setting the Source port as the exact opposite of the Destination port. Any ideas and or thoughts would be greatly appreciated.



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
mhellman Thu, 05/03/2007 - 09:33

using a source port of 1024 is pretty natural, it's the first available ephemeral port. If the switches make connections to each other on tcp port 7000, then what you're seeing makes sense.

I don't know jack about IWATSU phone switches, but a cursory google suggests that they use RPC. So, the ASA inpecting and then dropping those connections is not necessarily unusual. If you don't know what the actual RPC inspection on the ASA does, I would recommend turning it off for now until you have time to understand it.

cratejockey Thu, 05/03/2007 - 10:04

Maybe I am missing something. But when I have devices communicating on TCP 7000 shouldn't that always be my destination port? Instead the one host always sends 1024 as the Destination.



mhellman Thu, 05/03/2007 - 10:24

from the perspective of the server, packets being returned to the client will have a source port of 7000 and a destination port of 1024. I'm just guessing that this is what you're seeing.


This Discussion