?
Solved

Cisco ASA 5505 Allow SIP Through

Posted on 2011-10-19
11
Medium Priority
?
3,793 Views
Last Modified: 2012-06-21
I'm having issues with my VoIP Phones, where I'm getting one way audio.  I setup wireshark and tracked packets and can see my firewall is blocking some of the packets.

I want to allow all SIP and RTP traffic from specific IP range through my firewall.  What are the correct commands to do this?
0
Comment
Question by:Railroad
  • 6
  • 4
11 Comments
 
LVL 28

Expert Comment

by:asavener
ID: 36997917
We need network topology.

Is this all internal traffic?  (i.e., the ASA is blocking traffic that should be routed internally)

Or is this SIP traffic that's supposed to be traversing the firewall?

(Lots of folks try to use the ASA as a router, when it is really a firewall.  It blocks traffic that a router would pass, because it only sees one side of the conversation, and so it blocks the traffic.)

If this is all internal traffic, try adding a static route for that particular destination.
0
 
LVL 36

Expert Comment

by:grblades
ID: 36998316
Do you have any other sip phones behind the firewall?
Do you have sip inspection enabled on the ASA?
Are you phones configured to enable ICE?
Are your phones configured to use a STUN server?
0
 

Author Comment

by:Railroad
ID: 37002881
We are using a hosted VoIP system, so yes all the traffic has to pass through the firewall.

I have in the firewall:

object-group network SIP_SERVERS
 network-object x.x.x.96 255.255.255.224
object-group service SIP_PORTS
 service-object udp range 10000 20000
 service-object udp eq sip

And then for testing:

access-list outside_access_in extended permit udp any object-group SIP_SERVERS
access-list outside_access_in extended permit tcp any object-group SIP_SERVERS

The ASA is still blocking/dropping traffic from the servers however, although it's not reporting it's doing to in any of the debug logging.


No SIP inspect is not turned on, I was told by the VoIP provider to turn this off.

There are 21 phones behind the firewall.

Unsure about ICE and STUN, don't know what they are.  The phone were pre-configured by the vendor.
0
 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

 

Author Comment

by:Railroad
ID: 37002962
I removed the two testing commands and added:

access-list outside_access_in extended permit object-group SIP_PORTS object-group SIP_SERVERS any
0
 
LVL 36

Expert Comment

by:grblades
ID: 37003418
Your two access lists are allowing completely different traffic. Are x.x.x.96 you ip addresses or those of the VoIP provider?

Normally what would happen when your phone makes a call is it will advertise the ip address the audio should be sent to. This will normally be your internal ip address so if the pbx tries to send traffic to this internal address it won't go anywhere.
You can have detection built into the pbx, have stun or ice support enabled on the phones or have sip inspection enabled on the firewall. Normally any of these will fix the problem (but some methods can have issues with call transfers) but trying to use more than one method at a time can stop it from working.

There s nothing you have to do on the firewall to make it work as incoming audio should be treated as a reply but some config can make things work better. I would suggest increasing the udp connection timeout to at least a couple of minutes though.

I would contact the people who supplied the pbx and ask what nat detection method they are using.
0
 

Author Comment

by:Railroad
ID: 37003470
The x.x.x.96/27 are the VoIP Servers from the provider.

FYI, this all worked well (For 2 months), without any special statements in the firewall until Monday.  Then Monday morning we started getting one-way audio.  It's always, that the person being called can not hear the caller.

Nothing was change on my ASA and supposedly nothing changed on the providers end.  It's happening to four different sites, three with Cisco ASA 5505 and 1 with m0n0wall.

In sniffing the traffic on the ASA, I can see the packets hitting the outside interface of the ASA, but then are not transmitted on the inside interface.  And debug logging shows no dropped packets.

FYI, upgrading the ASA to 8.2(5) and the reboot didn't correct the issue.
0
 
LVL 36

Expert Comment

by:grblades
ID: 37003703
Always the person being called? Regardless of outgoing or incoming call?
Or is it always you don't hear the audio?
Who is calling? From one location to another?
Does it work ok with calls out to general destinations where the call has to go over regular telephone system?
0
 

Author Comment

by:Railroad
ID: 37004153
Yes, it is always the person being called that can not hear the caller; if the one way audio issue arises, it doesn't always.

There is a fifth site, which is connected to the local network of the VoIP provider; this site has no issues.  If an "off-site" phone calls an extension at this "on-site", there are no issues with the call.

If the off-site locations call another off-site location, local to that site or not, this is where the issue arises.  But it doesn't always happen, I haven't figured out any pattern to it.

If an off-site phone calls a POTS lines, there are no issues.  If a POTS line calls and off-site phone there is an issue.

Boggles my mind, can not figure it out.
0
 
LVL 36

Expert Comment

by:grblades
ID: 37005085
It does sound like a firewall/NAT issue and you did say you can see the traffic coming back in and hitting the firewall.

For the traffic going out does the source port and IP address match the destination port and IP address for the incoming traffic?
This would be required for the firewall to think they are replies to the already established outbound connection and therefore permit the traffic back in and also know which internal IP address and port the traffic should be forwarded to.
0
 

Accepted Solution

by:
Railroad earned 0 total points
ID: 37243644
Cisco TAC installed an upgraded Firmware for the ASA and rebuild the inspect rule.  Solved issue.
0
 

Author Closing Comment

by:Railroad
ID: 37268894
It's what solved the issue.
0

Featured Post

NFR key for Veeam Backup for Microsoft Office 365

Veeam is happy to provide a free NFR license (for 1 year, up to 10 users). This license allows for the non‑production use of Veeam Backup for Microsoft Office 365 in your home lab without any feature limitations.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

If your business is like most, chances are you still need to maintain a fax infrastructure for your staff. It’s hard to believe that a communication technology that was thriving in the mid-80s could still be an essential part of your team’s modern I…
Why do some people recommend buying business VoIP from an ISP? What are the benefits to my company? What are the costs?
This lesson discusses how to use a Mainform + Subforms in Microsoft Access to find and enter data for payments on orders. The sample data comes from a custom shop that builds and sells movable storage structures that are delivered to your property. …
When cloud platforms entered the scene, users and companies jumped on board to take advantage of the many benefits, like the ability to work and connect with company information from various locations. What many didn't foresee was the increased risk…
Suggested Courses
Course of the Month16 days, 15 hours left to enroll

862 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question