How to conservatively translate "open these ports in the firewall" requests?

Being a network administrator, among other things, I'm often asked by users to open ports in a firewall.
Usually the users don't know much about what they're asking for so they can't answer any questions - just forward what their technical people have provided.

Here is a typical example for a VOIP system:

The full network information for the VoIP system is:
Port Range (Audio): 35000-65000 UDP
Port Range (SIP): 5060 UDP, 5061 TLS
Port Range (Configuration Servers): 1024-65536 TCP source port, TCP Destination ports: 80, 443, 1443, 2443, 6716,
Port Range (Presence Servers): TCP Destination ports: 5222 and 5280.
I guess that's all well and good if you understand the context but that's where I'm not the expert.

I can set up firewall rules but, being conservative, I don't want to open incoming ports just willy-nilly in order to assure that the requestor gets what he/she wants.
If I ask them: "Are these incoming ports or outgoing ports?" they have no idea.
In some cases, I'm sure that some are outgoing.....
What I'm used to, for the most part, is that all outgoing will be allowed and all incoming will be blocked unless initiated by outgoing traffic.
Given this limited view, I would want to set up to allow incoming traffic to certain ports and leave things at that.
But, which ones?

I know this is likely a naive question.
So, in my context of understanding, how would you interpret the specification above?
And, in the details, I've never set up a firewall that had a "TLS" port setting available (as compared to TCP or UDP) ......
LVL 27
Fred MarshallPrincipalAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

KimputerIT ManagerCommented:
The full network information for the VoIP system is: Port Range (Audio): 35000-65000 UDP

That's a sloppy range. The VOIP system should do much better. Limit it to a narrower range, and make it clear if it's source/dest (and thereby incoming or outgoing.

Port Range (SIP): 5060 UDP, 5061 TLS

It depends if the VOIP server is inside your LAN or not. If yes, it's incoming. If not, it's outgoing.

Port Range (Configuration Servers): 1024-65536 TCP source port, TCP Destination ports: 80, 443, 1443, 2443, 6716,
Again, ridiculous port range. Assume it's outgoing though.

Port Range (Presence Servers): TCP Destination ports: 5222 and 5280.

It depends if the VOIP server is inside your LAN or not. If yes, it's incoming. If not, it's outgoing.



Generally speaking, you have to do research for each request. Usually, if it's to reach a server inside your network, it's incoming. If it's because the users have a client app, it's usually outgoing.

Also, in most situations, I don't filter outgoing, except port 25 to prevent spam. If you have the same logic, you don't really have to pay attention to any request that's for outgoing ports.
Fred MarshallPrincipalAuthor Commented:
Kimputer: Thank you!
Well, just to be clear, the information that I provided comes from a VOIP provider - it's their information and I have no control over it.
The VOIP server (if I understand at all what this means) is outside.  Well, all we have are telephones and that's it.  Perhaps you mean the VOIP PBX?  I've seen those both ways but most cases I'd be dealing with, it is outside.

What I have to do is to set up the local firewall so that:
1) VOIP works
2) the firewall settings aren't sloppier than needed for (1).

So, now I'll translate what you said:

VOIP Provider sez: The full network information for the VoIP system is: Port Range (Audio): 35000-65000 UDP

That's a sloppy range. The VOIP system should do much better.
Limit it to a narrower range - I can't change what they said here.
Make it clear if it's source/dest (and thereby incoming or outgoing).  I sure agree that it would be helpful for them to say.

VOIP Provider sez: Port Range (SIP): 5060 UDP, 5061 TLS

It depends if the VOIP server is inside your LAN or not. If yes, it's incoming. If not, it's outgoing.

Since it's outside the LAN then it's outgoing and not needed (to be dealt with in firewall settings) at all.

VOIP Provider sez: Port Range (Configuration Servers): 1024-65536 TCP source port, TCP Destination ports: 80, 443, 1443, 2443, 6716,
Again, ridiculous port range. Assume it's outgoing though.
Again, if outgoing then no special firewall settings needed.  But, if THEY said "outgoing" then we'd know for sure.  In truth, I have asked about 80 and 443 in the past as was told it was needed incoming with the server outside.  Not that the answer I got was correct but it sure was conservative for THEM.

