Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

MAS question 4

Status
Not open for further replies.

unclerico

IS-IT--Management
Jun 8, 2005
2,738
US
We're in the midst of our Mitel implementation and one of the products that we purchased was MAS. According to the VAR doing the install, I need to have a non NATed public IP on one NIC and a private IP on the second NIC. I really, really do not like the fact that if this server is compromised that an attacker would be able to have direct access into my network and would be able to bypass my IPS. I asked if I could place the NIC with the private IP in my DMZ and only open the necessary ports for communication into and out of my internal network. The consultant said that this cannot happen and that the private NIC needs to be on the same LAN segment as the 3300. Is this true??

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)
 
It would help if you told us what applications are running on the MAS. Teleworker is the sticking point.

Short answer is your consultant needs to bone up on his homework.

More specific answers are available when you provide more specific details.
Controller type and SW rev
MAS SW rev
MAS enabled Applications




*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
I teleworker, nupoint, and mobility are what we purchased. I'm not 100% sure on the SW rev of the controller, but it is a 3300. As for the MAS SW rev, I'm not sure of that either. Sorry for the lack of answers, but thanks for helping me out!!!

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)
 
Hello,

New here :)
I think you can have that server in server only mode with those apps running plus a seperate MBG in the DMZ controlled by the MBG on the MAS. So what you are asking for can be done.
Someone correct me if i am wrong.
 
I am going to assume that you have current software for the MAS and Teleworker.

If this is the case, and you want to avoid using the MAS as its own firewall then the documentation indicates you require 2 servers. 1 for the MAS and 1 for the MBG (Mitel Border Gateway, aka-Teleworker)

From the documentation:

For Industry Standard Server deployed on LAN
with a Mitel Border Gateway (MBG) in the
Demilitarized Zone (DMZ).

- Remote Teleworker users connect to the
thh ltd MAS server through MBG server located
in the DMZ.
- MAS Server (master) is clustered with
the MBG server (slave) allowing you to
manage Teleworker services from server
manager.
- Both MAS server and MBG server require
Teleworker blade to be installed.


The scenario that your consultant has recommended only requires 1 server:

Industry Standard Server deployed on
Network Edge with firewall capability.
-Network Edge deployment requires two
Ethernet adaptors:
One adapter is configured as "Local"
for connection to the local network,
Other adapter is configured as "WAN"
for connection to the Internet.
The WAN network adapter has a
publicly-routable IP address;
accessible to both the Internet and the
internal network.
- Preferred deployment is MAS server used
in conjunction with the corporate firewall.
MAS server is configured as parallel
firewall protecting telephony applications.
- Some AWC data must be routed through
Firewall or Router. AWC web collaboration
client requires a second IP address
assigned and configured.


*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
Wow, talk about an indepth answer! Thanks a lot. I'll bring this up with the consultant this afternoon. As an aside, what deployment scenario would you recommend?

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)
 
Teleworker Solution Installation notes

The following items are designed to provide some assistance in terms of successfully deploying a Teleworker Solution server.

1) Be sure that the ethernet port(s), to which a Teleworker Server is being connected, are able to provide Full Duplex connections. Some DSL modems do provide L2 switched ports that will only allow for a 10baseT Half-Duplex connection.

2) When deploying a Teleworker Solution server as a gateway, the external interface of the server *MUST* have a publicly routable IP address assigned directly to it. That is, the server should not be residing behind a NAT device.

3) When deploying the server in a firewall's DMZ, the server should be deployed in server-only mode. In this scenario, a DMZ is defined as having the following characteristics:
a) Consists of a physically distinct interface on the firewall
b) Consists of a logical network that is separate from the LAN
c) Requires unique firewall rules in order to interact with the LAN
d) Is directly accessible from both the Internet and the LAN
e) Commonly provides NAT to the devices residing within.

4) When deploying the server in a firewall's DMZ, the firewall should NAT the publicly routable IP address of the server to the server's actual DMZ IP address (a private IP address). All voice traffic to, and from, remote sets will be directed to the publicly routable IP address of the server, rather than its private DMZ IP address. By default, most firewalls will not handle this behaviour, as the existing NAT rule for the Teleworker server NAT from the WAN interface to the DMZ interface; a NAT rule, or alias (Cisco specific) would be required on the LAN interface to translate the publicly routable IP address of the Teleworker server to the correct DMZ IP address.

5) When deploying a Teleworker Solution server as a gateway in a subnetted environment, any network that is to be able to access the server's facilities must be added to the server's Local Networks. When adding entries to the Local Networks section, please keep in mind that the router entry must refer to a router IP on the server's native network.

6) When deploying the Teleworker Solution in an environment that consists of multiple ICPs and/or phone networks, the Teleworker server *MUST* have a direct route to/from any voice device from/to which a call may be placed. i.e. A Teleworker server, in a DMZ, in an environment with clustered 3300 ICPs requires that the firewall rules allow it to speak to all the ICPs in the cluster, along with their respective IP sets, in order for all calls to have 2-way audio.

7) When deploying a Teleworker Solution server as a gateway in a VLAN environment, it is best to deploy the server on the voice VLAN because it is there to provide a virtual extension to the voice network. The Teleworker itself is not a VLAN aware device, so it should be connected to the VLAN router/switch using an untagged port. In the case where the server is to be accessible by multiple VLANs, the VLAN switch/router port must be untagged for each additional VLAN, in most cases this means configuring the switch port as a trunk port.

8) When deploying a Teleworker Solution server, you may have problems if the phone network's gateways do not align themselves towards the teleworker server. That is,
a) When deploying the server as an internet gateway, it should be the gateway for the phone network.
b) When deploying the server in a firewall's DMZ, the firewall should be the gateway for the phone network.
 
What you should have been recommended is the 2 server appraoach

The MBG (Teleworker) sits on a server in the DMZ and then the MAS on a seperate server sits on the LAN.

They are then clustered so can be managed from the MAS. The MBG then comes with a Web Proxy so you can get access to the apps through the MBG in your DMZ. That is th method for wanting all apps but with MBG in the DMZ.

What the consultant told you isn;t all untrue. You can have the MAS (including MBG) in server-gateway mode which indeed does have 2 X NICS, one WAN one LAN. The MAS has it's own stateful firewall so doesn;t open up to your LAN.

Both options work fie, it's down to how the customer feels most comfortable.
 
unclerico:

My recommendation would be based on your capabilities/confidence level of setting up the DMZ. Also your capability of providing a second server is a factor.

The single server and gateway scenario is by far the simplest to implement. Start to finish I can do one of these in a little over an hour. I trust Mitel's security as a firewall but I understand if you do not.

With the DMZ, the implementation requires a lot more configuration on the network. I have yet to have a DMZ deployment go well. Also, most questions on this forum invove issues with DMZ deployment.

The choice is yours, this is what your consultant should have said. Informed decisions are better than my way or the highway.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
yeah, kwb, exactly what i was saying

It's all about choice! ::) We like choice!
 
Fantastic replies guys!!!

The reason I am looking for deployment in my DMZ is because, like I said, having the MAS bridge my public network and my private network will bypass my permiter security (IPS and Netflow) and should the host itself be compromised it'll be a nightmare to see. It adds yet another entry point into the network and since we are overextended as it is in terms of staff, one less place to keep an eye on the better. I'd love to have a simple deployment of the one server, but it really makes me nervous.

kwb, i wish i could give you more than one star. to mitelmatt and loopylou, stars for you...haha, i'm a poet and i didn't even know it!!! I'm sure I'll be posting a lot in this forum as I come up to speed on all of the components that go into a functioning Mitel system.

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)
 
One final thought would be is security is a big issue you can use the seperate Web Proxy product in the DMZ and hide the MBG on your network. I believe it adds a bit more security in that you restrict traffic from it to the MBG and only the MBG. Anyways good luck.
 
The issue here is that most Mitel resellers are "phone people". They are not "network people". Our business has a phone and network component to it and we setup all new MAS servers that need the teleworker solution on a DMZ. Circumventing a company firewall is an absolute no no in the data world. I don't know why people think it is acceptable in the phone world. This may take 2 hours as opposed to one hour but it is worth the extra security. The Mitel firewall is an open source Linux application. While it provides decent security, I would not trust it compared to a Cisco ASA firewall or other such device.

I would setup the MAS server with a single NIC on the private voice network (which should be a different VLAN and IP subnet from the data network with a layer 3 switch routing and doing QOS). You can then setup a second server with a single NIC running Mitel MBG software in the DMZ. This "second server" does not need to be anything great hardware wise. It can be an old computer or cheap server. technically, it needs to be on the Mitel approved hardware list but we have used old computers and never had an issue. Every business has old computers lying around. If the old computer dies, this is very easy to restore to a differnt old computer. Less then a 1 hour process.

You can even install the Mitel Web proxy on the MBG server in the DMZ and use it for the Mitel UC Mobile client. This is an additional app people can run on their cell phones to help tie them in better with UC Mobile. You do need to buy an SSL certificate to do this (very cheap).

Again, the issue is that most Mitel partners need to brush up on the data side of things. Installing a second server in a DMZ is not hard at all.
 
loopy, that's what direction we are going to go in. i had an impromptu meeting with the contractors and my CIO and voiced my concerns. the CIO definitely wants the proxy product in place as he was not aware of the potential security risks (neither was i until they showed up onsite telling me how they wanted to install it).

sterling, believe me as a CCNP and almost CCSP i think i screamed like a third grade school girl when i heard how they wanted to do things lol. as i said to loopy, the proxy config is how we will proceed. the consultant wasn't too happy to hear that, but it's my network :)

Thanks again.

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)
 
Stirling5005: I disagree with a minor part of your statement. Specifically:
the issue is that most Mitel partners need to brush up on the data side of things
It is not a matter of brushing up, at least for me. I understand both ways and I agree entirely that the Firewall on the Linux box will not meet the needs of some, maybe even most, customers. The fact is, in some cases, it will exceed what they currently have in place and as such it will meet their needs entirely.

Additionally, the DMZ by necessity, is entirely the domain of the customer and their support team. I can provide documentation, direction, and assistance but I've yet to encounter a customer that would allow me to configure their DMZ settings. If the customer and their support team is incapable of getting it to work, how should they expect me to?

It's not a matter of training, its a matter of access.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
Sterling5005

The fact that you are installing Mitel apps on "used old computers" is slightly disconcerting and would leave the customer in a position of being unsupported if problems arise.
I would never in a million years in a production environment install apps on old pc's. It sounds like you are deploying MAS, MBG in small scale environments. I called never guarantee the customer a 1 hour turn around if there pc was to fail. It sounds to me that you don't understand the voice side of the business, especially the legalities of downtime.

Configuring a DMZ on a firewall whether you are a phone or a network guy is not brain surgery. We provide detailed engineering guidelines to the customer and let them decide on the best course of action. Frankly, most of the network engineers I deal with have no idea about voice protocols, in particular SIP and take weeks to setup the firewall correctly.

These are the exact people that have CCNP, CCSP in there signatures.(lots of pretenders out there!)

Doing things on the cheap saves the customer money but lands you in hot water when things go bad.

Knowledge is power, thats why we share!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top