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

ASA 5510 - Hide SDP C= behind NAT

DavidOConnor
Level 1
Level 1

Good Afternoon,

 

We have been working tirelessly trying to find a solution to this and i have now lost the will with it.

 

I have a Cisco ASA 5510 which i have configured for our inside border controllers (Not Cisco) to an external suppliers border controllers.  The external supplier sends all of their singalling (5060) and RTP (6000-40000) to the same IP address which is the MPLS interface between us and them.  In addition to this we have to manipulate our traffic to look like its come from this IP address, not just source / destination but SIP packet inspect to hide the server IP addresses.

 

Now this all works fine in terms of singalling, this is also the case with us sending out RTP traffic out - when we place test calls the user is able to hear the call crystal clear. However after speaking with the supplier they are advising that the C= inside the SDP part of the SIP/SDP packet has not been manipulated to show the NAT'd address whilst everything else has.

 

Outside IP 1.1.1.1

External SBC Address 2.2.2.2

External Media Address 3.3.3.3

Inside SBC Address 4.4.4.4

Inside Media Address 5.5.5.5

 

SIP Invite and 183 Session Response

 

Invite to External SBC
INVITE sip:01234567891@2.2.2.2:5060 SIP/2.0 From: "01234567891"<sip:01234567891@1.1.1.1:5060>;tag=1449c080-bc5470a-13c4-55022-ff847-4a1891bf-ff847 To: "01234567891"<sip:01234567891@2.2.2.2:5060> Call-ID: 14c57c68-bc5470a-13c4-55022-ff847-5d171411-ff847 CSeq: 1 INVITE Supported: 100rel,timer,replaces Max-Forwards: 69 Via: SIP/2.0/UDP 1.1.1.1:4123;rport;branch=z9hG4bK-ff847-3e61d55d-627b7fa5 Session-Expires: 1800;refresher=uac Contact: <sip:01234567891@1.1.1.1:4123> Record-Route: <sip:HOST@1.1.1.1:4123;transport=udp;lr> Content-Type: application/sdp Content-Length: 219 v=0 o=dcpsrv 1539860533 1539860533 IN IP4 5.5.5.5 s=call c=IN IP4 5.5.5.5 t=0 0 m=audio 18312 RTP/AVP 8 96 a=rtpmap:8 PCMA/8000 a=ptime:20 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15 a=sendrecv Response from External SBC SIP/2.0 183 Session Progress Require: 100rel Via: SIP/2.0/UDP 1.1.1.1:4123;rport=5060;received=1.1.1.1;branch=z9hG4bK-ff847-3e61d55d-627b7fa5 RSeq: 1 Record-Route: <sip:HOST@1.1.1.1:4123;transport=udp;lr> To: <sip:01234567891@2.2.2.2>;tag=3748849336-582865851 From: <sip:01234567891@1.1.1.1>;tag=1449c080-bc5470a-13c4-55022-ff847-4a1891bf-ff847 Call-ID: 14c57c68-bc5470a-13c4-55022-ff847-5d171411-ff847 CSeq: 1 INVITE Allow: UPDATE,PRACK,INFO,NOTIFY,REGISTER,OPTIONS,BYE,INVITE,ACK,CANCEL Contact: <sip:01234567891@1.1.1.1:5060> Content-Type: application/sdp Content-Length: 217 v=0 o=MSX138 7202704 7202704 IN IP4 2.2.2.2 s=sip call c=IN IP4 3.3.3.3 t=0 0 a=sendrecv m=audio 22018 RTP/AVP 8 96 a=rtpmap:8 PCMA/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15 a=ptime:20

 

As you can see we hide everything but the SDP connection address and this is resulting packet drops completely from the external side as they cant route our internal IP address and won't do it either.  They insist that all their traffic must use the 1.1.1.1 address which is almost true except for the SDP field that is telling their SBC/Media Gateway to send their RTP traffic to our inside IP address.

 

Nat Statements have to be unidirectional as we are pointing to them but they are point at the 1.1.1.1

 

