Table of Contents
X505 CONFIGURATION MULTICAST CONFIG, AS USED FOR MULTISITE NBX
Introduction
This deployment scenario builds on the simple site-to-site IPSec link site for your X505. Through the instructions, you can configure dynamic routing (RIP) and multicast over a site-to-site tunnel.
In order to run multicast and dynamic routing over a tunnel, the X505 supports Generic Route Encapsulation (GRE). This protocol embeds the intended payload within the GRE payload for transfer. The link made between two end points is called a GRE Tunnel.
The X505 supports the use of GRE over IPSec (GRE/IPSec) allowing GRE tunnels to be established between two end points with the data encrypted within an IPSec tunnel.
In the configuration steps that follow, the two units are known as “X505_1” and “X505_2”. These names represent the X505 units for Site 1 and Site 2 respectively. There are LANs on each side where client and server PCs can be positioned. The test positions the units back-to-back but any such solution is ok.
The basic steps in the use case show the solution being configured in stages with on-going testing during the process:
- Establish basic connectivity between the two units (not detailed in this document). For this step, set up the virtual interfaces, DHCP server for the clients, and the policies to allow PING between the two X505 devices. For details, see the X Series Deployment Guide.
- Establish IPSec tunnel. This is a main-mode tunnel with transport mode enabled and 3DES encryption.
- Convert the IPSec tunnel to have GRE/IPSec.
- Enable multicast and RIP routing.
- Demonstrate the multicast stream running.
NBX Phones Configuration
When configuring for NBX phones, you should configure the following setting:
- Option 184 needs to be configured on the remote X505.
As available throughout the document, further information is listed for NBX configurations.
Establish an IPSec Tunnel
Assuming basic connectivity between the two units, the following steps detail the configuration of an IPSec tunnel.
Step 1: Setup the IPSec parameters required for local ID. Because the tunnel you will establish is a main mode tunnel, this is not strictly necessary. You should also perform the setup on the peer X505 unit.
X505_2# conf t vpn ike local-id email site2@3com.com X505_2# conf t vpn ike local-id domain site2
Use the existing (default) IKE proposal 3DES-SHA1-PSK on each device. The following is the output of X505_2:
X505_2# show conf vpn ike vpn ike local-id email site2@3com.com vpn ike local-id domain site2 vpn ike add 3DES-SHA1-PSK vpn ike proposal 3DES-SHA1-PSK phase1-encryption 3des-cbc vpn ike proposal 3DES-SHA1-PSK phase1-integrity sha1 vpn ike proposal 3DES-SHA1-PSK phase1-dh-group 2 vpn ike proposal 3DES-SHA1-PSK phase1-lifetime 28800 vpn ike proposal 3DES-SHA1-PSK auth-type psk vpn ike proposal 3DES-SHA1-PSK aggressive-mode disable vpn ike proposal 3DES-SHA1-PSK local-id-type ip vpn ike proposal 3DES-SHA1-PSK peer-id-type ip vpn ike proposal 3DES-SHA1-PSK ca-cert ANY vpn ike proposal 3DES-SHA1-PSK nat-t disable vpn ike proposal 3DES-SHA1-PSK dpd enable vpn ike proposal 3DES-SHA1-PSK auto-connect disable vpn ike proposal 3DES-SHA1-PSK tight-phase2-control enable vpn ike proposal 3DES-SHA1-PSK phase2-encryption 3des-cbc vpn ike proposal 3DES-SHA1-PSK phase2-integrity esp-sha1-hmac vpn ike proposal 3DES-SHA1-PSK phase2-lifetime 3600 vpn ike proposal 3DES-SHA1-PSK pfs disable vpn ike proposal 3DES-SHA1-PSK phase2-dh-group 2
Step 2: Define the Security Association and tie it to the IKE proposal. Use a shared-secret for authentication.
Note: The peer IP address is 10.0.0.1
X505_2# conf t vpn ipsec add site1_sa X505_2# conf t vpn ipsec sa site1_sa key ike proposal 3DES-SHA1-PSK shared-secret testtest X505_2# conf t vpn ipsec sa site1_sa transport enable X505_2# conf t vpn ipsec sa site1_sa peer 10.0.0.1 X505_2# conf t vpn ipsec sa site1_sa enable
Step 3: Enable IPSec:
X505_2# conf t vpn ipsec enable
Step 4: Define the Security Association to X505_1.
Note: The peer IP address will be 10.0.0.2.
X505_1# conf t vpn ipsec add site2_sa X505_1# conf t vpn ipsec sa site2_sa key ike proposal 3DES-SHA1-PSK shared-secret testtest X505_1# conf t vpn ipsec sa site2_sa transport enable X505_1# conf t vpn ipsec sa site2_sa peer 10.0.0.2 X505_1# conf t vpn ipsec sa site2_sa enable
Step 5: Finally enable IPSec to X505_1:
X505_1# conf t vpn ipsec enable
You should now be able to establish the tunnel. This can be done from the consoles of the X505 units by PING to the peer WAN ip address. The X505 brings up the IPSec tunnel as a more specific route to the peer device than the normal WAN link. As shown below, before the PING starts, the tunnel is shown as “Idle”. Once the PING begins, the first few packets cause the tunnel to form. You can see this change from the packet loss statistic below displaying 42% packet loss. This figure demonstrates that the first 3 packets were used to establish the tunnel.
X505_2# show vpn ipsec
Name Peer Local ID Peer ID Status
---------- --------------- ----------------- ----------------- ------------
site1_sa 10.0.0.1 10.0.0.2 10.0.0.1 Phase 1 Idle
10.0.0.2 - 10.0.0.1 - Phase 2 Idle
10.0.0.2 10.0.0.1
X505_2# ping 10.0.0.1
64 bytes from 10.0.0.1: icmp_seq=3. time=0. ms
64 bytes from 10.0.0.1: icmp_seq=4. time=0. ms
64 bytes from 10.0.0.1: icmp_seq=5. time=0. ms
64 bytes from 10.0.0.1: icmp_seq=6. time=0. ms
----10.0.0.1 PING Statistics----
7 packets transmitted, 4 packets received, 42 percent packet loss
round-trip (ms) min/avg/max = 0/0/0
X505_2# show vpn ipsec
Name Peer Local ID Peer ID Status
---------- --------------- ----------------- ----------------- ------------
site1_sa 10.0.0.1 10.0.0.2 10.0.0.1 Phase 1 Up
10.0.0.2 - 10.0.0.1 - Phase 2 Up
10.0.0.2 10.0.0.1
X505_2#
Establish a GRE/IPSec Tunnel
After establishing IPSec connectivity, you can establish a GRE/IPSec tunnel using the existing Security Association. This will allow us to run the routing protocols over the tunnel.
- Step 1: Create a GRE virtual interface to the peer WAN interface and assign the Security Association to it. You can select the local IP address to set in the VPN zone.
Note: You must associate the Security Association with the GRE tunnel before setting the remote tunnel endpoint. Otherwise, you will receive the following error:
X505_2# conf t interface virtual add 3 gre X505_2# conf t interface virtual gre 3 local-ip 192.168.3.2 X505_2# conf t interface virtual gre 3 remote-endpoint-ip 10.0.0.1 Error: Remote IP used by Security Association. Cannot assign to Unsecured GRE. X505_2# conf t interface virtual gre 3 sa site1_sa X505_2# conf t interface virtual gre 3 remote-endpoint-ip 10.0.0.1 X505_2# conf t interface virtual gre 3 peer-ip 192.168.3.1 X505_2# conf t interface virtual gre 3 zone add VPN
Step 2: Enter this setting on the X505_1, but specifying the other peer.
Note: The choice of local IP is an end point IP address that you can use for routing. Set the tunnel to terminate in the VPN zone.
X505_1# conf t interface virtual add 3 gre X505_1# conf t interface virtual gre 3 local-ip 192.168.3.1 X505_1# conf t interface virtual gre 3 sa site2_sa X505_1# conf t interface virtual gre 3 remote-endpoint-ip 10.0.0.2 X505_1# conf t interface virtual gre 3 peer-ip 192.168.3.2 X505_1# conf t interface virtual gre 3 zone add VPN
Step 3: With the GRE tunnel terminated in the VPN zone, define policy rules allowing the LAN zone to/from the VPN zone to allow traffic access into the tunnel. You can be specific for certain protocols; this example allows everything.
Note: You can also define an IPS segment between the LAN and VPN zones to check the traffic. This configuration change is needed on both sides:
X505_1# conf t policy rule update 11 allow LAN VPN ANY X505_1# conf t policy rule move 11 before 8 X505_1# show policy rules ID Action Source Destination Service En. 1 allow LAN WAN ANY X 2 allow LAN this-device sms-conf.. X 3 allow LAN this-device icmp-ping X 4 allow LAN this-device secure-m.. X 5 allow LAN this-device dhcp-ser.. X 6 allow LAN this-device dns X 7 allow ANY this-device vpn-prot.. X 11 allow LAN VPN ANY X 8 allow WAN this-device sms-conf.. 9 allow this-device ANY ANY X 10 deny ANY ANY ANY X
Pinging IP Addresses
At this point, you cannot ping the 192.168.3.x addresses from the appropriate peer to prove the GRE tunnel is up. Unfortunately, GRE virtual interface addresses (local-ip) cannot be pinged. To ping addresses, you need to either use clients on the LAN as targets or the target X505’s LAN interface IP address. To setup this environment, you must setup the routes needed for the configuration scenario between the GRE tunnel and the LAN zones on each X505.
Step 3: Setup a static route on each device such that the local X505 knows how to get to the remote LAN. The static route is therefore defined for the remote LAN zone, and set to go via the local GRE endpoint. After configuration, you can enable RIP protocols to avoid the need for static routes.
X505_2# show interface virtual
Id Type Zones Mode IP Address Subnet Mask State
1 internal LAN static 192.168.2.254 255.255.255.0 Up
VPN
2 external WAN static 10.0.0.2 255.255.255.0 Up
3 gre VPN static 192.168.3.2 Up
X505_2# conf t routing static-route add 192.168.1.0 netmask 255.255.255.0 gw 192.168.3.2
Perform the same on the other X505:
X505_1# show interface virtual
Id Type Zones Mode IP Address Subnet Mask State
1 internal LAN static 192.168.1.254 255.255.255.0 Up
VPN
2 external WAN static 10.0.0.1 255.255.255.0 Up
3 gre VPN static 192.168.3.1 Up
X505_1# conf t routing static-route add 192.168.2.0 netmask 255.255.255.0 gw 192.168.3.1
Step 2: Define some policy rules on each device. This is because we have setup the GRE tunnel to terminate in the VPN zone. Doing this allows both the firewall and IPS to scan the traffic coming in over the GRE/IPSec tunnel. To ensure the GRE tunnel is passing the ping test traffic, you can also disable the policy rule that would have allowed PING to come in from the WAN zone. You must commit these changes to both X505 devices.
X505_2# conf t policy rule update 11 allow LAN VPN ANY X505_2# conf t policy rule move 11 before 8 X505_2# conf t policy rule update 12 allow VPN ANY ANY X505_2# conf t policy rule move 12 before 8 X505_2# show policy rule ID Action Source Destination Service En. 1 allow LAN WAN ANY X 2 allow LAN this-device sms-conf.. X 3 allow LAN this-device icmp-ping X 4 allow LAN this-device secure-m.. X 5 allow LAN this-device dhcp-ser.. X 6 allow LAN this-device dns X 7 allow ANY this-device vpn-prot.. X 11 allow LAN VPN ANY X 12 allow VPN ANY ANY X 8 allow WAN this-device sms-conf.. 9 allow this-device ANY ANY X 10 deny ANY ANY ANY X
Step 3: With the policy rules on both devices and the routing are set, you can ping the LAN interface of the GRE peer from the other X505 unit:
X505_1# ping 192.168.2.254 64 bytes from 192.168.2.254: icmp_seq=0. time=0. ms 64 bytes from 192.168.2.254: icmp_seq=1. time=0. ms 64 bytes from 192.168.2.254: icmp_seq=2. time=0. ms 64 bytes from 192.168.2.254: icmp_seq=3. time=0. ms ----192.168.2.254 PING Statistics---- 4 packets transmitted, 4 packets received, 0 percent packet loss round-trip (ms) min/avg/max = 0/0/0 X505_1#
And on the other unit:
X505_2# ping 192.168.1.254 64 bytes from 192.168.1.254: icmp_seq=0. time=0. ms 64 bytes from 192.168.1.254: icmp_seq=1. time=0. ms 64 bytes from 192.168.1.254: icmp_seq=2. time=0. ms 64 bytes from 192.168.1.254: icmp_seq=3. time=0. ms ----192.168.1.254 PING Statistics---- 4 packets transmitted, 4 packets received, 0 percent packet loss round-trip (ms) min/avg/max = 0/0/0
Enable Dynamic Routing with RIP
The next step is to replace the static routes with RIP running over the GRE tunnel. To complete this task, you need to do the following:
- Enable RIP globally on both units.
- Enable RIP on all the relevant virtual interfaces contributing to the flow of data. This includes the GRE virtual interface and the LAN.
Note: You must ensure RIP is either disabled, or route advertisement is disabled on the external virtual interface (normally WAN). Otherwise you may cause a routing loop.
- Ensure you have policy rules allowing RIP traffic into/out-of the appropriate zones.
Note: The settings entered so far include several key rules, specifically 11, 12 and 7, that ensure this step. The X505 device is the source and destination for routing traffic. It must therefore have policy rules allowing it to participate in these protocols.
- Rule 11 ensures that the LAN zone can send traffic into the VPN zone.
- Rule 12 ensures the VPN zone can send traffic to any zone (which includes this-device – the key piece for RIP).
- Rule 7 allows this-device to send any traffic anywhere (again key for RIP).
X505_2# show conf routing routing rip disable update-timer 30 routing static add 192.168.1.0 netmask 255.255.255.0 gw 192.168.3.2 metric 1 X505_2# conf t routing rip enable X505_2# conf t interface virtual gre 3 rip enable X505_2# conf t interface virtual internal 1 rip enable X505_2# conf t interface virtual external 2 rip disable X505_2# conf t interface virtual external 2 rip advertise-routes enable X505_2# show policy rules ID Action Source Destination Service En. 1 allow LAN WAN ANY X 2 allow LAN this-device sms-conf.. X 3 allow LAN this-device icmp-ping X 4 allow LAN this-device secure-m.. X 5 allow LAN this-device dhcp-ser.. X 6 allow LAN this-device dns X 7 allow ANY this-device vpn-prot.. X 11 allow LAN VPN ANY X 12 allow VPN ANY ANY X 8 allow WAN this-device sms-conf.. 9 allow this-device ANY ANY X 10 deny ANY ANY ANY X X505_2# conf t routing static remove 192.168.1.0 netmask 255.255.255.0
After entering these changes, you can review the routing table to see that the RIP route is working. As displayed below, the routes display as provided by RIP. The routing statistics display the trigger updates from the RIP stack.
X505_2# show routing table Destination Subnet Mask Gateway Metric Age Status ---------------- ---------------- ---------------- ------- ------ -------- 0.0.0.0 0.0.0.0 10.0.0.1 8 - Static 10.0.0.0 255.255.255.0 10.0.0.2 1 - Direct 10.0.0.2 255.255.255.255 127.0.0.1 1 - Local 127.0.0.0 255.0.0.0 127.0.0.1 1 - Local 192.168.1.0 255.255.255.0 192.168.3.1 2 4 RIP 192.168.2.0 255.255.255.0 192.168.2.254 1 - Direct 192.168.2.254 255.255.255.255 127.0.0.1 1 - Local 192.168.3.1 255.255.255.255 192.168.3.2 1 - Direct 192.168.3.2 255.255.255.255 127.0.0.1 1 - Local X505_2# show routing statistics RIP Interface Statistics Interface Bad Packets Bad Routes Trig. Updates Sent V2 Auth Failures --------- ----------- ---------- ------------------ ---------------- 1 0 0 2 0 2 0 0 0 0 3 0 7 2 0
You can now re-verify the connectivity to the destination LAN virtual interface address with the PING tool as before.
X505_2# ping 192.168.2.254 64 bytes from 192.168.2.254: icmp_seq=0. time=0. ms 64 bytes from 192.168.2.254: icmp_seq=1. time=0. ms 64 bytes from 192.168.2.254: icmp_seq=2. time=0. ms 64 bytes from 192.168.2.254: icmp_seq=3. time=0. ms ----192.168.2.254 PING Statistics---- 4 packets transmitted, 4 packets received, 0 percent packet loss round-trip (ms) min/avg/max = 0/0/0
Enable Multicast Routing (IGMP, PIM-DM)
Next, you can enable multicast.
- You must enable IGMP and PIM-DM on both X505 devices and again on all virtual interfaces the multicast data must flow through. You must enable these services globally, then on each virtual interface the multicast data must traverse between the end points.
- Policy rules must allow the routing traffic to/from this-device for the X505 to participate in the multicast streams. For this the existing rules need a modification to allow IGMP from the LAN to the X505 (this-device). The existing rule 7 ensures the X505 can initiate multicast traffic to anywhere.
X505_2# conf t routing multicast igmp enable X505_2# conf t routing multicast pim-dm enable X505_2# conf t interface virtual internal 1 igmp enable X505_2# conf t interface virtual internal 1 pim-dm enable X505_2# conf t interface virtual gre 3 igmp enable X505_2# conf t interface virtual gre 3 pim-dm enable X505_2# conf t policy rule update 13 allow LAN this-device igmp X505_2# conf t policy rule move 13 before 8 X505_2# show policy rules ID Action Source Destination Service En. 1 allow LAN WAN ANY X 2 allow LAN this-device sms-conf.. X 3 allow LAN this-device icmp-ping X 4 allow LAN this-device secure-m.. X 5 allow ANY this-device vpn-prot.. X 6 allow WAN this-device sms-conf.. 7 allow this-device ANY ANY X 9 allow LAN this-device dhcp X 10 allow WAN this-device icmp-ping 11 allow LAN VPN ANY X 12 allow VPN ANY ANY X 13 allow LAN this-device igmp X 8 deny ANY ANY ANY X
After making this change on both X505 devices, you can see the multicast IGMP querier groups and the PIM-DM neighbors established.
X505_2# show routing multicast IGMP Querier Status Interface IP Address Querier Groups ---------- ---------------- ---------------- ---------------- 1 192.168.1.254 192.168.1.254 2 10.0.0.1 3 192.168.3.2 192.168.3.2 PIM-DM Neighbor Table Neighbor Interface Uptime Expires Version ---------------- ---------- ---------- ---------- ---------- 192.168.3.1 3 3 102 2
Connectivity can also be tested between clients on the LANs of the two X505 devices by having them ping each other.
With these settings completed, you can run multicast traffic between the two devices. The tool used in this example is VLC, a video streaming utility that can act as either server or client. If using this please ensure you comply with the VLC license terms. VLC is available from:
Once installed, a PC on the LAN side of X505_1 accessed a multicast stream on the LAN side of X505_2. Given a sample video stream called “presentation_short.vob”, the server was invoked with:
vlc -vvv presentation_short.vob –sout udp:239.255.1.1 –ttl 12 –loop
where:
- Presentation_short.vob – video you whish to stream
- 239.255.1.1 - a multicast IP address of your choice. By using UDP and a multicast address, the VLC server starts serving a multicast stream.
- 12 – is the TTL value of the IP packets
- loop – Loops the video clip over and over again.
The client was then invoked as:
vlc –vvv udp:@239.255.1.1
where 239.255.1.1 is the multicast IP address specified for the server.
The video display appears showing the traffic flowing correctly.
Looking at the X505 devices, you can see the IGMP group established for the multicast stream. In the test, X505_2 is on the client side and shows the IGMP group running.
X505_2# show routing multicast IGMP Querier Status Interface IP Address Querier Groups ---------- ---------------- ---------------- ---------------- 1 192.168.2.254 192.168.2.254 239.255.1.1 2 10.0.0.2 3 192.168.3.2 192.168.3.1 PIM-DM Neighbor Table Neighbor Interface Uptime Expires Version ---------------- ---------- ---------- ---------- ---------- 192.168.3.1 3 11700 82 2
Accordingly, X505_1 is on the server side and does not show such status. This is because the server X505 is unaware of the group – that is a transaction between the client and the local X505 it connects to.
X505_1# show routing multic IGMP Querier Status Interface IP Address Querier Groups ---------- ---------------- ---------------- ---------------- 1 192.168.1.254 192.168.1.254 2 10.0.0.1 3 192.168.3.1 192.168.3.1 PIM-DM Neighbor Table Neighbor Interface Uptime Expires Version ---------------- ---------- ---------- ---------- ---------- 192.168.3.2 3 55733 82 2
Files of the full configurations for the two devices are attached below:
Sample Files and Network Diagram
The following files are configuration examples of a sample deployment.
(Double-click on a file to open it.)
The following image details the network architecture for this sample deployment.
— David Gonzalez 2021/04/07 14:23