Allow RTP/UDP Ports For Any IP

[jonathanblack]

We have several 908e units configured for SIP-to-PRI service from several SIP carriers interfacing to our legacy PRI-based equipment.  These units are not intended to serve as gate-keepers for data access to a LAN, therefore, the firewall is not turned on.  We did explore the firewall option, but it really seemed geared toward traffic passing through, rather than terminating on the unit (for purposes of SIP).

We've configured the SIP trunks with the specific IP addresses of the carriers, and that seems to grant access to allow communication with the carriers' servers for signaling and RTP.  This has worked fine for two carriers, provided we add any RTP addresses as "sip-server secondary" entries. 

We've now brought on a third SIP carrier who tells us that their RTP traffic will be coming from varying IP addresses depending on which underlying carrier is being used--they aren't proxying (is that a word?) the traffic through their servers.  They are recommending that we "specify the ports we can be contacted on for RTP and allow that in our firewall--any UDP traffic for those ports from any originating IP".

The first question is:  How secure is this suggestion?

Secondly: Can this be done on a 908e?  If so, how would we do that?

[Anonymous]

Is the 908 on a public IP or behind a firewall?

[jonathanblack]

Public IP

[Anonymous · Accepted solution]

If the firewall is tuned off on the TA908e then the unit will accept RTP from any IP as long as it’s the SIP header.

At the bottom of the SIP INVITE you will see something like this:

c=IN IP4

t=0 0

m=audio 24358 RTP/AVP 18 0 101

a=rtpmap:101 telephone-event/8000

a=ptime:20

[jonathanblack]

Ok, thanks for the info.  Is there a debug command I can use to determine if RTP traffic is getting blocked?  I normally use:

debug sip stack messages

debug isdn l2-formatted

[jayh]

You probably want the firewall turned on as it is used under-the-hood for quite a bit of the functionality of the box.

Create an access-list as follows:

ip access-list standard sip-allow-list

  permit host X.X.X.X

  permit host Y.Y.Y.Y

  permit host Z.Z.Z.Z

Then apply that to your SIP connections:

ip sip access-class sip-allow-list in

You don't need to worry about RTP, it can come from any media gateway of the SIP providers.  It is generally a good thing that RTP go directly to the media gateway.  This tends to minimize latency of routing it through the SIP provider's network.

When you enable the firewall for the first time, you'll want to do so from the console or be careful not to lock yourself out if enabling it remotely. 

[jonathanblack]

Thanks for the input.  So the "permit host" addresses would be the signaling addresses provided by the SIP provider, and not including any RTP addresses?  Would we not need a rule to handle the RTP servers or is this handled on-the-fly by way of the SIP header as mentioned by @unified, above?

[jayh]

That's handled automatically.  You want to restrict SIP to known hosts and reject all others to avoid the possibility of someone exploiting your system to place expensive international calls.  RTP is set up within the SIP header as mentioned by @unified.

[jonathanblack]

Ok, thanks.  Our experience so far has been that even with the firewall off, the only signaling addresses from which it will accept traffic are those specified in the SIP trunk settings either under "sip-server primary" or "sip-server secondary".  However, this is good information for when we enable the firewall.

[jayh]

jonathanblack wrote:

Ok, thanks.  Our experience so far has been that even with the firewall off, the only signaling addresses from which it will accept traffic are those specified in the SIP trunk settings either under "sip-server primary" or "sip-server secondary".  However, this is good information for when we enable the firewall.

You may be very unpleasantly surprised when you get a phone bill if you don't lock down SIP to known and authorized servers.  I haven't tested simply adding the SIP ACL with firewall not enabled, it may work.  Please lock it down.  Despite their name, the scanners out there aren't very friendly.

[jonathanblack]

The main reason we haven't already is that when we turned on the firewall on a 908e Gen1 unit, after several hours it seemed to stop accepting traffic at all.  Restarting the unit restored service, but then it happened again a few hours later.  We finally turned the firewall back off and the problem went away.

We might try again with a secondary unit and see if we can make it work reliably.

[Anonymous]

The access-list is not using the Adtran firewall.

You can have the firewall disabled and the ACL will still work.

[jonathanblack]

Are you referring to the "ip access-list" and "ip sip access-class" commands that @jayh mentioned above?  Will those two commands work without the firewall enabled?  If so, this may be a good option for us in light of the prior problems we've had with the firewall.

[Anonymous]

Yes that will work without the firewall enabled.

You can use similar commands for SSH and HTTP:

ip access-list standard Access

permit 192.168.1.0 0.0.0.225 #range

permit host x.x.x.x #single ip

http ip access-class Access in

http ip secure-access-class Access in

line ssh 0 4

login local-userlist

no shutdown

ip access-class Access in

[jonathanblack]

Sounds promising, but just to confirm: None of that will impact RTP traffic?  The reason I ask is because in the original problem that generated this post, the SIP provider is telling us that RTP traffic is being blocked.  When they proxied the RTP traffic through their IP (which I have entered as a "sip-server secondary"), the traffic comes through.

[Anonymous · Accepted solution]

I do this all the time without a problem.

If the Adtran is setup on a public IP and its firewall is disabled nothing should be blocked by the RTP ports.

[jayh]

RTP traffic to a remote media server on a random IP different from the defined SIP server won't be affected.  It will just work.  By limiting the SIP servers with an access list you will protect against fraud. 

[jonathanblack]

I've just confirmed with the SIP provider that it isn't blocking RTP traffic from "non-registered" IP addresses.  And we're unable to reliably replicate the problem, so I'm going to assume the problem is on the provider's side and close this out.  Thanks to both of you, and , for your input and assistance!