Tag Archives: default route

Juniper SRX240 – Firewall Cluster (Active / Standby)

Posted on by

KB ID 0000990

Problem

I’ve had very little exposure to JUNOS and Juniper equipment, and later in the year I have to deploy some for a client in a failover cluster. So I had a good look round on the Internet, and found loads of good blog posts and KB articles like this one. The problem is they are all geared to setting up a cluster, they ASSUME you then know about security zones, how to add default routes, and setup NAT etc. So they don’t cover that. Yes you then can set up a cluster, but it has no IP addresses, and you cant pass any traffic though it! Hopefully this will redress the balance.

Solution

Before you start, you obviously need two physical firewalls running the same OS, and this whole procedure is carried out from command line, (I’m using the console cable).

Things that took me a while to grasp, that you need to know.

1. The SRX240 has 16 ports numbered ge-0/0/0 to ge-0/0/15, when you cluster them the ports on the secondary firewall (node1) are renumbered to ge-5/0/0 to ge-5/0/16.

2. As soon as you cluster the firewalls the first port (on both) is reserved for management. That’s ge-0/0/0 and ge-5/0/0 they are then refereed to as fxp0.

3. As soon as you cluster the firewalls the second port (on both) is reserved for the firewalls control plane. That’s ge-0/0/1 and ge-5/0/1 they are then refereed to as fxp1.

4. You need to dedicate another port on both firewalls for the firewalls data link this can be any port, but to keep things simple I’ll use the next free port on both firewalls (ge-0/0/2 and ge-5/0/2). These will then be referred to as fab0 and fab1 (respectively).

Thats the clustering side of things, what about the networks I’m going to connect to the firewall. Take a look at this diagram;

Both the firewalls have a connection to each network (which makes sense if they are going to fail over). I’ve got an ‘outside’ network that connects to the Internet. ‘Inside’ I’ve got two networks, (most people reading this will have one, but remember this is practice for a live client, and they have two data LANS).

As all the networks are connected in two places, where do you assign IP addresses? Well above you can see the outside connections are plugged into ge-0/0/4 and ge-5/0/4. You add both these physical interfaces to a Reth (Redundant Ethernet Interface), and you assign the IP to that. So I have three Reth interfaces, (Reth0 for outside, Reth1 for the first inside network, Reth2 for the second inside interface).

So only Reth interfaces have IP addresses? Well no, the two fxp0 interfaces on each physical firewall, also get an IP address (for out of band management), and it’s a different one for each firewall.

Step 1: SRX240 Setup a Chassis Cluster.

1. Before we start you need to delete the existing interfaces from the config (ALL of them), otherwise you will get some errors later on when you try and commit (save) the firewall config. Also remove the hostname, we will set that in a minute.

[box] delete interfaces ge-0/0/0
delete interfaces ge-0/0/1
—Repeat for the rest of the interfaces—
delete interfaces ge-0/0/14
delete interfaces ge-0/0/15

delete system host-name[/box]

2. Connect ge-0/0/0 to management network > Connect ge-5/0/0 to management network >
Connect ge-0/0/1 on Primary to ge-5/0/1 on Standby, (this can’t be changed and will be the fxp0 connection) > Connect ge-0/0/2 on Primary to ge-5/0/2 on Standby (this can be changed but will be the fab0 and fab1 connection).

3. Carry out the following procedure on BOTH firewalls. This sets the host names of the firewalls and the IP addresses of the management interfaces.

[box]set groups node0 system host-name FW-A
set groups node0 interfaces fxp0 unit 0 family inet address 192.168.254.1/24
set groups node1 system host-name FW-B
set groups node1 interfaces fxp0 unit 0 family inet address 192.168.254.2/24
set apply-groups “${node}”[/box]

4. On FW-A (the primary node0) turn on clustering.

[box]set chassis cluster cluster-id 1 node 0 reboot[/box]

5. On FW-B (the secondary node1) turn on clustering.

[box]set chassis cluster cluster-id 1 node 1 reboot[/box]

6. Back on FW-A (the remainder of the config will be done on node0), set the configuration for the data link, notice I’m deleting the interface again, (I had a lot of bother with this so let’s play it safe). Then I’m saving the changes with a ‘commit’ command, because at this point if something is wrong it will tell you.

[box]delete interfaces ge-0/0/2
set interfaces fab0 fabric-options member-interfaces ge-0/0/2
set interfaces fab1 fabric-options member-interfaces ge-5/0/2
commit[/box]

Step 2 Create Redundancy Groups

1. Redundancy group 0 is created by default so set the priority for that one first.

