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

SIP Inspection and dynamic port opening after re-invite

ahmed.jama
Level 1
Level 1

Platform: ASA 8.3(2)

Hello,

I have SIP devices along with SipTrunk and media endpoints. I am having issues with the ASA not dynamically opening (sip inspect enabled) UDP ports for RTP after a SIP re-invite causes the media endpoints to change within SDP.

The problem as below.

Initial SIP invite setups properly with ports dynamically opened between the media endpoints in the ASA

Re-inivite from the SIP device causes the media endpoints to change within the SDP

ASA blocks ports associated to the new media endpoints

I can resolve this by allowing the ports in the ACL, but suprised this is not working as re-invites to change media endpoints is to be expected in SIP conversation.

Regards,

AJ

1 Accepted Solution

Accepted Solutions

Hello Ahmed,

Great, thanks for the resolution,

Do mark the question as answered so future users can learn from your solution.

Kudos to you

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

View solution in original post

10 Replies 10

Julio Carvajal
VIP Alumni
VIP Alumni

Hello Ahmed,

Looks like the ASA is doing it's job regarding the SIP inspection..

That being said is also failing as there are re-invites that will come from a diferent media endpoints, correct?

I mean that would be expected as the ASA already open and mantain on it's stateful table a particular SIP connection between 2 endpoints, if the endpoints change then of course they will be blocked.

Let me know if I understood this properly?

Julio

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

Hi Julio,

Thanks for the update. The initial invite in the SIP call is correctly setup by a SIP proxy and SIP trunk using a media device and a SIP Trunk. The SIP end points (sip proxy and sip trunk) stay the same for the entire duration of the call, a reinvite occurs to change the media end points in the SDP in order to establish T38 between a new media end point and the SIP trunk (Same SIP call). Since the ASA already had ports opened for this SIP call, isn't it just a case of updating ip addresses/ports for the new end points as this is to be expected in a SIP call.

Ahmed,

Sent from Cisco Technical Support iPad App

Hello Ahmed,

It is definetly expected for the ports but I am not sure about the IP addresses, I mean the ASA will notice that there is no Connection between those 2 hosts.

What does the logs say?

Regards,

Julio

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

Logs show the ASA denying the packets, endpoints/ports correspond to SIP SDP for the reinvite.

Sent from Cisco Technical Support iPad App

Hello Ahmed,

Where is the connection being innitiated (Inside or outside)????

What the ASA is going to do with the SIP protocol is follow the signaling exchange of information so the data chanel can be open dynamically with no problem ( Open the required ports for the endpoints over the communication) that is why the endpoints do not need to change,

Regards,

Julio

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

Outside. I have allowed SIP from the SipTrunk to my SIP device.

Per the SIP RFC this should work as this normal SIP behaviour.

"During the session, either Alice or Bob may decide to change the

characteristics of the media session. This is accomplished by

sending a re-INVITE containing a new media description. This re-

INVITE references the existing dialog so that the other party knows

that it is to modify an existing session instead of establishing a

new session. The other party sends a 200 (OK) to accept the change.

The requestor responds to the 200 (OK) with an ACK. If the other

party does not accept the change, he sends an error response such as

488 (Not Acceptable Here), which also receives an ACK. However, the

failure of the re-INVITE does not cause the existing call to fail -

the session continues using the previously negotiated

characteristics"

http://www.ietf.org/rfc/rfc3261.txt

Sent from Cisco Technical Support iPad App

Hello Ahmed,

Good, we are getting closer,

May I see the NAT and the ACL configuration to make this work.

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

Below is the script you can use to reproduce this. Points worth mentioning.

  • Initial invite sets up the media between SIP Trunk and a media device ( 10.1.2.150) in the inside network, SIP signalling will be with 10.1.2.100. At this poit RTP flows freely between the SIP Trunk and the media device.
  • If the call is fax, a re-invite will occur and this will cause the IP address to change in the SDP. The new media endpoint becomes 10.1.2.151 (This device is SIP and Media (T38) capable).
  • For every SIP call we establish 10.1.2.150 will be used for media, we do not want to change this behaviour.

!

ASA 8.3 (2)

!

conf t

!

interface Ethernet0/0

nameif Inside_Voice

security-level 100

ip address 10.1.2.11 255.255.255.0 standby 10.1.2.12

exit

!

interface Ethernet0/1

nameif Outside_SIP_Trunk

security-level 0

ip address 10.1.60.254 255.255.255.0 standby 10.1.60.253

exit

!

object-group network SIP_trunks

network-object 1.2.3.0 255.255.255.0

exit

!

object-group service SIP_service

service-object tcp destination eq sip

service-object udp destination eq sip

exit

!

object-group network SIP_inside_servers

network-object host 10.1.2.100

exit

!

access-list Outside_SIP_in extended permit object-group SIP_service object-group SIP_trunks object-group SIP_inside_servers

!

access-group Outside_SIP_in in interface Outside_SIP_Trunk

!

route Outside_SIP_Trunk 0.0.0.0 0.0.0.0 10.1.60.1

!

class-map inspection_default

match default-inspection-traffic

exit

!

policy-map global_policy

class inspection_default

inspect dns preset_dns_map

inspect ftp

inspect h323 h225

inspect h323 ras

inspect ip-options

inspect netbios

inspect rsh

inspect rtsp

inspect skinny

inspect esmtp

inspect sqlnet

inspect sunrpc

inspect tftp

inspect sip

inspect xdmcp

inspect icmp

inspect icmp error

lass class-default

set connection decrement-ttl

exit

!

service-policy global_policy global

!

end

Just FYI, I opened a TAC case and this was failing because of the T38 payload in the SDP of the re-invite. As of now T38 is not supported in ASA codes. Our work around was to allow the relevant ports in ACL so that media traffic was not dropped.

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtr86607

Hello Ahmed,

Great, thanks for the resolution,

Do mark the question as answered so future users can learn from your solution.

Kudos to you

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: