Sie sind auf Seite 1von 32

Configuring NOE VOIP

Alcatel-Lucent Security Products Configuration Example Series

January 2010

Software Version 9.4


Preparing For Your Configuration
• This configuration assistant assumes that you already
have a running VOIP application and would like to
secure it.
• Or that you are comfortable configuring and testing
your VOIP application and now want directions in
securing the application.
• This configuration example will also assume that you
are comfortable with basic Brick and ALSMS setup.
• Other configuration examples and documentation to
assist in the setup for the Bricks and ALSMS can be
found here:
http://aww.ind.alcatel.com/products/?family=Brick&product=VPN
FirewallBrick&page=presales_docs

2
About the NOE Protocol
• The primary components that you will use in your
NOE VOIP application are:
•Media Gateways (MGW)
•Call Servers (CS)
•Handsets (Phones)
•Brick Firewalls

3
About the NOE Protocol
• The primary protocols that are used between these
devices are:
• UA/NOE- New Office Environment (Phone <-> CS)
• IP Link (MGW <-> CS)
• ABC- Alcatel-Lucent Business Communications
(CS <-> CS)
• These protocols have layer 7 commands used in
them.
• Therefore you will need to apply application filters
to inspect and filter those commands at layer 7.

4
About the NOE Protocol
• Notice that there are
many other common
protocols used in
this application as
well.
• Along the way
Bandwidth controls
need to be applied
per call
• NAT may be needed
• And you will want to
secure your network
by opening dynamic
pinholes per call

5
Configuring The Brick for NOE
• Taking the complexity of this type of configuration into account
Alcatel-Lucent has created pre-configured tools that will make
the process of securing your VOIP application relatively simple.
• A set of pre-defined Brick zone rulesets are provided with the
SMS application when it is installed to make it easier to
provision the Brick to monitor and protect call and data traffic
in a VoIP network. Each pre-defined Brick zone ruleset is pre-
configured with the required rules and other rule components
(pre-defined host groups, service groups, application filters)
which allow the Brick to secure the media and call control
sessions at a specific location in the VoIP network.

6
Configuring The Brick for NOE
• All required settings and parameters are pre-provisioned within
these Brick zone ruleset templates for VoIP traffic.
• All that is required is for you to edit the host group templates
called within the rules of the ruleset and add the IP addresses
of the equipment (IP phones, call servers and MGWs…) from
each of the sites (Main, Branch, Backup, Remote).
• Once you have populated the host groups you will insert your
Bricks into your working VOIP network, basically completing
your physical layer and securing your VOIP application.
• The following slides will show you a step by step approach.

7
Preparing to Configure NOE Protocol

• Start out by making yourself a good network diagram of the


VoIP network.
• Include IP Addresses of each device, you’ll need them.

8
Configuring the NOE Protocol
• Turn on the added NOE
features in your ALSMS.
• Right click on your
“System” folder or the
folder where your devices
will be.
• Select “Create NOE
Template”

9
Configuring the NOE Protocol
• Select “Yes”
• This will populate sub
folders in your:
•Brick Zone Rulesets
•Host Groups
•Service Groups
•Application Filters

10
Configuring the NOE Protocol
• Configure and Activate your Bricks so that they are
communicating with the ALSMS.
• Refer to the configuration example named
“Configuring and Activating a Brick” if needed for
assistance. It can be found at:
http://aww.ind.alcatel.com/products/?family=Brick&product=VPN
FirewallBrick&page=presales_docs

11
Configuring the NOE Protocol (Sample Network)
• In our example we will create a simple network with a
Headquarters site and one remote site.
• Our Call Server and MGW will both be at the HQ site.
• We will encrypt and tunnel the VOIP traffic between our two
sites.
• The network diagram, including IP Addresses on the following
slide will help.
• Based on that diagram we will fill in our Host Groups, Apply our
rule sets and create our LAN-LAN tunnel.

12
Configuring the NOE Protocol (Sample Network)
Headquarters Remote Site
192.168.1.x/24 192.168.2.x/24
ALSMS
10.0.0.30

Media GW
192.168.1.20

OXE CS <192.168.1.50/24 >192.168.2.50/24 NOE Phone


