Bob Dobb wrote:
My home office is growing as my wife moves from the office to the home.
Her work requires her to have an 831 to which is attached a 7960 IP phone.
Currently, my network just has a cheap intel box with OpenBSD doing
nat/firewall. My question is how do I make the openbsd nat/firewall box
disappear in front of the 831, so that her 7960 can configure
appropriately and her work doesn't get all uptight that she is not
connecting it the way they suggest.
I guess the alternative is that I move the openbsd box and all of my
computers behind the 831, but I have been running OpenBSD for 5-6 years
with no problems (for her or me).
I currently have the 831 plugged into a switch via a regular port on the
831 (port 1-4) rather than the ethernet/internet(e1) port which may be
my biggest problem. Of course I can plug other boxes into the 831 in
this configuration and connect to the internet through the OpenBSD nat
box no problems. Since I am not familiar with the Cisco hardware, maybe
someone who has done the same thing can point me in the correct
direction (i.e. do i have to drill holes through my firewall for the
7960 to work).
Thanks.
That would depend if here office support NAT traversal, or if they
expect the Cisco phone to use fix IP's and also if the phone is using
SIP, or MGCP as the protocol of choice. MGCP is the proprietary call
manager for Cisco and SIP would be everyone else, and now Cisco start to
support that as well on their cal manager.
If SIP, then they would connect and control the phone via the UDP/5060
and also they would use a UDP port range for the RTP stream. If they
haven't restricted it, the default Cisco use is 16384 to 32767,
obviously way to wide. However, they need only two ports be stream of
voice and have the 7960 can support as much as 6 lines, they twelve
ports would/could be use. Also, if they allow conference on that phone,
it also add more ports. However, it always start at 16384 by default,
but again is dictate by their configuration. You can always poke around
and found out. The voice however, only use UDP.
Also, the Cisco phone also expect to get the configuration via tftp as
well, so that will need to be allow in form their tftp server, again,
you need to know what it would be.
Last thing it is possible to setup the Cisco phone to work with NAT as
well, inside the Cisco phone, you can preset the NAT IP to use as long
as they let you access the configuration of the phone witch they may not.
Did they provide you with the requirements for the phone, or configure a
router for and tell you to plus it in and be done with it assume you
would accept to do as they wish and protect their phone, but not your stuff?
It is sure possible to make it work behind NAT no problem as long as you
really know their requirements. It become a problem if you need to
connect more then one phone behind NAT at witch point NAT traversal is
required to be configure at both end.
To start with, you need to allow if SIP, UDP/5060 from their SBC as you
want to protect your phone obviously, then the range of UDP ports they
use from their VoIP Gateways as well and the tftp port from their tftp
server for the configuration file to be download as well as the IOS for
the phone when they upgrade it, or patch it.
After that, you are pretty much home free.
When testing, if you don't map the port properly, the phone will ring
and you will pick it up and only have a one way conversation, so easy to
see the problem.
If they do not give you any configuration, or access to the phone
itself, then you can also figure out the setting of their TFTP server as
when you boot the phone, the first thig it does is access the TFTP
server to get the file. So, looking at the log in PF, you can see that
easy, the program that.
They when that's done, you can call the phone from your one land line
phone and then you will see the RTP stream coming to your phone when you
pick it up and look at the IP address as well as the port use. You will
notice that two ports are always use, one for incoming and one for
outgoing. If the default is 16384 on their system for example, you will
see 16384 and 16385 in use. Again easy to see in logs from PF.
So, allow that IP gateways with that range and you will be fine. Also,
it's possible that they use other gateways from third party, so a bit
more tests might be required and you would know that for example by
doing a LD calls as they may have their own gateway for local calls and
use third party for LD, however the source for the SIP 5060 will always
be the same, only the TRP stream will/might be different if more then
one gateways is in use.
So, one way to find that out as well is after you know the port range
they use, you could for a few days allow that port range from any where
and log the different source IP's at with point you would know what
source they would be and then only allow them. If you don't want to do
that and I sure understand that you may not, you can restrict that and
look at the logs when you will get a one way call as then like I said
above two ports are always in use, so you would see the stream coming
out of your PF and nothing coming is as it would be the port associated
with it that is missing.
How to know, again, it is easy.
The ports are always two contiguous ports with the even port the lowest,
and that depend who start the stream.
So, if you see UDP/15795 for example and you have one way voice, then
you would know that the port missing is UDP/15795. Same thing if you
have one way and you see the port in your PF be UDP/34874, then you now
the missing one is UDP/34875.
After you have the range and the various gateways IP's if more then one,
they you are fine.
It's really not that hard to get going. If you have the informations,
it's easy, but they may not want to give it to you, so you sure can
figure it would by just poking around and log with PF.
If they use MGCP however, I wouldn't be able to help you.
Hope this help anyway.
If you need more, just ask!
Best,
Daniel
