Initiating VOIP with DHCP
I'm working at integrating Mitel 6867i phones into our network.
At first, the provider said that there had to be firewall ports open (and, obviously NOT forwarded to any particular IP). That is, the ports had to be opened incoming and outgoing.
Well, usually outgoing is open by default. So that would only be mentioned to CYA.
And, if outgoing is all that's needed then saying incoming is needed seems double CYA.
Right?
My hope is that no firewall ports need be specifically opened at all.
But, I started on this path by accepting what they specified and decided I would NOT run these things through our main firewall at all.
So, there will be a separate firewall as we have enough public IP addresses to accomodate.
And so, there has been a VLAN set up just to service the VOIP phones and to keep the firewall LANs separated.
I hope this much sounds like a reasonable approach.
If you're familiar with these phones (and I hope you are) then you'll know that the phones will accept a trunk line connection and "pass through" the main LAN / e.g. VLAN1 untagged to the computer on the desk. (This saves running a new cable to the desk assuming the computer is already cabled). And, the phone functions are supposed to run off a tagged VLAN / e.g. VLAN100 that's combined on the trunk.
All this seems fine so far. I'm a little uncomfortable with the phones being so integrally connected inside the network but it seems like accepted practice.
As they say, "the devil is in the details":
- I have connected the VOIP firewall/router/gateway with it's own LAN subnet to our main LAN switch on a VLAN100 untagged access port. This seems to work.
- I can connect a phone to a VLAN100UP access port on the main switch and it will work. I'm not sure I can say that about trunked ports on the main switch.
- There are other switches cascaded down using trunked connections.
- Most ports on those switches are trunked as well.
- Phones connected to those other trunked ports aren't working right. They are not identified as being on VLAN100 even though they are set up to do that. They don't get an IP address from the VOIP gateway.
- One hypothesis is that they will work an an Access, Untagged VLAN100 port and NOT on a trunked port. If true, that puts new requirements on the installation.
I've been told that the phones start out by connecting to VLAN1, get an IP address from the VLAN1 DHCP server (there *is no* DHCP service on VLAN1!!) and then switch over to VLAN100 and subsequently get an IP address from there.
This is a surprise that hasn't quite sunk in yet
Now I have two issues:
1) What shall I do to make these phones work since trunk lines are necessary to serve the computers.
a) One idea is to provide a DHCP server on VLAN1 but that's a big bandage for a little cut. Gee, we could talk about MAC-address assignments, etc. etc. just more admin.
b) Another idea is that accessing VLAN1 internal to the phones really shouldn't be necessary - but I don't know enough about these phones yet to be able to pursue that idea.
2) Should I be concerned about network security when the phone guy just casually mentions that VLAN1 is going to be used by these phones - even if briefly? I was getting used to the idea of them being a relatively dumb switch that would pass through VLAN1 to the adjacent computer and only be using VLAN100 internally - but this is something different altogether as I see it. That's the trouble with having a "functional block diagram" in my head.
If so, what to do about that? Something? Nothing?
It's fair to say that part of the purpose of this question is to learn something and another is to find solutions.
At first, the provider said that there had to be firewall ports open (and, obviously NOT forwarded to any particular IP). That is, the ports had to be opened incoming and outgoing.
Well, usually outgoing is open by default. So that would only be mentioned to CYA.
And, if outgoing is all that's needed then saying incoming is needed seems double CYA.
Right?
My hope is that no firewall ports need be specifically opened at all.
But, I started on this path by accepting what they specified and decided I would NOT run these things through our main firewall at all.
So, there will be a separate firewall as we have enough public IP addresses to accomodate.
And so, there has been a VLAN set up just to service the VOIP phones and to keep the firewall LANs separated.
I hope this much sounds like a reasonable approach.
If you're familiar with these phones (and I hope you are) then you'll know that the phones will accept a trunk line connection and "pass through" the main LAN / e.g. VLAN1 untagged to the computer on the desk. (This saves running a new cable to the desk assuming the computer is already cabled). And, the phone functions are supposed to run off a tagged VLAN / e.g. VLAN100 that's combined on the trunk.
All this seems fine so far. I'm a little uncomfortable with the phones being so integrally connected inside the network but it seems like accepted practice.
As they say, "the devil is in the details":
- I have connected the VOIP firewall/router/gateway with it's own LAN subnet to our main LAN switch on a VLAN100 untagged access port. This seems to work.
- I can connect a phone to a VLAN100UP access port on the main switch and it will work. I'm not sure I can say that about trunked ports on the main switch.
- There are other switches cascaded down using trunked connections.
- Most ports on those switches are trunked as well.
- Phones connected to those other trunked ports aren't working right. They are not identified as being on VLAN100 even though they are set up to do that. They don't get an IP address from the VOIP gateway.
- One hypothesis is that they will work an an Access, Untagged VLAN100 port and NOT on a trunked port. If true, that puts new requirements on the installation.
I've been told that the phones start out by connecting to VLAN1, get an IP address from the VLAN1 DHCP server (there *is no* DHCP service on VLAN1!!) and then switch over to VLAN100 and subsequently get an IP address from there.
This is a surprise that hasn't quite sunk in yet
Now I have two issues:
1) What shall I do to make these phones work since trunk lines are necessary to serve the computers.
a) One idea is to provide a DHCP server on VLAN1 but that's a big bandage for a little cut. Gee, we could talk about MAC-address assignments, etc. etc. just more admin.
b) Another idea is that accessing VLAN1 internal to the phones really shouldn't be necessary - but I don't know enough about these phones yet to be able to pursue that idea.
2) Should I be concerned about network security when the phone guy just casually mentions that VLAN1 is going to be used by these phones - even if briefly? I was getting used to the idea of them being a relatively dumb switch that would pass through VLAN1 to the adjacent computer and only be using VLAN100 internally - but this is something different altogether as I see it. That's the trouble with having a "functional block diagram" in my head.
If so, what to do about that? Something? Nothing?
It's fair to say that part of the purpose of this question is to learn something and another is to find solutions.
Change the provider if its enable to serve you basically its waste of time there are tons of voip out there its not even necessary to risk business critical process.
thanks
thanks
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
mattibut: Heh... I'm just the IT guy and not the owner. So *my* solutions will mostly be technical unless there's something truly objectionable. And, to your point, this could be one of those situations. Time will tell.
Going with a different supplier would be quite a leap. And, this supplier is at least cooperative and helpful.
noci:
- before the phone is configured (such as when it's new or has be fully reset) then it has no VLAN ID configured.
(I would be happy to configure the phones manually or by local download but haven't learned if that's possible yet.
In the best of worlds, I'd hard code the subnet).
- at that point it takes the native default untagged VLAN1 to reach out in order to be configured. That requires getting IP settings via the VLAN1 DHCP service.
- It downloads the configuration.
- then it likely reboots and loads the configuration that includes the VLAN100 info.
- then it operates using VLAN100 using the VLAN100 DHCP as intended.
So, I guess that *is* changing a VLAN ID somewhere, eh? I'd just not thought of it quite that way. Maybe "adding"?
I appreciate the discussion about ports. I believe that only SIP is in use and the "PBX" is off site.
I'm always prepared to learn new stuff but I'm getting to the point where the critical things have to come first.
Experimenting with VOIP isn't one of them but the ideas are interesting! Thanks for mentioning.
The port requirements have been stated:
80
443
5060
IN AND OUT.....
As before, I'm not worried about OUT as it's likely the default.
And, I imagine that most or all of the INCOMING are carrying port numbers in response to what came OUT - at least at the public/firewall level. Other ports may be buried inside for moving down to the target device/app.
This isn't the first time that I've been given spec's for opening ports IN and OUT..... some VPNs may still do need incoming port opened like 500, etc. but then this is more likely port forwarding than port opening, eh? I believe it's more prevalent to run a service on the inside to initiate communications and to "open" temporary ports as necessary.
Going with a different supplier would be quite a leap. And, this supplier is at least cooperative and helpful.
noci:
DHCP will never change a VLAN id anywhere....,I wouldn't have thought any different and I'm sorry if I gave the impression that I did. The sequence described to me is this:
- before the phone is configured (such as when it's new or has be fully reset) then it has no VLAN ID configured.
(I would be happy to configure the phones manually or by local download but haven't learned if that's possible yet.
In the best of worlds, I'd hard code the subnet).
- at that point it takes the native default untagged VLAN1 to reach out in order to be configured. That requires getting IP settings via the VLAN1 DHCP service.
- It downloads the configuration.
- then it likely reboots and loads the configuration that includes the VLAN100 info.
- then it operates using VLAN100 using the VLAN100 DHCP as intended.
So, I guess that *is* changing a VLAN ID somewhere, eh? I'd just not thought of it quite that way. Maybe "adding"?
I appreciate the discussion about ports. I believe that only SIP is in use and the "PBX" is off site.
I'm always prepared to learn new stuff but I'm getting to the point where the critical things have to come first.
Experimenting with VOIP isn't one of them but the ideas are interesting! Thanks for mentioning.
The port requirements have been stated:
80
443
5060
IN AND OUT.....
As before, I'm not worried about OUT as it's likely the default.
And, I imagine that most or all of the INCOMING are carrying port numbers in response to what came OUT - at least at the public/firewall level. Other ports may be buried inside for moving down to the target device/app.
This isn't the first time that I've been given spec's for opening ports IN and OUT..... some VPNs may still do need incoming port opened like 500, etc. but then this is more likely port forwarding than port opening, eh? I believe it's more prevalent to run a service on the inside to initiate communications and to "open" temporary ports as necessary.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Justin,
That's a great answer!
The redirection is new to me!
There is no DHCP server on the data network to provide redirection at present.
If there were a DHCP server on the data network, other than available IP addresses, I'm not sure I see the need for redirection IF the process will work anyway. I know the redirection looks neat but what would is normally the point?
I'm not challenging, just learning.
In this case, all of the switches are Cisco SG300-xx running at Layer 2.
It has never been my ambition to become this much of a phone expert and my expectation was that the VOIP provider would provide reasonable guidance for network integration. And, we got that. But, this connection to the data LAN came as a surprise. Likely the VOIP providers assumed data LAN DHCP. oops! But one has to be realistic.
I have considered programming the phones manually. I might hope that a "canned" approach on a laptop, with a single(?)
common phone configuration would be feasible in order to get a phone up and running on the VOIP VLAN directly. Then, even a caveman could do it and there could be a laptop at each site. Does that make sense? There aren't that many phones and I don't imagine that phones would need to be initialized that often would they? But "automatic" is surely better than this.
My initial objective was to keep the data LAN completely separate from the VOIP LAN.
Redirection would get closer to that goal.
That's a great answer!
The redirection is new to me!
There is no DHCP server on the data network to provide redirection at present.
If there were a DHCP server on the data network, other than available IP addresses, I'm not sure I see the need for redirection IF the process will work anyway. I know the redirection looks neat but what would is normally the point?
I'm not challenging, just learning.
In this case, all of the switches are Cisco SG300-xx running at Layer 2.
It has never been my ambition to become this much of a phone expert and my expectation was that the VOIP provider would provide reasonable guidance for network integration. And, we got that. But, this connection to the data LAN came as a surprise. Likely the VOIP providers assumed data LAN DHCP. oops! But one has to be realistic.
I have considered programming the phones manually. I might hope that a "canned" approach on a laptop, with a single(?)
common phone configuration would be feasible in order to get a phone up and running on the VOIP VLAN directly. Then, even a caveman could do it and there could be a laptop at each site. Does that make sense? There aren't that many phones and I don't imagine that phones would need to be initialized that often would they? But "automatic" is surely better than this.
My initial objective was to keep the data LAN completely separate from the VOIP LAN.
Redirection would get closer to that goal.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks folks!!
I don't see where our likely DHCP server on VLAN1 will do the redirect - but it may.
And, what I've been reading suggests that the redirect is to an FTP server which I don't have and would have to set up.
Setting it up isn't such a big deal but determining what to put there will be more.
My understanding was that as long as the (factory defaulted) phone has an IP address on VLAN1 temporarily, it would go to the public address of the telco server and get its configuration.
So redirection is yet another approach to this it appears.
So, my likely approach for comment:
Set up a "closed" DHCP server on VLAN1 (only leases reserved addresses).
Assign reserved IP addresses in this DHCP server to the phone MACs for those situations when it may be needed.
In the mean time, the phone guys have figured out how to preconfigure the phones so that this won't be needed.
So, the DHCP on VLAN1 will only be needed in case of a full reset / back to factory defaults.
I don't see where our likely DHCP server on VLAN1 will do the redirect - but it may.
And, what I've been reading suggests that the redirect is to an FTP server which I don't have and would have to set up.
Setting it up isn't such a big deal but determining what to put there will be more.
My understanding was that as long as the (factory defaulted) phone has an IP address on VLAN1 temporarily, it would go to the public address of the telco server and get its configuration.
So redirection is yet another approach to this it appears.
So, my likely approach for comment:
Set up a "closed" DHCP server on VLAN1 (only leases reserved addresses).
Assign reserved IP addresses in this DHCP server to the phone MACs for those situations when it may be needed.
In the mean time, the phone guys have figured out how to preconfigure the phones so that this won't be needed.
So, the DHCP on VLAN1 will only be needed in case of a full reset / back to factory defaults.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks! In the end, we had to adjust some of the SG300 switch settings to propagate the VLANs properly.
IF at all then 802.1x is used to gain access to a network (specific protocol to exchange authentication) and get a port configured. That will require a radius server talking to the switch.
After this optional step is done, then DHCP can try to negotiate an address in the assigned VLAN.
w.r.t. Firewall: (Assuming SIP) one port that is needed would be UDP 5060, possibly (5061..for SSL ) of TCP is used then 5060 is needed there.
SIP is only the signaling, you would also need RTP negotiated ports on for UDP. Mostly this can be setup on a PBX what the limits are.
(Mostly 2 ports / conversation and a few spare). That UDP range and SIP ports are needed for VOIP.