[box]root@FW-A# set chassis cluster redundancy-group 0 node 0 priority 100
root@FW-A# set chassis cluster redundancy-group 0 node 1 priority 1[/box]

2. Create a new redundancy group that the Reth interfaces will use.

[box]root@FW-A# set chassis cluster redundancy-group 1 node 0 priority 100
root@FW-A# set chassis cluster redundancy-group 1 node 1 priority 1[/box]

Step 3 Define and Add Physical Interfaces to the Reth Interfaces

1. Define the number of Reth interfaces (two inside and one outside).

[box]root@FW-A# set chassis cluster reth-count 3[/box]

2. Allocate Reth0 to the physical interfaces (for outside).

[box] {primary:node0}[edit]
root@FW-A# edit interfaces

{primary:node0}[edit interfaces]
root@FW-A# set ge-0/0/4 gigether-options redundant-parent reth0
root@FW-A# set ge-5/0/4 gigether-options redundant-parent reth0 [/box]

3. Apply Redundancy group 1 to Reth0 and give it an IP Address.

[box]root@FW-A# set reth0 redundant-ether-options redundancy-group 1
root@FW-A# set reth0 unit 0 family inet address 123.123.123.123/24[/box]

4. Let’s see if that worked.

[box]root@FW-A# show chassis cluster
reth-count 3;
redundancy-group 0 {
node 0 priority 100;
node 1 priority 1;
}
redundancy-group 1 {
node 0 priority 100;
node 1 priority 1;
}[/box]

5. Setup Reth1 (inside). Add the physical interfaces, and apply redundancy group 1 (again).

[box] {primary:node0}[edit]
root@FW-A# edit interfaces

{primary:node0}[edit interfaces]
root@FW-A# set ge-0/0/8 gigether-options redundant-parent reth1
root@FW-A# set ge-5/0/8 gigether-options redundant-parent reth1
root@FW-A# set reth1 redundant-ether-options redundancy-group 1
root@FW-A# set reth1 unit 0 family inet address 192.168.20.1/24 [/box]

6. Setup Reth2 (inside). Add the physical interfaces, and apply redundancy group 1 (again) then save the changes.

[box] {primary:node0}[edit]
root@FW-A# edit interfaces

{primary:node0}[edit interfaces]
root@FW-A# set ge-0/0/12 gigether-options redundant-parent reth2
root@FW-A# set ge-5/0/12 gigether-options redundant-parent reth2
root@FW-A# set reth2 redundant-ether-options redundancy-group 1
root@FW-A# set reth2 unit 0 family inet address 192.168.50./24
{primary:node0}[edit interfaces]
root@FW-A# exit

{primary:node0}[edit]
root@FW-A# commit
node0:
commit complete

{primary:node0}[edit]
root@FW-A# [/box]

7. Then add the six physical interfaces that make up all the Reth interfaces to the redundancy group 1, and give each interface a ‘weighting’ of 255.

[box] {primary:node0}[edit]
root@FW-A#

set chassis cluster redundancy-group 1 interface-monitor ge-0/0/4 weight 255

{primary:node0}[edit]
root@FW-A# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/8 weight 255

{primary:node0}[edit]
root@FW-A# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/12 weight 255

{primary:node0}[edit]
root@FW-A# set chassis cluster redundancy-group 1 interface-monitor ge-5/0/4 weight 255

{primary:node0}[edit]
root@FW-A# set chassis cluster redundancy-group 1 interface-monitor ge-5/0/8 weight 255

{primary:node0}[edit]
root@FW-A# set chassis cluster redundancy-group 1 interface-monitor ge-5/0/12 weight 255 [/box]

Step 4 Add a ‘Default Route’ to the Internet.

1. To get traffic out to the Internet. the cluster needs the IP of its ‘next-hop’, (usually the router supplied by your ISP).

Note: If you’re anything like me after you enter this you will try and ‘ping’ the router from the firewall, or ping an Internet. IP address, at this point that wont work, (you need to allocate interfaces to security zones first).

[box]root@FW-A# set routing-options static route 0.0.0.0/0 next-hop 123.123.123.1[/box]

Step 5 Add interfaces to Security Zones and Allow Traffic Out

Note: I’m simply allowing all traffic out.

1. Make sure the Security Zones ‘Trust’ and ‘Untrusted’ Exist

[box]root@FW-A# show security zones
or
root@FW-A# run show security zones[/box]

2. Add the Reth0 Interface to the Untrusted zone.

[box]root@FW-A# set security zones security-zone untrust interfaces reth0.0 [/box]

3. Allow traffic.

[box]{primary:node0}[edit]
root@FW-A# set security zones security-zone untrust host-inbound-traffic system-services all
root@FW-A# set security zones security-zone untrust host-inbound-traffic protocols all[/box]

4. You can check the changes before you commit them.

[box] {primary:node0}[edit]
root@FW-A# show | compare
[edit security zones security-zone untrust]
+ host-inbound-traffic {
+ system-services {
+ all;
+ }
+ protocols {
+ all;
+ }
+ }
+ interfaces {
+ reth0.0;
+ }

Save the changes

{primary:node0}[edit]
root@FW-A# commit
node0:
configuration check succeeds
node1:
commit complete
node0:
commit complete

[/box]

5. Then add Reth1 and Reth2 to the Trusted zone and repeat the process to allow all traffic.

[box]root@FW-A# set security zones security-zone trust interfaces reth1.0
root@FW-A# set security zones security-zone trust interfaces reth2.0
root@FW-A# set security zones security-zone trust host-inbound-traffic system-services all
root@FW-A# set security zones security-zone trust host-inbound-traffic protocols all[/box]

6. Let’s check to see all that worked.

[box]

{primary:node0}[edit]
root@FW-A# show security policies from-zone trust to-zone untrust
policy trust-to-untrust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}

{primary:node0}[edit]
root@FW-A# show security policies
from-zone trust to-zone untrust {
policy trust-to-untrust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}

[/box]

Step 6 Allow Remote Management

1. We have two interfaces dedicated to out of band management, and we gave them an IP address earlier. Here I’m allowing remote administration via web to the J-Web console.

[box]root@FW-A# set system services web-management https interface fxp0.0[/box]

Step 7 Perform NAT on ‘Outgoing’ traffic.

1. Here we are doing what Juniper call ‘Source NAT‘ where we translate many addresses to one, (as in this case, but it can be a ‘pool’ of IP addresses). For the Cisco heads (like me) we are doing PAT.

Note: If you see Juniper mention ‘Destination NAT‘ they are usually talking about NATTING inbound traffic to one (or more) internal IP addresses.

[box] set security nat source rule-set TRUST-TO-UNTRUST from zone untrust
set security nat source rule-set TRUST-TO-UNTRUST to zone trust

set security nat source rule-set TRUST-TO-UNTRUST rule PAT-INTERFACE match source-address 192.168.0.0/16
set security nat source rule-set TRUST-TO-UNTRUST rule PAT-INTERFACE match destination-address 0.0.0.0/0
set security nat source rule-set TRUST-TO-UNTRUST rule PAT-INTERFACE then source-nat interface [/box]

 

Related Articles, References, Credits, or External Links

NA

Juniper SRX – Setting the Default Static Route

Posted on by

KB ID 0001008 

Problem

It takes me seconds to do this on an ASA, on every occasion I’ve had to do the same on a Juniper firewall I’ve had to research how to do it again.

Here I’m setting up the ‘default’ route to the Internet, but the syntax is the same for setting up any static route.

Solution

1. Connect to the firewall either by console cable or via SSH, go to CLI mode then configuration mode.

[box]login: PeteL
Password: ************

— JUNOS 12.1X47-D10.4 built 2014-08-14 22:21:50 UTC

PeteL@Petes-SRX> cli

PeteL@Petes-SRX> configure
Entering configuration mode

[edit]
PeteL@Petes-SRX#

[/box]

2.Here is the syntax for adding a route, (0.0.0.0/0 denotes the default route or GOLR).

[box][edit]
PeteL@Petes-SRX# set routing-options static route 0.0.0.0/0 next-hop 123.123.123.123[/box]

3. Save the changes.

[box][edit]
PeteL@Petes-SRX# commit
commit complete[/box]

 

Related Articles, References, Credits, or External Links

NA

 

Manually Configuring HP Wireless (MSM 720 controller) for Public and Private Wireless Networks

Posted on by

KB ID 0000833 

Problem

In the following procedure I’ll configure the following;

  1. HP 5412zl Switch.
  2. Cisco ASA 5510 Firewall.
  3. HP MSM720 Controller.
  4. HP MSM460 and MSM317 Access Points.

If you are configuring an MSM765zl or MSM775zl use the following article first.

HP MSM765zl and 775zl – Initial Setup and Routing

Assumptions

  1. Private SSID will be on the normal corporate LAN (In this case 172.16.254.0/24).
  2. Public SSID will get its IP addressing from the controllers DHCP Server. (10.220.0.0/16).
  3. The Wireless traffic will traverse the corporate LAN (After being natted on the controller) as 10.210.0.0/16.
  4. My LAN DNS Servers are 172.16.254.1 and 172.16.254.2.