VOIP Provider sez: Port Range (Presence Servers): TCP Destination ports: 5222 and 5280.
It depends if the VOIP server is inside your LAN or not. If yes, it's incoming. If not, it's outgoing.
Again, if outgoing then no special firewall settings needed.  But, if THEY said "outgoing" then we'd know for sure.  

Generally speaking, you have to do research for each request. Usually, if it's to reach a server inside your network, it's incoming. If it's because the users have a client app, it's usually outgoing.
Right.  But what's harder to ascertain is whether they might be trying to use incoming ports and whether their point of contact knows the difference.....  In most of the cases I run into, the whole thing is a bit of a nuisance for me and the people I have to deal with are often fairly clueless in that they simply pass on the information that they've been given.  Not to be disparaging as they are nice people and we both have our jobs to do.  My point is that the "research" is often difficult.  The same set of issues come up when visitors are going to be using their own VPN to "phone home".

Also, in most situations, I don't filter outgoing, except port 25 to prevent spam. If you have the same logic, you don't really have to pay attention to any request that's for outgoing ports.
Yes, that's what I've been doing.

My belief is this:
They tell us that certain ports have to be open.  
This could include all the outgoing ports that are already open.
But, without information, we'd have to open the same incoming port numbers with no legitimate purpose.
The specifier is being conservative in making it easy for his/her people and app's -  to the detriment of the firewall.
N. SpearsSr.Net.EngCommented:
The main thing I ask when I get the "I need the fw rule to be Bi-directional" request is "Which side is initiating the connection?"  This seems to always clear things up with app or system folks.
Monitor and Analyze Slow Network Performance

SolarWinds® Bandwidth Analyzer Pack, is designed to detect, diagnose, and resolve network performance issues, and monitor and test network throughput and traffic patterns from a single customizable console.

Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
Yes, the direction is the main issue. What the provider tells is too unspecific. BTW, I think TLS is a typo and means TCP, as TLS is  SSL and can use both UDP and TCP.

If you cannot get the "issuer" to provide more detailed information, you need to do your own research on each individual protocol used.
E.g. SIP is used for signaling phone calls, with a fixed target port (which means outgoing phone port X to PBX port 5060/5061 and incoming PBX X to phone 5060/5061).
And a port range of 1024-65535 of course means "all ports", usually for the source port.

Note that your firewall needs to be SIP aware (because the phone IPs get NATted), or the phones have public IPs not getting translated-

Setting up VOIP traffic can get very complex and flaky. Usual issues are calling/signaling works, but no voice is heard, as there are two audio streams often using UDP with unspecific ports.
nociSoftware EngineerCommented:
VOIP 5060 UDP (unencrypted SIP), 5061 UDP(Encrypted SIP) and 5060 TCP (Both unencrypted/encrypted(TLS) SIP over TCP).

This is from a phone in the direction of a PBX.
A PBX will return the the traffic to the IP address/Port that was given during registration.
Be aware that in the case of NAT the SIP registration timeout should be well below the NAT timeout. (Otherwise you cannot be called again if the NAT entry expires.)

The Audio ports are a given and should be setup as UDP bidirectional (The are negotiated during SIP CALL setup).

A SIP ALG can be used to proxy for the portnumbers BUT very many ALG's are flawed of don't cooperate well with a given PBX. A serious PBX will be able to handle FENT (Far End NAT) without ALG.
if the PBX is off-premises (Outside) then all port 80, 443, etc. are in the direction of the PBX, your VOIP provider SHOULD know the difference.
masnrockCommented:
Onsite or cloud PBX? That is going to help majorly in figuring out this mess. I have seen vendors give big lists of firewall ports without citing which systems those ports should be open on until they get pressured.

A lot of good points have been brought up already (namely the vagueness on the part of the vendor from what you have presented), and it is concerning that the telephone people don't seem to be able to answer whether the ports they are asking about are in or outbound.

But having that answer of onsite of cloud, as well as they type of PBX (if known) would be a possible way of getting around their lack of clarity.
Fred MarshallPrincipalAuthor Commented:
masnrock:  Good point!  Of course, *we* generally know if the PBX is internal or external but what they tell us may not differentiate and we may assume that it must be tailored to our situation.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Hardware Firewalls

From novice to tech pro — start learning today.