nat (inside,outside) source static 4.4.4.4 1.1.1.1 destination static 2.2.2.2 2.2.2.2 service SIP SIP unidirectional
nat (outside,outside) source static 2.2.2.2 2.2.2.2 destination static 1.1.1.1 4.4.4.4 service SIP SIP unidirectional
nat (inside,outside) source static 5.5.5.5 1.1.1.1 destination static 3.3.3.3 3.3.3.3 service RTP RTP unidirectional
nat (outside,outside) source static 3.3.3.3 3.3.3.3 destination static 1.1.1.1 5.5.5.5 service RTP RTP unidirectional

 

Inspection Policy

 

policy-map type inspect sip SIPInspectionMap
 parameters
  ip-address-privacy
  max-forwards-validation action log
  state-checking action log
  software-version action log
  strict-header-validation action log
  uri-non-sip action log
policy-map outside-policy
 class outside-class
  inspect sip SIPInspectionMap
  user-statistics accounting
service-policy outside-policy interface outside
class-map outside-class
 match port udp eq sip

 

 

I am not sure if i am missing something fundamental and basic? We attempted this with a Watchguard M200 firewall which did replace the SDP Connection information using SIP - ALG however we lost 70% of packets to and from us and the supplier. 

 

A lot of the examples i find for manipulating the NAT are not for ASA 5500 series and as a result the command isnt recognised.

 

Would appreciate if someone could help out here and point me in the right direction!

 

Appreciate it.

David

 

1 Accepted Solution

Accepted Solutions

Thanks for the reply and it was helpful, becuase when we traced this we found that it was working but was working as a PAT as well. The SIP Inspection was then 'Hiding' the server address and port but only when both where present as in the C= case - it was only showing an IP address, as a result it wasnt getting processed in the SIP Inspection map.

We disabled the original NATS and placed it as an object NAT with no service information attached.  Audio both ways now and the C= section of the SDP packet is now being matched and translated so the External SBC now knows where to send the call to and our 1-1 NAT sends it on accordingly.

object network LocalSBC
 host 4.4.4.4
object network SIPGateway
 host 1.1.1.1
object network LocalMG
 host 5.5.5.5
object network ExternalSBC
 host 2.2.2.2
object network ExternalMG
 host 3.3.3.3

object network LocalSBC
 nat (inside,outside) static SIPGateway
object network LocalMG
 nat (inside,outside) static SIPGateway


Thanks again.

View solution in original post

2 Replies 2

I've doubt about your NAT. According to the documentation the NAT should be:

 

ciscoasa(config)# nat (inside,outside) source static MyInsidePrivateNetwork MyOutsideMappedNetwork destination static InsideIP OutsideIP service REAL_SRC_SVC MAPPED_SRC_SVC

 

This is an example:

object network MyInsNet
subnet 10.1.2.0 255.255.255.0
object network MapInsNet
subnet 209.165.202.128 255.255.255.224
object network Server1
host 209.165.200.225
object network Server1_mapped
host 10.1.2.67
object service REAL_ftp
service tcp destination eq ftp
object service MAPPED_ftp
service tcp destination eq 2021
object network MyOutNet
subnet 209.165.201.0 255.255.255.224
 
nat (inside,outside) source static MyInsNet MapInsNet destination static Server1_mapped Server1 service MAPPED_ftp REAL_ftp
 
So in you case should be something like:
nat (inside,outside) source static 5.5.5.5 1.1.1.1 destination static 5.5.5.5 1.1.1.1 service SIP SIP
 
Do you have tried this NAT?
Regards.

Thanks for the reply and it was helpful, becuase when we traced this we found that it was working but was working as a PAT as well. The SIP Inspection was then 'Hiding' the server address and port but only when both where present as in the C= case - it was only showing an IP address, as a result it wasnt getting processed in the SIP Inspection map.

We disabled the original NATS and placed it as an object NAT with no service information attached.  Audio both ways now and the C= section of the SDP packet is now being matched and translated so the External SBC now knows where to send the call to and our 1-1 NAT sends it on accordingly.

object network LocalSBC
 host 4.4.4.4
object network SIPGateway
 host 1.1.1.1
object network LocalMG
 host 5.5.5.5
object network ExternalSBC
 host 2.2.2.2
object network ExternalMG
 host 3.3.3.3

object network LocalSBC
 nat (inside,outside) static SIPGateway
object network LocalMG
 nat (inside,outside) static SIPGateway


Thanks again.

Review Cisco Networking for a $25 gift card