Solution

HP Switch Configuration.

1. The switch must be performing LAN routing, if the LAN’s default gateway is a firewall that needs rectifying first. (where 172.16.254.200 is the firewall).

[box]ip routing
ip route 0.0.0.0 0.0.0.0 172.16.254.200[/box]

2. Switch must be able to resolve DNS queries.

[box]ip dns server-address priority 1 172.16.254.1[/box]

3. Declare a VLAN for the guest VLAN (210), name it, and give it an IP address > Add a Port (A1) to that VLAN which will connect to the Internet Port of the MSM Controller (Port5).

[box]vlan 210
name WIRELESS-TRAFFIC
ip address 10.210.0.1 255.255.255.0.0
untagged A1 [/box]

4. Tag This VLAN on the ‘Inter Switch’ Links from the core switch to the firewall/perimeter device.

[box]tag D24[/box]

5. Save the Switch changes with a write mem command.

Configure the Cisco ASA To Allow the Wireless Traffic out.

Actions for different firewall vendors will vary but you need to achieve the following;

Make sure that a client on the 10.210.0.0/16 network can get access to the Internet

To do that you will need to achieve the following;

Make sure that the 10.210.0.0/16 network has http and https access allowed outbound on the firewall.
Make sure that 10.210.0.0/16 is getting NATTED through the firewall to the public IP address.

1. Connect to the firewall > Allow the Wireless Traffic out.

[box]

access-list outbound extended permit ip 10.210.0.0 255.255.0.0 any

Note: this permits ALL IP traffic you might prefer

access-list outbound extended permit ip 10.210.0.0 255.255.0.0 any eq http
access-list outbound extended permit ip 10.210.0.0 255.255.0.0 any eq https

Note2: This also assumes you have an ACL called outbound applied to traffic that is destined outbound (show run access-group will tell you)

[/box]

2. Perform NAT on the new wireless outbound traffic.

[box]

object network WLAN-CLIENTS
subnet 10.210.0.0 255.255.0.0
nat (inside,outside) dynamic interface

Note: For Firewalls running versions older than 8.3 the NAT commands will be different, e.g.

nat (inside) 1 10.210.0.0 255.255.0.0

{Where you have a matching global (outside) 1 command in the config already}

[/box]

3. Allow the firewall to ‘route’ traffic back to the wireless clients. (where 172.16.254.254 is the core switch performing LAN routing).

[box] route inside 10.210.0.0 255.255.0.0 172.16.254.254[/box]

4. Save the changes.

5. At this point plug a PC/Laptop into the core switch (Port A1) and make sure you can get Internet access (‘you will need a static IP on the 10.210.0.0 range).

Configure the HP MSM 720 Controller

MSM 720 Initial Setup and IP Addressing.

1. Connect to to the MSM 720 controller (Port 1) 192.168.1.1 (username admin, password admin).

2. Go though the initial setup > Stop when you get to the Automated workflows screen (simply press Home).

3. Setup Access Network: Home > Network > Access Network > Set the Addressing and Management IP addresses like so;

  • Addressing 172.16.254.115/24
  • Management address 172.16.254.116/25

Save.

Note: There’s two because you can separate the management traffic off to another subnet if you wish.

4. Connect Port 1 on the MSM controller to ANY normal port on the Switch (which will be untagged in VLAN 1) >Then connect to the Controller on its new IP https://172.16.254.115.

5. Setup Internet Network: Home > Network > Internet Network > Static.

6. Configure > IP = 10.210.0.2 > Address Mask 255.255.0.0 > Save (don’t worry if you get a warning about DNS).

7. Connect Port 5 on the MSM to Port A1 on the switch (the one you untagged in VLAN 210).

8. Setup DNS: Home > Network > DNS > Enter the Primary LAN DNS servers (172.16.254.1 and 172.16.254.2).

9. Tick DNS Cache > Tick DNS Switch over > Tick DNS interception > Save.

10. Setup Default Route: Home > Network > IP Routes > Add.

11. Enter 10.210.0.1 with a Metric of 1 > Add.

12. Setup DHCP (Note: you will create the scope later)

Obviously only complete this step if you want the Controller to act as a DHCP server for your ‘Public’ Wireless network.

Home> Network > Address allocation > Tick DHCP Server > Configure.

13. Enter the domain name > change Lease tome to 1500.

Note: At this point it automatically fills in DHCP Settings (these will NOT be used don’t panic!)

