cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3105
Views
10
Helpful
13
Replies

SIP behind firewall no audio in both ways

aouelali
Level 1
Level 1

Hello Everyone im new in voip im working in new project and i have this toplogy 

Cisco jabber -->Cucm-->Cube-->Firewall(sophos)--->INTERNET(SIP-Trunk)

the problem was the phone ringing but there's no sound in both ways and i think the problem is NAT 

the firewall is sophos 

the internal call is working fine but when i establish a call to outside there's no audio in both ways 

which NAT should i put in the firewall 

i use this NAT but it does't work 

thnx

 
 

image_2020-11-30_171646.png

nat.PNG

 

 

13 Replies 13

Ritesh Desai
Spotlight
Spotlight

Hi @aouelali 

 

I assume its new project so assume it was not working before...

Your signaling is also good that it reaches the destination.

 

What I would do is to make sure configuration is correct and required configuration is in place on CUBE. to do so check below.

 

First step is you make sure that, the SIP PROVIDER would have given you SIP TRUNK MEDIA IP ADDRESS. Is that configured and allowed on your CUBE ( ip route <SIP trunk media ip><subnet mask><default gw to reach sip trunk>) Please check this first.

For media to establish please check if the media IP address is allowed on CUBE side. Also, if you are specifically allowing IP address, then add the Media IP address in voice service voip > ipv4 <sip trunk media sip address>

 

Second Step is to check on CUBE which media IP address you are getting. there is possibility of incorrect media ip address is sent, incorrect media ip address is configured, etc.

 

Basis the above steps, it depends the next actions....

*** Please rate helpful post. Please mark as answer if it solves your problem/query.
regards, Ritesh Desai

Thank you for reply

I check the configuration on cube and it's good .i can ping the SIP TRUNK from the CUBE.

the cube has only one interface 192.168.5.5 and i use NAT i reach the SIP TRUNK and i think the problem in the rule NAT can you confim is that rules is good

best regards

@aouelali  Pinging the SIP TRUNK does not mean your end to end communication will be success.

One more thing, is the FW allowing UDP ports 16384 - 32767 for RTP. Also, the processing of UDP packets on FW may also cause (i m assuming).

 

What you can do here is by enabling the debugs on CUBE and check when the ACK is sent in SIP MESSAGES debug.

 

#debug ccsip messages

#debug voip ccapi inout

Please analyse to go for next stage.

*** Please rate helpful post. Please mark as answer if it solves your problem/query.
regards, Ritesh Desai

Recommend you to reconfigure your SBC (Cube) to have two interfaces. One connected to your internal network and the other connected to your firewall for the connection to the SIP service. This would be the preferred setup of a SBC for it to truly come to it’s right as the demarcation point between your internal network and the external SIP service provider.



Response Signature


Are you recommending that the CUBE connection would look like this?

cube-two-interfaces-roger.png

Yes that’s correct. Anyway if the OP wants to have a firewall in front of the outside interface of the SBC to the service provider. This is not all that common in my experience, as the SBC can be setup with its own security enforcement, but if for example the connection to the service provider would utilise internet it could be a requirement for various reason.



Response Signature


Ah that's interesting and thanks for sharing your experience with it.  That is not a deployment I have ever seen before, and while I agree that the CUBE has its own security features built in, I would just as soon leave it on a single interface in the DMZ, just being careful with my NAT and ALG.

The reason for why I would argue to have an inside interface is that there is little point in having the internal endpoints communicate with the SBC via a firewall. I mean you would not likely contemplate to do that with a TDM voice gateway, right? See it as you would for a Expressway C, you would not very likely put a firewall between that and your endpoints. There is a merit to have the interface that face the service provider behind a firewall for protection. But as you say keep clear of NAT as that's s pretty sure way of successfully creating a perfect storm of issue and shorten your expected lifespan with a few odd years or so.



Response Signature


Yeah, I hear you on those points.  But, I wonder what the security folks would say about having systems in the dmz with direct inside connections, bypassing the security from DMZ to Inside (security levels, ACL, IPS, IDS, etc.)

True, those paranoid security folks are always “fun”. Joke aside, it would depend on what type of connection you utilities for the circuit with the service provider. If it’s a less secure connection type like internet this could absolutely be of concern.

My experience is that this is not the preference connection type for most service providers. More common would be to use a dedicated private connection to deliver the SIP service. This also in most cases removes the need to use encryption to protect the media and signaling path between the customer and the service provider. Whereas with a service running via internet this would be a necessity to protect the integrity of the traffic.



Response Signature


Yeah, I see no FW in the mix for private connections.  The FW only comes up when the connection is public and things like SIP Vicious start scanning you.  The FW is nice in this context because it can block the traffic to CUBE, and let CUBE spend more time processing real calls.  This way your max calls and/or CPS don't take a hit.

Anthony Holloway
Cisco Employee
Cisco Employee

NAT does present a challenge with SIP, because while the signaling might seem fine*, the media establishment is tucked away deep inside the packet payload where NAT cannot reach.  For this, you need some sort of application layer gateway (ALG) functionality to be able to open the payload and perform a re-write of the addresses inside the SIP message headers and bodies.  You can achieve this in one of two ways:

  1. You could enable this functionality on your NAT device.  Which I think you said is Sophos.  That's not a product I know, but a google search leads me to this page: https://support.sophos.com/support/s/article/KB-000035917?language=en_US
  2. You could disable this functionality on your NAT device (same link as above) and use the CUBE itself to rewrite the headers and body for you, like how I show in the following post**: https://community.cisco.com/t5/ip-telephony-and-phones/cube-sip-nat-without-alg/m-p/3989857#M384324

* Technically you would receive the setup because the layer 3 routing is working, but you would fail to receive a BYE message since this is sent to the address in the Contact header.

** Technically you will also need a /32 loopback interface on CUBE of the public IP address (61.x.x.x) as most newer versions of CUBE will not honor or respond to SIP messages to IP addresses which do not exist on itself.

aouelali
Level 1
Level 1

thnx all for this answers but the problem after spending some time with my manager it was in dial-peer and the configuration in the cube

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: