Remote Desktop Services – Connection Errors

KB ID 0001132

 

Below is not an exhaustive list of connection errors, it’s just a some things that have tripped me up. If you have a nasty error that you have fixed, feel free to drop me a line, send me some screenshots and the fix, and I’ll add them as well.

General Errors

Remote Desktop can’t connect to the remote computer for one of the following reasons;

1) Remote access to the server is not enabled
2)The remote computer is turned off
3)The remote computer is not available on the network

Make sure the remote computer is turned on and connected to the network, and that remote access sis enabled.

Probably the most common (and easiest to troubleshoot) of RDP errors, firstly ensure that the server is actually ‘listening’ for RDP connections, on the SERVER issue the following command;

[box]

netstat -an | find /i ":3389"

[/box]

You should see it LISTENING (Note: Below its listed twice because its listening on IPv4 and IPv6)

If its not, the the service might not even be running, Look in Services, and ensure the following services are running;

  • Remote Desktop Services
  • Remote Desktop Services UserMode Port Redirector

Make sure that RDP has been allowed on the local firewall of the RDP server, In the past I’ve seen a bug on some versions of Windows when even with the firewall disabled, things didn’t work unless RDP was allowed on the firewall settings. (I know that makes no sense, but I’ve seen it, particularly for remote VPN traffic).

Test RDP Connectivity

From a machine ON THE SAME NETWORK as the target RDP Server, firs see if you can ping the server by both IP address and hostname. (This is more for peace of mind remember the server might ot respond to pings but might be responding to RDP Traffic.

Then test that the machine you are on can get to the the RDP server on the correct port, (TCP 3389*)

[box]

Test-NetConnection {IP-Address-or-Hostname} -Port 3389
OR
Test-NetConnection {IP-Address-or-Hostname} RDP

[/box]

Providing this works, now try the SAME tests form outside you network, i.e. outside the firewall, or on a remote VPN  connection etc.

*RDP Port Note: Normally RDP is on TCP 3389, check on the server just in case someones changed the RDP listening port number. Or the firewall is expecting you to connect on another RDP Port.

Your computer can’t connect to the remote computer because an error occurred on the remote computer that you want to connect to. Contact your network administrator for assistance.

Solution for Windows 10: I struggled with this for a while, all forum posts refer to windows 7/8 and the problem was caused by a windows update (KB2592687), that needed to be removed. But I was connecting with Windows 10? This  was the resolution;

Create/Edit a 32 bit DWORD value called RDGClientTransport in your registry at;

[box]

HKCU > SOFTWARE  >Microsoft > Terminal Services Client

[/box]

Set its value to ‘1’ (one).

Also See Remote Desktop Web Access – Connection Error


Your computer can’t connect to the remote computer because your computer or device did not pass the Network Access Protection requirements set by your network administrator.Contact your network administrator for assistance.

You normally see this error if one (or more), of your Remote Desktop Role servers does not have the correct certificate installed on it, (or the certificate it does has has expired).

Server Manager > Remote Desktop Services > Collection > Task > Select your collection > Task > Edit Deployment Settings > Certificates > Check and reinstall each one as required.

Remote Desktop Gateway Errors

Your computer can’t connect to the remote computer because the Remote Desktop Gateway server address is unreachable or incorrect. Type a valid Remote Desktop Gateway server address.

Your computer can’t connect to the remote computer because the Remote Desktop Gateway server is temporarily unavailable. Try reconnecting later or contact your network administrator for assistance.

The machine trying to connect needs to be able to resolve the ‘public name’ of the Remote Desktop Gateway server. And this may not be the hostname of the server! As you can see in the image above the Gateway server name is set to rdg.smoggyninja.com. The important thing is when I ping this name, it resolves to the correct IP address, (mine responds to pings, yours probably wont if you’re connecting though a firewall.)

In some cases you need to set the public name of the the Remote Desktop Gateway server, in the servers IIS Settings. On the Gateway server > Start > Administrative Tools > Internet Information Services (IIS) Manager > {Server-name} > Sites > Default Website > RDWeb > Pages  > Application Settings > Set ‘DefaultTSGateway’ to the public name of the gateway server. Then from command line run ‘iisreset‘ to restart the web services.

Your computer can’t connect to the remote computer because the Remote Desktop Gateway server’s certificate has expired or has been revoked. Contact your network administrator for assistance.

In most cases this should be easy to fix, if you use self signed certificates make sure your CRL settings and/or OCSP settings are correct. If you use a publicly signed cert make sure your client can contact the publishers CRL (look on the properties of the certificate).

Check the Obvious: It saying the RDG cert has expired, make sure it’s in date! In the Gateway Server Launch Server Manager > Remote Desktop Services > Collections > {Collection-name} > Tasks > Edit Deployment Properties.

Certificates > RD Gateway > View Details > Is it in date?

Everything is OK? But I’m Still Getting This Error? Are you publishing the Gateway with something else like Web Application Gateway? Threat Management Gateway? Load Balancer? Look in that direction.

Also See Remote Desktop Web Access – Connection Error

Related Articles, References, Credits, or External Links

NA

Windows Server 2012 R2 – Deploying Remote Desktop Services

KB ID 0001136 

Problem

I’ve had to do a rollout of Remote Desktop Services on Server 2012 R2, and publish it with Active Directory Federation Services and Web Application Proxy. I’m a little rusty on RDS and needed to deploy a few roles, so for my proof of concept I deployed RDS on TWO servers. Below is a run though and my notes on deploying RDS ONLY (I’ll put the links to other articles at the bottom of this post as I write them).

Solution

To save yourself some hassle, visit every server that will be in the Remote Desktop Server deployment, and add all the others into each others ‘server manager’ console.

Manage > Add Roles and Features > Next > Remote Desktop Services Installation > Next.

Standard Deployment. Note: If you choose Quick Start it puts all the roles on one server  > Next.

Session-based desktop deployment > Next.

Next.

Select the server that will host the Connection Broker Rule and add it  > Next.

Add the server that will host the Remote Desktop Web Access role > Next.

Add the server that will host the Remote Desktop Session Host role > Next.

Tick the ‘restart the destination server automatically if required’ > Deploy.

Finish. (Note: There will be a licensing error, we will address that in a minute).

In Server Manager > Remote Desktop Services > Overview > Note: There are two options yet to be configured, (shown in green). Select ‘RD Gateway’.

Add in the server that will host the RD Gateway role > Next.

Add in the public name of the RD Gateway server, this will generate a self signed certificate, (you can replace this with a proper one later).

Add.

Close

Now Add RD Licensing.

Add in the server that will host the licensing role > Next.

Add

Close

All the nodes should now be displayed..

In production you would now add your Remote Desktop Licences, If you don’t,  the whole thing will run for 120 days, (though it continues to nag you about adding licences). I’m content with the 120 day licence for my test deployment. But I will still ‘Activate’ my licensing server.

Follow the instructions

Now you need to create a ‘Collection‘, this is a group of host servers that host applications you can publish. Server Manager > Remote Desktop Services > Collection > Task > Create Session Collection.

Next.

Give the collection a name  > Next.

Add in the server(s) running the RD Host role that will be included in this collection > Next.

Select the user groups that you want to grant access to. Here Im simply using the domain users group  > Next.

If you want to deploy ‘profile disks’ enter a UNC path to the share > Next.

Create.

Close.

To actually publish applications, select the collection you just created > RemoteApp Programs > Tasks  >Publish RemoteApp Programs.

Select the applications, (or add them in if they are not displayed)  > Next.

Publish.

Note: You can change certificates from within Server Manger, but I prefer the manual approach, on the RD Gateway Server > Launch the IIS Manager > Select the server > Server Certificates.

Import > Import your publicly signed certificate, (you can use a self signed certificate but DON’T FORGET your remote client needs to be able to check your CRL, and trust your issuing CA if you do).

Sites > Default Web Site > Edit Bindings.

Select ‘https’ > Edit > Add in your certificate > OK > Close.

Bounce the services with an ‘iisreset‘ command.

Update 070316 You also will need to restart the Remote Desktop Services Service!

Connect to the server on the https://{FQDN}/RDWeb address, and you can check the correct certificate is used.

You should now be able to log into Remote Desktop Services Web Access.

Related Articles, References, Credits, or External Links

Server 2008 R2 Install and Configure Remote Desktop Services (Web Access)

Publishing Remote Desktop Services With Web Application Gateway

VMware VI Client error ‘Unable to connect to the MKS: Failed to connect to server {ESX-Host}:902’

KB ID 0000815 

Problem

Seen when connected to the VMware VI client software, and attempting to open a console session with a virtual machine.

Solution

This is a pretty generic error, for whatever reason the client software cannot connect to the KMS (Keyboard, Mouse, and Screen).

In NEARLY every case this is a communication issue, either the machine running the client software cannot resolve the name of the ESX host that is hosting the virtual machines, or TCP Port 902 is being blocked by a firewall.

1. If you can’t simply pop the correct name in your DNS, then add the name and IP to the machines, (the one running the VI client software) host file. You will locate this in;

[box] C:WindowsSystem32Driversetc [/box]

2. Open it with Notepad, and add the IP and name of your ESX host(s), Note: I’m also putting the name and IP of my Virtual Center server as well. Save the file and try again.

3. You should now be able to connect.

It’s NOT DNS!

If you can happily resolve the name and are sure that the port is not being blocked, then have you made any IP changes? Is the default gateway on the ESX Server set correctly? And finally restart the management agents on the host, either from the console, or by running ‘/sbin/services.sh restart’.

I’ve also fixed this error by shutting down the machine > removing it from the inventory > then browsing the storage, to locate the .vmx file > then simply import it back again.

Related Articles, References, Credits, or External Links

NA

Windows Gets a 0.0.0.0 Default Gateway

KB ID 0000332 

Problem

Seen on Windows 7 but can also occur on Vista, I had this problem a while ago and fixed it then it reoccurred this morning (after I’d spent a morning on a client site changing my IP address a few times. As soon at I got back to the office the machine picked up an IP address form DHCP with the correct default gateway, but sat above that was a default gateway of 0.0.0.0

I could not ping anything outside my network either.

Solution

After some “Googling” it turns out this problem is caused the the Apple “Bonjour Service” as I detest iTunes and have no Apple software I was confused. It Seems that Adobe CS3 (Creative Studio) installs it, (Thought CS4 does not).

Quick Fix (though not permanent)

1. Start > Run > cmd {enter}

2. Issue the following command,

[box]route delete 0.0.0.0[/box]

Permanent Fix

1. Firstly make sure that Bonjour IS your problem look for the following,

C:Program FilesBonjourmDNSResponder.exe or C:Program Files (x86)BonjourmDNSResponder.exe (if your x64 bit I’m not sure?)

2.If is is there look to find the service that running it, (Start > Run > Services.msc).

In my case the service was called,

##Id_String2.6844F930_1628_4223_B5CC_5BB94B879762##

Catchy eh? I discovered that is caused by an install error.

This;

Is fixed with these commands;

3. Now I can see it correctly,

Note: Some forums report that the “National Instruments mDNS Responder Service” also used the same system and causes this problem.

4. You can simply stop and disable the service if you wish, or you can remove it by, running the following command,

x32 bit

[box]”C:Program FilesBonjourmDNSResponder.exe” -remove[/box]

x64 bit

[box]”C:Program Files (x86)BonjourmDNSResponder.exe” -remove[/box]

remove mdns responder

5. Navigate to, C:Program FilesBonjour OR C:Program Files (x86)Bonjour And rename mdnsNSP.dll to mdnsNSP.old

6. Reboot the affected machine.

7. Then delete the Bonjour folder.

 

Related Articles, References, Credits, or External Links

National Instruments Microsoft

Juniper SRX240 – Firewall Cluster (Active / Standby)

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

HP MSM765zl and 775zl – Initial Setup and Routing

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 ASA 5500 – Sub Interfaces and VLANS

KB ID 0001085 

Problem

You can take the physical interface of a Cisco ASA firewall, (or an ether channel) and split it down into further sub-interfaces. This way you can set multiple VLANs to use this interface as a gateway at the same time whilst still separating the traffic.

In this scenario I’m going to have two VLANs, one for my wired clients, and one for a ‘Guest WiFi’ that I’m setting up. I want the guest WiFi to run in its own separate VLAN, so it can’t touch my corporate network. And I want to NAT both networks to my public IP.

Maximum number of sub interfaces, depends on the hardware model maximum number of VLANs so;

Model
Max VLANS
5506-X 5 (30 with Security Plus)
5506-W-X 5 (30 with Security Plus)
5506-H-X 30
5508-X 50
5510 50 (100 with Security Plus)
5512-X 10 (100 with Security Plus)
5515-X 100
5516-X 100
5520 150
5525-X 200
5540 200
5545-X 300
5550 250
5555-X 500
5580 250
5585-X 1024

Note: Sub interfaces are NOT supported on the ASA 5505. (But you can have up to 20 VLANs with a ‘security-plus‘ licence, or 3 (DMZ restricted) with a ‘base‘ licence).

Solution

To create sub interfaces on a physical interface, that interface must have no settings on it (other than it should not be shutdown).

[box]

 Petes-ASA # configure terminal 
 Petes-ASA(config)# clear interface gigabitEthernet 1

[/box] Then create a sub-interface for each of my VLANs. [box]

 Create Sub interface for VLAN 2 

Petes-ASA(config)# interface gigabitEthernet 1.2
 Petes-ASA(config-subif)# vlan 2
 Petes-ASA(config-subif)# nameif Corp-LAN
 INFO: Security level for "Corp-LAN" set to 0 by default.
 Petes-ASA(config-subif)# security-level 100
 Petes-ASA(config-subif)# ip address 10.2.2.254 255.255.0.0
 Petes-ASA(config-subif)# exit
 Petes-ASA(config)#

Create Sub interface for VLAN 3

Petes-ASA(config)# interface gigabitEthernet 1.3
 Petes-ASA(config-subif)# vlan 3
 Petes-ASA(config-subif)# nameif Corp-WiFi
 INFO: Security level for "Corp-Wifi” set to 0 by default.
 Petes-ASA(config-subif)# security-level 90
 Petes-ASA(config-subif)# ip address 10.3.3.254 255.255.0.0
 Petes-ASA(config-subif)# exit
 Petes-ASA(config)#

[/box]

Note: I’ve manually set the security levels and made the corp-lan interface more trusted.

So my firewall config now looks like this;

[box]

!
 interface GigabitEthernet1
 no nameif
 no security-level
 no ip address
 !
 interface GigabitEthernet1.2
 vlan 2
 nameif Corp-LAN
 security-level 100
 ip address 10.2.2.254 255.255.0.0 
 !
 interface GigabitEthernet1.3
 vlan 3
 nameif Corp-WiFi
 security-level 90
 ip address 10.3.3.254 255.255.0.0 
 !

[/box]

NAT/PAT Traffic From Your Sub-Interfaces

Taking all traffic from both subnets (10.2.0.0/16 and 10.3.0.0/16), and I’m going to NAT both of these to my public IP. (Note: I’m actually going to PAT the addresses, but that’s just semantics).

[box]

Petes-ASA(config)# object network Corp-LAN-PAT
 Petes-ASA(config-network-object)# subnet 10.2.0.0 255.255.0.0
 Petes-ASA(config-network-object)# nat (Corp-LAN,outside) dynamic interface 
 Petes-ASA(config-network-object)# exit
 Petes-ASA(config)# object network Corp-Wifi
 Petes-ASA(config-network-object)# subnet 10.3.0.0 255.255.0.0
 Petes-ASA(config-network-object)# nat (Corp-WiFi,outside) dynamic interface
 Petes-ASA(config-network-object)# exit

[/box]

If you have ACLs you will need to allow the traffic out, and if you want to test connectivity by pinging a public IP address you will need to have ICMP inspection configured on the firewall.

What if you want the WiFi VLAN to have a different Public IP?

If you want to use another public IP from your public range, here is an example of the config;

<[box]

 !
 interface GigabitEthernet0
 nameif outside
 security-level 0
 ip address 123.123.123.123 255.255.255.0 
 !
 interface GigabitEthernet1
 no nameif
 no security-level
 no ip address
 !
 interface GigabitEthernet1.2
 vlan 2
 nameif Corp-LAN
 security-level 100
 ip address 10.2.2.254 255.255.0.0 
 !
 interface GigabitEthernet1.3
 vlan 3
 nameif Corp-WiFi
 security-level 90
 ip address 10.3.3.254 255.255.0.0 
 ! 
 object network Corp-LAN-PAT
 subnet 10.2.0.0 255.255.0.0
 nat (Corp-LAN,outside) dynamic interface
 !
 object network Corp-Wifi
 subnet 10.3.0.0 255.255.0.0
 nat (Corp-WiFi,outside) dynamic 123.123.123.124 
 ! 
 route outside 0.0.0.0 0.0.0.0 123.123.123.124
 ! 

[/box]

OR, If you want the traffic to leave by another public interface (i.e. connected to another ISP) you can do the following;

[box]

!
 interface GigabitEthernet0
 nameif outside
 security-level 0
 ip address 123.123.123.123 255.255.255.0 
 !
 interface GigabitEthernet1
 no nameif
 no security-level
 no ip address
 !
 interface GigabitEthernet1.2
 vlan 2
 nameif Corp-LAN
 security-level 100
 ip address 10.2.2.254 255.255.0.0 
 !
 interface GigabitEthernet1.3
 vlan 3
 nameif Corp-WiFi
 security-level 90
 ip address 10.3.3.254 255.255.0.0 
 !
 interface GigabitEthernet2
 nameif outside-WiFi
 security-level 0
 ip address 234.234.234.234 255.255.255.252 
 ! 
 object network Corp-LAN-PAT
 subnet 10.2.0.0 255.255.0.0
 nat (Corp-LAN,outside) dynamic interface
 !
 object network Corp-Wifi
 subnet 10.3.0.0 255.255.0.0
 nat (Corp-WiFi,outside-WiFi) dynamic interface
 !
 route outside 0.0.0.0 0.0.0.0 123.123.123.124
 route outside-wifi 0.0.0.0 0.0.0.0 234.234.234.235
 ! 
 

[/box]

Setting Up The Switch

This will depend upon the vendor, but essentially if it’s a Cisco Switch you make the uplink switch port a ‘trunk-port’, and either allow ALL or VLAN 2 and 3. Then every wired connection will connect to a port you have setup as a ‘access-port’ on VLAN 2. All the wireless equipment will plug into ports that you have made ‘access-ports’ on VLAN 3.

For other vendors you would need to ‘tag’ VLANs 2 and 3 onto the firewall uplink port. Then ‘untag’ VLAN 2 on all the wired ports. Then finally ‘untagVLAN 3 on all the wireless ports.

See the following article for more information;

HP and Cisco – VLANs and Trunks Confusion!

Related Articles, References, Credits, or External Links

NA