14. REMOVE the tick form Listen for DHCP Requests on ‘Access Network’

15. MAKE SURE there is a tick in the ‘Client data tunnel’ box > Save.

HP MSM 720 Configure Wireless Access Public and Private

For this procedure we will rename the default VSC which is called HP.

1. Home > Controller (on the left) > VSCs) > HP > Change the Profile name for HP to “Private” > Untick Authentication > Untick Access control.

2. Change the SSID from HP to ‘Private’ > Tick Broadcast Filtering.

3. Ensure Wireless security filters is unticked.

4. Tick Wireless Protection > Set the mode to WPA2 (AES/CCMP) > Change Key Source to ‘Preshared Key’ > Enter and confirm the WPA Password > Save (at the bottom of the screen).

5. Setup Public/Guest VSC: Home > VSC’s > Add New VSC Profile.

6. Set the profile name to ‘Public’ > MAKE SURE authentication and access control ARE ticked.

7. Change the SSID to Public > Tick broadcast filtering.

8. Change Allow Traffic between wireless clients to NO > Expand Client Data Tunnel > Tick ‘always tunnel client traffic’.

9. Ensure Wireless Protection is unticked.

10. If you require HTML based logins, tick that (Note: You will need to create a user later, if you enable this).

11. If using the controller for DHCP > Enable the DHCP Server and specify;

  • DNS 10.220.0.1
  • Start 10.220.0.100
  • End 10.220.0.200
  • Gateway 10.220.0.1
  • Net mask 255.255.0.0
  • Subnet 10.220.0.0

Create a Network Profile for Each of the New VSC’s

1. Home > Network > Network Profiles > Add New Profile.

2. Call it ‘Private’ Tick VLAN ID select 1 > Save.

3. Add New Profile > Call it ‘Public’ > Tick VLAN ID and set it to 210 > Save.

4. At this point, connect your wireless AP’s to the network, and the controller should detect them.

Bind the VSC’s to the Default AP Group (Using the network profiles we just created)

1. On the left hand menu > Controller > Controlled Alps > Default Group > VSC Bindings (top) > Select the ‘Private’ VSC Binding.

2. Make sure ‘Egress Network’ is NOT ticked and none is selected > Save.

3. Add New Binding > Select the ‘Public’ VSC Profile > Tick EGRESS NETWORK > Set the Network profile to ‘Public (210)’ > Save.

Create user accounts (Only if using HTML Based Authentication)

1. Home > Users > User Accounts > Add New Account > specify a name i.e guest > specify and confirm a password i.e. Password123.

2. Change the MAX concurrent Sessions to 250 > Enable VSC Usage > Add the ‘Public’ VSC (right arrow) > Save.

Synchronize the Access Points to the MSM Controller

1. Home > Controller (left) > Controller APs > Overview Tab > Change the Action drop down to Synchronize Configuration > Apply.

2. Wait for the APs to synchronize > Test both the SSIDs.

 

Related Articles, References, Credits, or External Links

NA

 

HP MSM Controller – Access Points Stuck ‘Waiting Acceptance’

Posted on by

KB ID 0000868 

Problem

When viewing the Controller > Controlled APs, You may see some of them stuck with a ‘Waiting Acceptance’ status.

Solution

This happens because the Access Point can contact the controller, (otherwise you wouldn’t even see it). But the controller cant get traffic back to the access point, to update its firmware, or to synchronize it. The root cause of this is usually because this access point is on another subnet that the controller cant get to.

1. Navigate to > Home > Network > IP Routes.

2. Add an ‘Active Route’ for the subnet the remote network the AP is on (in this example 10.3.0.0/16), and the gateway the controller needs to send the traffic to to get there, (in this example 10.1.0.254).

3. Apply the cup of coffee rule.

4. Remember before you can Synchronize it you will need to select the AP and ‘Authorize Locally’

Related Articles, References, Credits, or External Links

NA

 

HP MSM765zl and 775zl – Initial Setup and Routing

Posted on by

KB ID 0000917 

Problem

The MSM 765zl and 775zl, unlike the rest of the HP MSM controller series, do not have any physical Ethernet ports on them.

So before you can get to its web management interface, you need to be able to give it an IP address, and then the controller needs to be able to find a route back to where you are, assuming you are not on a flat unrouted/single VLAN. Obviously if you are directly connected to the same network segment then you can set the devices ‘default route’ from the web management console.

Solution

1. Connect to the chassis that the controller is in, either via telnet or console cable. As I outlined in an earlier article you need to find the controllers slot letter and index number with a services command. (If you are sat in front of the switch the slot letter should already be known!)

2. Now, connect to the MSM directly and give the controller its LAN and WAN IP addresses.

Note: HP call them LAN and WAN interfaces, (I know it’s confusing), the WAN interface does not have to connect to the WAN it only points in that direction. I’m assuming it’s a throw back from when these devices were developed by Colubris.

[box] CORE-SW# services F 2
CORE-SW(msm765-aplication-F)> enable
CORE-SW(msm765-aplication-F)# config
CORE-SW(msm765-aplication-F)(config)# interface ip wan
CORE-SW(msm765-aplication-F)(config-if-ip)# ip address 192.168.1.1/24
CORE-SW(msm765-aplication-F)(config-if-ip)# ip address mode static
CORE-SW(msm765-aplication-F)(config-if-ip)# end
CORE-SW(msm765-aplication-F)(config)# interface ip lan
CORE-SW(msm765-aplication-F)(config-if-ip)# ip address 10.254.0.100/16
CORE-SW(msm765-aplication-F)(config-if-ip)# ip address mode static
CORE-SW(msm765-aplication-F)(config-if-ip)# end
[/box]

3. Now if you are on the same network (or VLAN) as the controller, you should be able to connect to the web management console. If not you will need to do two further steps

a) Connect the TWO virtual ports of the MSM to the correct VLANs on the switch.

b) Add a route back to the network you are on, either by setting a default route (if there is only one) or a static route.

Connect The Two MSM Virtual Ports

At this point the MSM blade can be treated like any other blade with Ethernet ports on it. Above we found out the blade was in slot F, so the ports with show up on the chassis switch as F1 and F2.

Port number 1: Is the WAN/Internet port
Port number 2: Is the LAN port

At the very least the WAN port should be in a different VLAN like so;

[box]

CORE-SW> enable
Password xxxxxxxx
CORE-SW# configure terminal
CORE-SW(config)# vlan 210 name WifiLink
CORE-SW(config)# vlan 210
CORE-SW(vlan-210)# untagged F1
CORE-SW(vlan-210)# exit
CORE-SW(config)#

If all your LAN traffic is on VLAN 1 (which is the default), then the MSM LAN port will already be untagged in VLAN 1. If not you will also need to present the MSM LAN port to the LAN VLAN.

CORE-SW# configure terminal
CORE-SW(config)# vlan 10 name LANTraffic
CORE-SW(config)# vlan 10
CORE-SW(vlan-10)# untagged F2
CORE-SW(vlan-10)# exit
CORE-SW(config)#

[/box]

Adding Default and Static Routes to the MSM controller.

The controller needs a default route, or it will not be able to send traffic out of the local LAN. In a simple flat network that should be all that you need. But if you have multiple network segments (or VLANs), then it will also need a static route adding for each of these. This is important for both access to the web management console, and because your wireless access points need to be able to speak to the controller! If your wireless access points are on a different network you may need to follow the article below to let them know where the controller is.

Register HP Wireless Access Points With an HP MSM Controller on a Different Subnet

[box]

CORE-SW# services F 2
CORE-SW(msm765-aplication-F)> enable
CORE-SW(msm765-aplication-F)# config
CORE-SW(msm765-aplication-F)(config)# ip route gateway 0.0.0.0/0 192.168.1.254 1

If you need to add additional routes the syntax is the same as above.

CORE-SW(msm765-aplication-F)(config)# ip route gateway 10.100.0.0/16 10.254.0.254 1
CORE-SW(msm765-aplication-F)(config)# ip route gateway 10.200.0.0/16 10.254.0.254 1

[/box]

Now you should be able to connect to the web management console and configure your wireless networks, this process is identical to configuring the physical controllers, like the MSM 720 see the link below.

Manually Configuring HP Wireless (MSM 720 controller) for Public and Private Wireless Networks

Related Articles, References, Credits, or External Links

NA

 

Cisco IOS – Find The ‘Default Route’ For A VRF

Posted on by

KB ID 0001086 

Problem

Routing is one of my weaker subjects, and today I was trying to chase some routes though a network to locate all the firewalls. The core of the network has a bunch of 6500 Switches in various data centers. I tracked the network I was working on to an SVI on one of the core switches, that was in a VRF.

But how could I find the ‘next hop’, the routing table on these switches is very large.

Solution

Thankfully I’m surrounded by a team of routing ninjas, so I asked. The syntax is just;

[box]show ip route vrf {VRF Name}[/box]

Note: I you don’t know the name of the vrf;

[box]show running-config vrf

OR

show running-config vrf | incl <NAME>[/box]

