cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1710
Views
5
Helpful
5
Replies

ASA 5506 - NAT Problem - Need to Prove it's not the Firewall

Dean Romanelli
Level 4
Level 4

Hi All,

I have a site that has an internal VOIP subnet (192.168.9.0/24) hanging off of a Cisco ASA 5506. On that subnet, there is a local IP-PBX: 192.168.9.11.  That PBX needs to be visible publically to a SIP server in the cloud on the internet.  The WAN subnet is a /30, so I need to interface NAT that 192.168.9.11 PBX so it is seen publically when it is called from the outside on a range of ports, which are UDP 46750 - UDP 50750.  I have set this up to the best of my knowledge, but it is not working.  The initial SIP exchange completes bidirectionally, but I begin to get nothing back from SIP Server once the UDP traffic starts to flow from the PBX.  I need to prove that this is not the ASA and the SIP Server has a problem.  Below is my NAT config, and attached is my full ASA scrub.  Can anyone validate these configs as correct or spot an issue if incorrect?

Relevant NAT Configs:

object network Avaya_IP_PBX-PRI
host 192.168.9.11

object network Avaya_IP_PBX-BKP
host 192.168.9.11

object service VOIP-UDP-46750-50750-PRI
service udp destination range 46750 50750

object service VOIP-UDP-46750-50750-BKP
service udp destination range 46750 50750


nat (outside,VOIP) source static any any destination static interface Avaya_IP_PBX-PRI service VOIP-UDP-46750-50750-PRI VOIP-UDP-46750-50750-PRI
nat (backup,VOIP) source static any any destination static interface Avaya_IP_PBX-BKP service VOIP-UDP-46750-50750-BKP VOIP-UDP-46750-50750-BKP

Relevant Access Configs:

object network Avaya_IP_PBX-PRI
host 192.168.9.11
object network Avaya_IP_PBX-BKP
host 192.168.9.11
object-group service VOIP-TCP-Ports-PRI tcp
port-object eq sip
port-object eq 5061
object-group service VOIP-UDP-Ports-PRI udp
port-object eq sip
port-object eq 5061
port-object eq 50795
port-object range 46750 50750
object-group service VOIP-TCP-Ports-BKP tcp
port-object eq sip
port-object eq 5061
object-group service VOIP-UDP-Ports-BKP udp
port-object eq sip
port-object eq 5061
port-object eq 50795
port-object range 46750 50750

access-list outside_access_in extended permit tcp any object Avaya_IP_PBX-PRI object-group VOIP-TCP-Ports-PRI
access-list outside_access_in extended permit udp any object Avaya_IP_PBX-PRI object-group VOIP-UDP-Ports-PRI

access-list backup_access_in extended permit tcp any object Avaya_IP_PBX-BKP object-group VOIP-TCP-Ports-BKP
access-list backup_access_in extended permit udp any object Avaya_IP_PBX-BKP object-group VOIP-UDP-Ports-BKP

1 Accepted Solution

Accepted Solutions

Ok it looks good. this is showing all the path the packet will take and, on the firewall, we can see it's sending it to your internal PBX.
You can also confirm by running a tcpdump on ASA on on the switch where PBX is connected to. If you see trafic, the issue is your SIP provider or application layer.
If you have the real public ip of your sip provider, you can re-run the packet-tracer command by replacing 8.8.8.8 with your SIP provider.

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

View solution in original post

5 Replies 5

Francesco Molino
VIP Alumni
VIP Alumni

Hi

 

 

To test, can you do a packet-tracer please:

packet-tracer input outside udp 8.8.8.8 46750 x.x.x.x 46750 where x.x.x.x is your public ip

 

 


Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

Certainly. Please see below:

 

FW7BuenosAires-SC5506# packet-tracer input outside udp 8.8.8.8 46750 170.xx.xx.197 46750

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (outside,VOIP) source static any any destination static interface Avaya_IP_PBX-PRI service VOIP-UDP-46750-50750-PRI VOIP-UDP-46750-50750-PRI
Additional Information:
NAT divert to egress interface VOIP
Untranslate 170.xx.xx.197/46750 to 192.168.9.11/46750

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside_access_in in interface outside
access-list outside_access_in extended permit udp any object Avaya_IP_PBX-PRI object-group VOIP-UDP-Ports-PRI
object-group service VOIP-UDP-Ports-PRI udp
port-object eq sip
port-object eq 5061
port-object eq 50795
port-object range 46750 50750
Additional Information:

Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (outside,VOIP) source static any any destination static interface Avaya_IP_PBX-PRI service VOIP-UDP-46750-50750-PRI VOIP-UDP-46750-50750-PRI
Additional Information:
Static translate 8.8.8.8/46750 to 8.8.8.8/46750

Phase: 5
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (outside,VOIP) source static any any destination static interface Avaya_IP_PBX-PRI service VOIP-UDP-46750-50750-PRI VOIP-UDP-46750-50750-PRI
Additional Information:

Phase: 9
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 10
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 11
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 1592613, packet dispatched to next module

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: VOIP
output-status: up
output-line-status: up
Action: allow

Ok it looks good. this is showing all the path the packet will take and, on the firewall, we can see it's sending it to your internal PBX.
You can also confirm by running a tcpdump on ASA on on the switch where PBX is connected to. If you see trafic, the issue is your SIP provider or application layer.
If you have the real public ip of your sip provider, you can re-run the packet-tracer command by replacing 8.8.8.8 with your SIP provider.

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

Thank you Francesco.  Yes, I do have the IP of the SIP provider.  I've rerun the packet tracer using that IP and the results are identical to the above results that used 8.8.8.8.

 

I have run capture tcpdump and what I see is the PBX and SIP server exchange initial 5060 and 5061 TCP traffic but then once RTP UDP traffic starts flowing, it is one way only - meaning that my PBX is sending RTP UDP traffic to SIP server but I am not getting anything back from it. 

 

Thank you for the validation. If you are in agreement, I will publish that this issue is not the ASA. 

Ok, in your global policy, can you check if you have inspect sip?

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question
Review Cisco Networking for a $25 gift card