192.168.1.30 >10.0.0.10/24
10.0.0.x/24 <10.0.0.20/24 192.168.2.100
Ext. 4000

NOE Phone
192.168.1.100 * Tested and proven this scenario can pass VOIP in the clear and
through a LAN to LAN tunnel.
Ext. 3001
13
Configuring the NOE Protocol (Host Groups)
• Fill in Host Groups for:
• NOE_Call_Server_Main
• NOE_TFTP_Server_Main (in our case this is the CS address)
• NOE_Phones_Branch_Office
• NOE_Phones_Main
• NOE_GA_IPs_Main (*one of these two or
NOE_MGWs_Headquarters must be
• NOE_GD_IPs_Main filled in with the MGW address)

• * Note that other Host Groups may apply if for instance you
have a Presentation Server, Regional Offices, multiple Call
Servers or MGW’s and so on. Refer to the Policy Guide for
more complex configurations.

14
Configuring the NOE Protocol (Rule Sets)
• Next lets add rule sets.
• Our HQ Brick Policies tab should look like this.

• Our Branch office Brick Policies tab should look like this.

15
Configuring the NOE Protocol (Tunnel)
• Then create your tunnel between the two sites using the LAN-
LAN Tunnel Viewer.

• Note in our case we assigned the TEP’s (Tunnel Endpoints) of


10.0.0.11 and 10.0.0.21 when we assigned the rule sets on the
previous slide.
• At the LAN-LAN Tunnel Viewer right click and select New LAN-
LAN Tunnel to create your tunnel.

16
Configuring the NOE Protocol (conclusion)
• Note that you filled in the appropriate host groups and applied the
appropriate rulesets which were preconfigured for you. Those same
rule sets are automatically applying the appropriate application filters
for you which will filter the NOE protocol at layer seven therefore
securing your VOIP traffic as well as your VOIP signaling.
• The Brick is now dynamically opening a closing the negotiated VOIP
ports for each phone call, which is necessary to allow VOIP calls yet
also secure the rest of the network.
• Other things that you probably want to consider that the Bricks can do
for you are:
• Bandwidth management, establishing guarantees to each
specific VOIP Session
• Redundancy- Bricks can be configured as redundant pairs with
rapid failover ensuring that you don’t drop any sessions or VOIP
calls in the event of a failover.

• Now you’re ready to test your interoffice VOIP.

17
Configuring NOE VOIP Behind Existing
Firewalls.

Alcatel-Lucent Security Products Configuration Example Series

January 2010

Software Version 9.4

Lucent Technologies – Proprietary


18 Use pursuant to company instruction
Configuring the NOE Protocol (3rd party testing)
• Quite often the VOIP application is installed into an existing
network.
• The network most likely has existing firewalls.
• The existing firewalls may or may not support VOIP protocols
and secure them to a satisfactory level.
• No third party firewalls on the market support the Omni-PCX
protocols, only Bricks
• In these cases you will be installing Bricks with the primary
purpose of securing the VOIP protocols and they will sit behind
the existing firewall on a subnet assigned for VOIP.
• The following slides document testing done passing NOE
protocols between Bricks that were sitting behind third party
firewalls from Juniper and Fortinet.

19
Juniper Testing.

Alcatel-Lucent Security Products Configuration Example Series

Lucent Technologies – Proprietary


20 Use pursuant to company instruction
Configuring the NOE Protocol (3rd party testing)
Headquarters Remote Site
192.168.1.x/24 192.168.2.x/24

Media GW 3rd party firewall 3rd party firewall


192.168.1.20 Juniper SRX100 Juniper SRX100

OXE CS
ALU Brick ALU Brick NOE Phone
192.168.1.30
172.16.0.0/30 192.168.2.100

NOE Phone
•Testing done with 3rd party firewalls from both Juniper
192.168.1.100
and Fortinet.

21
Configuring the NOE Protocol (3rd party testing)
• With Juniper SRX100 our follow up testing included tightening
up the firewalls with host and service groups across the trusted
and trusted networks, as follows.
• The trusted networks were the LAN networks on both sides
(192.168.1.0/24 and 192.168.2.0/24).
• The un-trusted network was the WAN network
(172.16.0.0/30).

22
Samples of Juniper configuration

• Screen shots after