Then as with any routing table, look for the default route.

For example;

[box]

Petes-Core-SW#show ip route vrf CORP:NET

Routing Table: CORP:NET
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is 5.229.0.1 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 5.229.0.1
      10.0.0.0/8 is variably subnetted, 13 subnets, 5 masks
B        10.1.0.0/16 [200/0] via 123.123.123.1, 3w5d
B        5.219.28.0/24 [200/0] via 123.123.123.1, 3w5d
B        5.219.40.0/24 [200/0] via 123.123.123.1, 3w5d
B        5.219.241.0/24 [200/0] via 123.123.123.1, 3w5d
B        10.220.50.0/24 [200/0] via 123.123.123.1, 3w5d
C        5.229.0.0/29 is directly connected, GigabitEthernet2/28
L        5.229.0.2/32 is directly connected, GigabitEthernet2/28
C        5.229.1.0/24 is directly connected, Vlan229
L        5.229.1.1/32 is directly connected, Vlan229
B        5.229.60.0/24 [200/0] via 123.123.123.16, 3w4d
B        5.229.61.0/24 [200/0] via 123.123.123.16, 3w4d
B        5.229.255.0/30 [200/0] via 123.123.123.1, 3w5d
B        5.229.255.4/30 [200/0] via 123.123.123.16, 3w4d
      172.100.0.0/24 is subnetted, 1 subnets
B        172.100.100.0 [200/0] via 123.123.123.1, 3w5d
Petes-Core-SW#

Lets test connectivity

Petes-Core-SW# ping vrf CORP:NET 5.229.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.229.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
Petes-Core-SW#

[/box]

Next hop is 5.229.0.1 (which turned out to be the firewall I was looking for).

To Ping Over a VFF

[box]ping vrf <VRF-NAME> <IP ADDRESS>

e.g.

ping vrf CORP:NET 192.168.1.100[/box]

To SSH Into Another IOS Device Over a VRF

[box]ssh -l <USER-NAME> -vrf <VRF_NAME> <IP-ADDRESS>

e.g.

ssh -l fredbloggs -vrf CORP:NET 192.168.1.123[/box]

Related Articles, References, Credits, or External Links

NA

Cisco ASA Redundant or Backup ISP Links with VPNs

Posted on by

KB ID 0000544

Problem

This method provides failover to a redundant ISP link should your primary network connection go down. IT IS NOT going to load balance the traffic across both interfaces. In this example I’ve also got a VPN to a remote site and some port forwarding to contend with as well.

Where we are at the start.

Where we want to be

 

Solution

Before you go any further the ASA that will have the backup ISP line, needs a Security Plus Licence or it’s not going to work.

Setup Backup ISP Links at the Main Site

1. Log into the firewall and setup the IP address on your backup interface.

[box]

PetesASA>
PetesASA> en
Password: *******
PetesASA#
PetesASA# configure terminal
PetesASA(config)# interface Ethernet0/3
PetesASA(config-if)# nameif backup
PetesASA(config-if)# security-level 0
PetesASA(config-if)# ip address 234.234.234.234 255.255.255.248
PetesASA(config-if)# no shutdown
PetesASA(config-if)# exit
PetesASA(config)#

[/box]

2. In a ‘Failed Over’ state your traffic needs to then be NATTED to the backup interface, then setup a new route for the outside interface, and finally one for the backup interface. Note: The new primary route will be “Tracked” based on an SLA we will configure in a minute.

[box]

Configure NAT for a firewall running an OS NEWER than 8.3

PetesASA(config)# object network obj_any-01
PetesASA(config-network-object)# subnet 0.0.0.0 0.0.0.0 
PetesASA(config-network-object)# nat (inside,backup) dynamic interface
Configure NAT for a firewall running an OS OLDER than 8.3

PetesASA(config)# global (backup) 1 interface
INFO: backup interface address added to PAT pool

Configure the Routes

PetesASA(config)# route outside 0.0.0.0 0.0.0.0 123.123.123.124 1 track 1
PetesASA(config)# route backup 0.0.0.0 0.0.0.0 234.234.234.235 2

[/box]

3. Now we are going to setup a new SLA that maintains connectivity to an IP address (In this case 4.2.2.2 via ICMP, then we are going to tie that SLA to “track 1”, )which you will remember is what keeps the default route on the Primary ISP), if that route fails, it swaps to the backup route.

[box]

