I have a very weird problem, and I've racked my brain trying to figure it out.
I have a 7940 on the inside of a PIX 501, connected via a Site-to-site VPN tunnel to our Cisco 2821. The phone is able to boot and receive its lines, I get dial tone, etc.
The problem is this: I can make calls to other IP phones on our LAN (on the inside of the 2821) and can have a perfect two-way conversation. I cannot, however, make calls to the Unity express voicemail or to external numbers. When I do that, the call setup proceeds perfectly, but I do not hear anything. The called party, however, can hear me just fine. They also can hear DTMF as I was able to delete a voicemail by memory of which keys to press and when.
This only happens on calls to the unity express voicemail or any number outside of our CME system.
The PIX 501 is running sw version 6.3.1(5)
The 2821 is runnign 12.4(6)T
The two are connected via a site-to-site IPSEC tunnel.
Does anyone know what could be causing this?
Make sure that your pix 501 permit the range of UDP ports for your RTP.I have same problem and found out that some UDP ports was not allowed on my firewall.
Thanks for the tip! I had figured that it was something that the PIX was not allowing, but I had also thought that traffic that came in over the IPSec tunnel was exempt from access rules.
Is there anything in this attached config that looks wrong? It's my first PIX device, so I am a bit unfamiliar.
I had another thought:
I wonder if the problem isn't in the PIX at all, I wonder it if is in my 2821. Here is the scenario:
-- Calls that work:
- 7940 behind PIX -> Any phone on Internal LAN:
Packets leave ethernet0 on PIX, enter Fa0/0/3 on the 2821, leave out Gi0/0 on the 2821 out to the core LAN switch and beyond, and the reverse happens for return traffic.
This works fine.
-- Calls that do not work:
- 7940 behind PIX -> Unity Express VM
Packets leave ethernet0 on PIX, enter Fa0/0/3 on 2821, then instead of going out to the LAN, they go to ServiceEngine1/0 in the 2821. Return traffic does not make it back.
- 7940 behind PIX -> Any external number
Packets leave ethernet0 on PIX, enter Fa0/0/3 on 2821, then instead of going out to the LAN, they go to Serial 0/3/0:23. Return traffic does not make it back.
I am wondering, is the cause of the one-way traffic somehow related to the fact that the calls that do not work are terminating at interfaces on the router, and the calls that do work are terminating beyond the router on the local LAN?
Calls that do work: Come in Fa0/0/3 and out Gi0/0 to the LAN
Calls that do not work: Come in Fa0/0/3 and out either Serial0/3/0:23 to the PRI trunk to PSTN, or ServiceEngine1/0 to Unity express.
I have attached the config of my 2821 (our Internet router, CME, Cisco IOS Firewall, and VPN endpoint). I have removed all the sensitive bits and a bunch of ACLs to save space.
I have experienced a similar problem using a phone over a VPN client. The problem with one way comms was due to the voice network not being defined on either the main firewall policy or the firewall policy of the desktop VPN client. So it wasn't routing the data back to the correct network. If your traversing voice traffic through a firewall check your voice networks and the fw logs. But be aware if the clean up rule is dropping the packets cus its not define, you probly aren't logging the clean up rule so you won't see it.
I have experieced this before. The problem was the IOS on the router.
Was running router 3825 15.0(1)M2, had to roll back to 12.4(24)T2.
There was a bug in15.0(1)M2 that Cisco does not have a fix for.
Upgrade or downgrade the IOS on the router, if not could be the firewall IOS.
Would you happen to know what bug that was? I have a need to run the 15.0 code due to some DMVPN enhancements and need to run CME at the same time. I might be hitting this bug since I occasionally experience a one-way audio scenario on one of my FXO (standard analog POTS) ports.
I wonder if 15.0(1)M3 has fixed this yet?
Cisco has not been able to determine a resolution for the bug. we never upgraded, still on 124-24.T2. Not sure if 15.0(1)M3 has the fix.