tightening up the Juniper
firewalls to allow VOIP
across trusted networks
using specific protocols
created in a service
group.

23
Juniper Testing Conclusions
• VOIP signaling and RTP Traffic was passed through the network
from the HQ subnet 192.168.1.0/24 through the HQ Brick
where it was filtered at layer seven through the Junipers and
WAN to the Branch office Brick for more filtering then onto the
branch office VOIP Subnet 192.168.2.0/24.
• Traffic was passed in the clear at first through the Junipers.
• Later we applied the VPN rule sets and passed tunneled traffic
through the Junipers.
• At no time with proper configuration did the Juniper boxes
interfere in any way with the passing of the VOIP traffic
between the Bricks.
• The Juniper boxes are not capable of filtering the ALU VOIP
protocols.
• Installing VOIP networks using Bricks to secure the VOIP
protocols on a subnet behind an existing Juniper firewall tested
to be 100% fine.

24
Fortinet Testing.

Alcatel-Lucent Security Products Configuration Example Series

Lucent Technologies – Proprietary


25 Use pursuant to company instruction
Configuring the NOE Protocol (3rd party testing)
Headquarters Remote Site
192.168.1.x/24 192.168.2.x/24

Media GW 3rd party firewall


192.168.1.20 Forgate-50B

OXE CS
ALU Brick ALU Brick NOE Phone
192.168.1.30
10.0.0.0/24 192.168.2.100

NOE Phone
•Testing done with 3rd party firewalls from both Juniper
192.168.1.100
and Fortinet.

26
Configuring the NOE Protocol (Fortinet 50B testing)
• For the initial Fortinet test I physically installed the Fortinet
50B into the network as shown on the previous slide.
• In this test we assume that the HQ site had an existing firewall
(Fortigate) and that the Brick would be the only firewall at the
remote site.
• As per the network diagram I had local interface #1 connected
to the HQ Brick directly and WAN #1 connected to the switch
that is simulating the internet on the 10.0.0.0/24 network.

27
Configuring the NOE Protocol (Fortinet 50B testing)
• By putting the Fortigate in Layer 2 Transparent mode I was able
to bring the VOIP network up and make calls.
• This was a simple test with just one rule set applied per
interface, that was configured to pass all traffic.
• The Bricks are tunneling the VOIP Signaling and the RTP
traffic through the Fortigate.

28
Configuring the NOE Protocol (Fortinet 50B testing)
• Immediately after applying the rule set on the Fortigate 50B the
Branch Brick and LAN-LAN Tunnel came back up.

29
Configuring the NOE Protocol (Fortinet 50B testing)
• To tighten up the Fortigate firewall I created host groups (aka
address groups).
• Since the Bricks are tunneling all of the information across the
WAN and through the Fortinet I didn’t have to do much with
services or service groups. The only services that will be passing
are Brick to SMS services (<>) and the IP Sec tunnel.
• Traffic and phone calls are still passing successfully with the host
groups applied.

30
Fortinet Testing Conclusions
• VOIP signaling and RTP Traffic was passed through the network
from the HQ subnet 192.168.1.0/24 through the HQ Brick
where it was filtered at layer seven through the Fortigate 50B
and WAN to the Branch office Brick for more filtering then onto
the branch office VOIP Subnet 192.168.2.0/24.
• Traffic was tunneled through the Fortigate box.
• Later I tightened up the rules from a simple pass all to a
directional host group trusted sites scenario.
• At no time with proper configuration did the Fortinet box
interfere in any way with the passing of the VOIP traffic
between the Bricks.
• The Fortinet boxes are not capable of filtering the ALU VOIP
protocols.
• Installing VOIP networks using Bricks to secure the VOIP
protocols on a subnet behind an existing Fortinet firewall
tested to be 100% fine.
31
ALSMS NOE/VoIP Configuration Example

• For more detailed information on configuring NOE VOIP go to


section 1 of the Policy Guide “Brick Zone Ruleset Templates
Provided with the SMS Application for VoIP/NOE Traffic”. Also
see appendix E in the Policy Guide “Configuring the Brick for
VoIP/NOE Traffic Using Pre-Defined SMS Templates”.
• From the ALSMS you can access the manuals by clicking-
Help>On Line Product Manuals>(choose Policy Guide)

32