PetesASA(config)# sla monitor 100
PetesASA(config-sla-monitor)# type echo protocol ipIcmpEcho 4.2.2.2 interface outside
PetesASA(config-sla-monitor-echo)# num-packets 3
PetesASA(config-sla-monitor-echo)# frequency 10
PetesASA(config-sla-monitor-echo)# sla monitor schedule 100 life forever start-time now
PetesASA(config)# track 1 rtr 100 reachability
PetesASA(config)#

[/box]

4. Any port forwarding getting done on the outside interface needs a mirror entry for the backup interface. and also will need matching ACL’s

[box]

PetesASA(config)# static (inside,backup) tcp interface www 10.0.0.5 www netmask 255.255.255.255
PetesASA(config)# static (inside,backup) tcp interface smtp 10.0.0.3 smtp netmask 255.255.255.255
PetesASA(config)# access-list backup permit tcp any interface backup eq www
PetesASA(config)# access-list backup permit tcp any interface backup eq smtp PetesASA(config)# access-group backup in interface backup

[/box]

5. Lets test it, issue a “show route” command, then disconnect your primary ISP then issue another “show route” command and it should have failed over like so;

[box]

PetesASA(config)# show route
 
 Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
 i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
 * - candidate default, U - per-user static route, o - ODR
 P - periodic downloaded static route
 
 Gateway of last resort is 123.123.123.124 to network 0.0.0.0
 
 C 234.234.234.0 255.255.255.248 is directly connected, backup
 C 123.123.123.0 255.255.255.240 is directly connected, outside
 C 10.0.0.0 255.255.255.0 is directly connected, inside
 S* 0.0.0.0 0.0.0.0 [1/0] via 123.123.123.124, outside
 PetesASA(config)#
 
 
Now Disconnect the Primary line
 
 PetesASA(config)# show route
 
 Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
 i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
 * - candidate default, U - per-user static route, o - ODR
 P - periodic downloaded static route
 
 Gateway of last resort is 234.234.234.235 to network 0.0.0.0
 
 C 234.234.234.0 255.255.255.248 is directly connected, backup
 C 10.0.0.0 255.255.255.0 is directly connected, inside
 S* 0.0.0.0 0.0.0.0 [254/0] via 234.234.234.235, backup
 PetesASA(config)#

[/box]

6. To enable this firewall to accept the existing VPN on its backup interface, you need to add the backup interface to that cryptomap (issue a show run crypto if your unsure). Then you need to enable ISAKMP on the backup Interface.

[box]

PetesASA(config)# crypto map outside_map interface backup
 PetesASA(config)# crypto isakmp enable backup

[/box]

7. Save the changes with a write mem command.

[box]

PetesASA(config)# wr mem
 Building configuration...
 Cryptochecksum: 91d190ba 2a3eb9c4 244d8c88 0da54e36
 
 10220 bytes copied in 3.740 secs (3406 bytes/sec)
 [OK]
 PetesASA(config)#

[/box]

Change the ASA at the Remote VPN Site

1. Connect to the firewall at the remote site, find the cryptomap that points to the main site (show run crypto). find the one that pointing to the IP at the main site, then add the new IP address as an alternate peer address.

[box]

RemoteSite(config)# crypto map outside_map 2 set peer 123.123.123.123 234.234.234.234

[/box]

2. Then create a tunnel group for the new backup address with the same shared secret as tunnel group to the primary IP.

[box]

RemoteSite(config)# tunnel-group 234.234.234.234 type ipsec-l2l
RemoteSite(config)# tunnel-group 234.234.234.234 ipsec-attributes
RemoteSite(config-tunnel-ipsec)# pre-shared-key 123456789

[/box]

3. Save the changes with a “write mem” command.

[box]

RemoteSite(config-tunnel-ipsec)#write mem
 Building configuration...
Cryptochecksum: 7a455ca7 3b637757 cd40aa82 7f3a22d8
 
7842 bytes copied in 1.530 secs (7842 bytes/sec)
[OK]
RemoteSite(config-tunnel-ipsec)#

[/box]

To test the VPN fails over, at the remote site issue a “show cry isa” command, then get someone at the primary site to disconnect the primary ISP, wait a few seconds and then re-issue a “show cry isa” command and it should have flipped over.

[box]

Failover-FWall# show cry isa
 
Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1
 
1 IKE Peer: 123.123.123.123
Type : L2L Role : responder
Rekey : no State : MM_ACTIVE
 
Now Disconnect the Primary line at the Main site
 
Failover-FWall# show cry isa
 
Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1
 
1 IKE Peer: 234.234.234.234
Type : L2L Role : responder
Rekey : no State : MM_ACTIVE

[/box]

Related Articles, References, Credits, or External Links

Original article written 12/12/11