About EddieBrown

Hello Folks,   We are currently leveraging Cisco's IP Communicator platform to allow VOIP to our user via softphone. The scenario is as follows:   1. User logs into a ASA VPN gateway using Cisco Any connect, the ASA is located in an AWS environment. 2. This ASA is virtually connected to a PA100 vm in the same AWS instance. 3. The Palo Alto firewall is netbonded back to our MPLS network to achieve full mesh connectivity.  4. On the Palo Alto we have three zones, trust (WAN/MPLS), VPN (ASA VPN clients), untrust (internet). 5. On the Palo Alto we have two NAT rules one to translate all traffic from the VPN zone to the trust zone and one to translate all traffic from the VPN zone to the untrust zone (we have been told this is a necessary step to achieve connectivty via our AWS provider) There are security policies in place to allow communication to all zones, only restricting the internet usage at this time. Everything seems to work flawlessly clients can connect to the ASA vpn gateway and traverse the NATs in either direction to get to the internal resources and internet. The only thing that doesn't work is the soft phones, the intermittently will not be able to register with the call managers. Some times it works and sometimes it doesn't. The IP phones are setup to use UDP as TCP hasn't worked whatsoever. When I capture packets I can plainly see certain packets being dropped. It's always in direction of call manager (trust) to  VPN client, sometimes its to the NAT IP address and sometimes its directly to the VPN client IP address.   I have checked the monitoring tabs for the traffic being dropped and it's non existent. It's only shows up during a packet capture or when I look at sessions through the CLI. The sessions will show up as discarded, clearing them out does nothing to help the IP phone from connecting. I thought maybe my Intrazone policies weren't doing what they were supposed to so I put in a manual trust-to-trust and VPN-to-VPN policy to simply experience the same situation. I've tried disabling the SIP ALG in the application settings and this doesn't help at all either. Something I did notice is the when I am in the session lookup via CLI, the DISCARDED sessions are always when the call manager is attempting to connect to the the NAT IP  address and the NAT IP address is being referenced on the trust zone. Within my monitoring tab I can see the NAT IP sometimes in the VPN zone and sometimes in the trust zone. I have been on hold with TAC for 2hr 15mins and just feel like they will want to do all the same troublehooting steps I have already taken when they finally pickup.   Is there any other way for me to figure out why a packet is being dropped or discarded? ... View more