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=VPNFirewallBrick&page=presales_docs

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

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.

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

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.

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.

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.

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”

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

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=VPNFirewallBrick&page=presales_docs

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.

Configuring the NOE Protocol (Sample Network) Headquarters 192.168.1.x/24 Remote Site 192.168.2.x/24 ALSMS 10.0.0.30 Media GW 192.168.1.20 OXE CS 192.168.1.30 <192.168.1.50/24 >10.0.0.10/24 >192.168.2.50/24 <10.0.0.20/24 NOE Phone 192.168.2.100 Ext. 4000 10.0.0.x/24 NOE Phone 192.168.1.100 Ext. 3001 * Tested and proven this scenario can pass VOIP in the clear and through a LAN to LAN tunnel.

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 NOE_GD_IPs_Main * 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. (*one of these two or NOE_MGWs_Headquarters must be filled in with the MGW address)

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.

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.

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.

Configuring NOE VOIP Behind Existing Firewalls. Alcatel-Lucent Security Products Configuration Example Series January 2010 Software Version 9.4 Lucent Technologies – Proprietary 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.

Alcatel-Lucent Security Products Configuration Example Series Juniper Testing. Alcatel-Lucent Security Products Configuration Example Series Lucent Technologies – Proprietary Use pursuant to company instruction

Configuring the NOE Protocol (3rd party testing) Headquarters 192.168.1.x/24 Remote Site 192.168.2.x/24 Media GW 192.168.1.20 3rd party firewall Juniper SRX100 3rd party firewall Juniper SRX100 OXE CS 192.168.1.30 ALU Brick ALU Brick NOE Phone 192.168.2.100 172.16.0.0/30 NOE Phone 192.168.1.100 Testing done with 3rd party firewalls from both Juniper and Fortinet.

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).

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.

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.

Alcatel-Lucent Security Products Configuration Example Series Fortinet Testing. Alcatel-Lucent Security Products Configuration Example Series Lucent Technologies – Proprietary Use pursuant to company instruction

Configuring the NOE Protocol (3rd party testing) Headquarters 192.168.1.x/24 Remote Site 192.168.2.x/24 Media GW 192.168.1.20 3rd party firewall Forgate-50B OXE CS 192.168.1.30 ALU Brick ALU Brick NOE Phone 192.168.2.100 10.0.0.0/24 NOE Phone 192.168.1.100 Testing done with 3rd party firewalls from both Juniper and Fortinet.

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.

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.

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.

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.

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.

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)