Networking

Showing posts with label Networking. Show all posts

How to Configure a Port Proxy for RDP Connections

Friday, January 27, 2017

I'm working with a small business customer who uses my Hyper-V home lab server to run their lab. They have a Domain Controller and several application servers running behind an AT&T DSL consumer-grade wireless router and they want to be able to RDP directly to each VM. If you run your own home lab, you might want to do the same.

The trouble is, most consumer routers don't allow you to forward the same port to more than one IP address. You can create a port forwarding rule for TCP 3389 (RDP) to TCP 3389 on one, and only one, IP address. On a "real" router you could forward the external TCP ports 33891-33895 to the internal 3389 port on each of the five internal server IPs, but that's not an option here.

Traditionally, there are several ways of handling this problem, each with it's own limitations:

RDP to the one main server and then "leapfrog" to the other computers using RDP from the main server. This can cause confusion about which desktop you're working on, and provides a less than stellar experience.
Change the RDP listening port on all the other computers to use another port (for example, TCP 33891-33895). See How to change the listening port for Remote Desktop. The downside to this is that you will always need to specify the custom listening port when connecting both internally (on the LAN) and externally (from the Internet). This can be troublesome, especially in a larger environment where several admins need to use RDP. "What RDP port do I need to use for SERVER1 again?"
Install and configure Remote Desktop Gateway services on the server hosting HTTPS services. This has a fair amount of overhead and configuration, requires a valid SSL certificate, and RDP clients need to be manually configured to use the RDG for these connections.

A much more elegant solution is to use the netsh utility to configure a port proxy entry in the TCP stack for each server. With this configuration, each server will continue to listen on TCP port 3389 for normal internal RDP connections. External RDP connections to the proxy port, say TCP 33891, will be forwarded to TCP 3389. Brilliant! Here's how to configure it:

Run the following netsh command from an elevated CMD prompt on each server:

netsh interface portproxy add v4tov4 listenport=[ListeningPort] listenaddress=[ServerIP] connectport=3389 connectaddress=[ServerIP]

For example, the following netsh command configures TCP port 33891 to forward to TCP port 3389 for IP address 10.0.0.101:

netsh interface portproxy add v4tov4 listenport=33891 listenaddress=10.0.0.101 connectport=3389 connectaddress=10.0.0.101

Now configure port forwarding for each internal server on the DSL/cable router. Create a custom service for each new port - The external (base) port and internal (host) port both use the new custom port (i.e., 33891, 33892, etc.):

Then configure port forwarding for each of the new custom services to the IP addresses of the servers:

With this configuration, you can still make internal RDP connections to the each server using the traditional RDP port 3389 (no special configuration of the RDP client is needed). All external RDP connections are made to the same public IP address using one of the new custom ports (i.e., 33891):

Getting to Know IPv6

Tuesday, July 16, 2013

My good friend Mark Morowczynski, Microsoft PFE for Active Directory, wrote a three-part series on the Ask Premier Field Engineering (PFE) Platforms blog about IPv6 that is well worth reading.

IPv6 for the Windows Administrator: Why you need to care about IPv6 - Explains why IPv6 is important and covers the #1 thing that most admins do wrong with IPv6: Disabling it improperly.
IPv6 for the Windows Administrator: IPv6 Fundamentals - Covers IPv6 addressing and explains what all those strange numbers and letters mean.
IPv6 for the Windows Administrator: More IPv6: Subnetting, Zones, Address Autoconfiguration, Router Advertisements and IPv4 comparisons - Goes into detail about setting up an IPv6 address scheme, Zone IDs, how clients can potentially get IPv6 address, and a nice comparison between IPv4 and IPv6.

In addition to these articles, Microsoft updated their IPv6 Support in Microsoft Products and Services web site to include all the Wave 15 products.

You can follow Mark on Twitter @markmorow.

Cisco Offers Free Nexus 1000V Integrated Switch for Hyper-V

Thursday, June 20, 2013

Hyper-V 3.0 on Windows Server 2012 offers a new feature called an extensible virtual switch. This feature allows you to replace the Windows integrated virtual switch in Hyper-V with a third-party switch, such as the Cisco 1000V. You can get a quick overview of Hyper-V extensible virtual switches here.

The Cisco 1000V virtual switch provides many advanced capabilities to Hyper-V VMs such as advanced switching (private VLANs, ACLs, PortSecurity, and Cisco vPath), security, monitoring, and manageability.

The following information comes from Cisco's Cisco Nexus 1000V Switch for Microsoft Hyper-V website:

Features and Capabilities

The Cisco Nexus 1000V Switch for Microsoft Hyper-V:

Offers consistent operational experience across physical, virtual, and mixed hypervisor environments
Reduces operational complexity through dynamic policy provisioning and mobility-aware network policies
Improves security through integrated virtual services and advanced Cisco NX-OS features

The following table summarizes the capabilities and benefits of the Cisco Nexus 1000V Switch for Microsoft Hyper-V.
Capabilities	Features	Operational Benefits
Advanced Switching	Private VLANs, Quality of Service (QoS), access control lists (ACLs), portsecurity, and Cisco vPath	Get granular control of virtual machine-to-virtual machine interaction.
Security	Dynamic Host Configuration Protocol (DHCP) Snooping, Dynamic Address Resolution Protocol Inspection, and IP Source Guard	Reduce common security threats in data center environments.
Monitoring	NetFlow, packet statistics, Switched Port Analyzer (SPAN), and Encapsulated Remote SPAN	Gain visibility into virtual machine-to-virtual machine traffic to reduce troubleshooting time.
Manageability	Simple Network Management Protocol, NetConf, syslog, and other troubleshooting command-line interfaces	Use existing network management tools to manage physical and virtual environments

The Cisco Nexus 1000V won the Best of Microsoft TechEd 2013 award in the Virtualization category.

If you're interested in learning more about the Nexus 1000V extensible switch, I encourage you to view the following 2 hour session on CiscoLive365: BRKVIR-2017. - The Nexus 1000V on Microsoft Hyper-V: Expanding the Virtual Edge (2013 London). Free registration is required. Bennial also posted the PowerPoint slide deck for this session on ScribD here.

Best of all it's free to download here! The download itself is for a 60 day trial. I received confirmation from Cisco that after 60 days you have to get a license, but it is free:

Go to www.cisco.com/go/license
Select the License Wizard, Check Product Category, Select Nexus 1000v, Select Add a License to Rehost
Enter the Nexus 1000v Serial Number (obtained from the virtual switch) or the existing PAK (Prod Auth Key)
A license file (PAK) will be generated and emailed to you
Just apply the new license file

How to specify which IP address to use for an Exchange Send Connector

Friday, May 13, 2011

If you have multiple IP addresses on and Exchange 2010 Hub Transport server for the same network, Exchange will always use the preferred IP address for all outbound traffic and consequently, the send connector.

There may be times when you want Exchange to use another IP. Maybe because you already have that IP address configured in your firewalls. Unfortunately, you can't specify the IP address to use in Exchange for a send connector on Hub Transport servers, only Edge Transport servers.

You can, however, install a hotfix on Windows Server 2008 or Windows Server 2008 R2 servers which allows you to use netsh to disallow certain IPs to be used for outbound traffic. The hotfix is required for all versions of Windows Server 2008 SP2 and Windows Server 2008 R2 RTM. It is included in Windows Server 2008 R2 SP1.

Hotfix for Windows Server 2008 SP2: http://support.microsoft.com/kb/975808
Hotfix for Windows Server 2008 R2 RTM: http://support.microsoft.com/kb/2386184/

Once the hotfix is installed, run the following command from an elevated CMD prompt:

Netsh int ipv4 add address <Interface Name> <IP address> skipassource=true

This will cause Windows to disallow the IP address on the specified NIC from being used for outbound network traffic.

PortQry - Simple Command Line Port Scanner

Monday, November 22, 2010

There are many reasons why you may need to use a port scanner to check if a TCP or UDP port is open. Microsoft has a little known utility called PortQry that allows you to perform basic port scanning from the command line.

You can download PortQry from http://www.microsoft.com/downloads/en/details.aspx?familyid=89811747-c74b-4638-a2d5-ac828bdc6983&displaylang=en

Download the PortQryV2.exe package and run it to extract the PortQry.exe program, EULA and readme file. I typically copy PortQry.exe to my %SystemRoot% folder so I can run it from any directory.

Here are some examples of how to use PortQry from the command line:

portqry -n servername -e 80 - Queries remote computer servername to check if it's listening on TCP port 80 (HTTP).
portqry -n servername -p UDP -o 37,88,135 - Queries the remote computer to check if it's listening on UDP ports 37, 88 and 135.
portqry -n 10.0.0.21 -r 1-1024 - Queries the IP address to determine if it's listening on any of the well-known TCP ports. The output will display each port and whether it's listening or not listening.
portqry -n 10.0.0.21 -r 1:1024 | find ": LISTENING" - Same as above, but only lists open ports.

PortQry can also be run in silent mode using the -q switch. The program exit with a returncode of 0 if listening, 1 if not listening, or 2 if listening or filtered. This is useful for batch file processing.

Can't Delete IP Address from Hyper-V Virtual Machine

Tuesday, June 1, 2010

I've had a number of problems with Windows Server 2008 Hyper-V guests that hold onto their original IPv4 address after running SysPrep.

SysPrep is supposed to remove this kind of server-specific information, but for some reason this isn't happening with Server 2008 images. Removal of machine-specific information is called "generalization" and is supposed to happen when you click the Generalize checkbox in SysPrep.

I've seen this cause the following symptoms:

"The IP address you have entered for this network adapter is already assigned to another adapter (microsoft Virtual machine Bus Network Adapter) which is no longer present in this computer"

For this error, do the following:

Open a command prompt and enter set devmgr_show_nonpresent_devices=1
Enter start devmgmt.msc to start Device Manager
In the Device Manager window, click View and Show hidden devices
Under Network Adapters you will see the dimmed conflicting device, probably the Microsoft Virtual Machine Bus Network Adapter. Delete it and you can continue to configure the existing adapter.

The other issue I've seen is when the network adapter hangs onto the imaged machine's IP address and you cannot delete it. In this case, you view the properties of the adapter and see the old IP address as an additional IP address. It looks like you can successfully remove the old IP address, but it still shows up when you view the NIC's properties again.

In this case, you do the following from the Hyper-V host server:

Connect to the VM guest session from the host. You will lose RDP connectivity otherwise.
Open Device Manager
Expand Network Adapters, right-click the misbehaving NIC and select Uninstall
Right-click Network Adapters and select Scan for hardware changes
Reconfigure the new adapter

Worst. AT&T Experience. Ever.

Thursday, September 10, 2009

The EXPTA {blog} is back online! Sorry about the prolonged outage, folks.

This blog is hosted on my own server, which is connected to the Internet using a DSL line from AT&T. I choose to do this instead of hosting it on blogspot because it gives me a lot more flexibility.

I finally decided to cancel my local phone service, since we only use our cell phones anyway, and why pay $25 a month to let cold-callers interrupt our dinner. Trouble is, a provisioned DSL line is normally tied to the landline phone number. To get DSL on its own, it needs to be converted to what AT&T calls a "dry loop". This can be done very quickly at the central office (CO), and then the phone line can be disconnected. When done correctly, the outage is very brief and the DSL customer (me) retains his user accounts, email addresses, and settings. But, when it's done wrong....

Problem #1: Human nature. When making a change request such as this (disconnect local phone service), the AT&T rep taking the call is a salesperson. Salespeople don't make money disconnecting service. Salesperson: "How can I make a buck off this? Ahh, I'll cancel BOTH the local phone service and DSL, and then put in a NEW order for DSL. Cha-ching!" Oh, and don't bother telling the customer (me) that you're going to do this.

Problem #2: Phone mail hell. The work will be performed sometime between 8am-8pm. My DSL was turned off promptly at 8am (of course), but my phone still worked. Several calls throughout the day resulted in transfers to at least three different departments. Apparently none of them work for the same company. "Be patient, sir, your order will be completed by 8pm."

Problem #3: We're closed. At 8pm sharp, my phone service stops, but I still don't have DSL. I called the "broadband customer care" department and find that all the techs have gone home for the day. A supervisor says he'll put me "first on the list tomorrow morning at 8am and we'll call your cell". Guess what?

Problem #4: Wires crossed. Many phone calls (all by me) and a service tech visit to the house (how could it possibly be a problem with my house wiring when it was working before they started screwing around?) results in a trip to the central office. "Oops, we connected the wrong wires."

So, 34 hours later I finally have my DSL service back, albeit with a new account and no access to my old email accounts. Next stop, a call to the Customer Retention department for a bill credit. Grrrrr!

How To Enable Change Notification On All Site Links

Wednesday, March 18, 2009

Normally, there are two replication intervals for Active Directory in a Windows domain: Intra-site (replication between DCs in the same site) and Inter-site (replication between DCs in different Active Directory sites).
Intra-site replication is very fast - typically around 15 seconds. This schedule can be configured via the registry using the following values in the HKLM\SYSTEM\CurrentControlSet\Service\NTDS\Parameters key:

Replicator notify pause after modify (secs)It is a REG_DWORD value of 15 by default
Replicator notify pause between DSAs (secs)It is a REG_DWORD value of 3 by default

See Microsoft TechNet (Active Directory Replication Tools and Settings) for a thorough explanation of what these keys do.Inter-site replication is dictated by the schedule associated with the replication connection in Active Directory Sites and Services. Using this GUI you can specify that the connector never replicates or to replicate once, twice or four times per hour.

Note: The inter-site replication schedule runs based on the server startup time. For example, if the DC starts up at 12:10pm and the replication connector's schedule is set to twice per hour, replication on this connector will occur at 12:10pm, 12:40pm, etc.

But what if you want Intersite replication to occur more frequently than every 15 minutes? For this, you must enable Change Notification on the Active Directory site link. How you do this depends on which OS is on your DC.

For Windows 2003 Domain Controllers:

Open ADSIEdit.msc (in the Windows Support Tools) as a Domain Admin
Open the Configuration naming context
Navigate to Sites > Inter-Site Transports > IP
Right-click the siteLink to modify in the results pane and click Properties
Locate the options attribute and edit the value from 0 to 1
Click OK and repeat for other siteLinks, as necessary.

For Windows 2008 and Windows 2008 R2 Domain Controllers:
You can use the same method as Windows Server 2003 DCs or you can edit the values directly from AD Sites and Services, as follows.

Locate the Inter-Site Transport site link to modify, typically DEFAULTIPSITELINK, in AD Sites and Services
Right-click the site link and choose Properties
Click the Attribute Editor tab
Locate the options attribute and edit the value from 0 to 1
Click OK and repeat for other Site Links, as necessary.

I also wrote two VBScripts for displaying and configuring Change Notification:

DisplayChangeNotification.vbs displays the current value of the options attribute on each site link in the Active Directory domain where it is run.
EnableChangeNotification.vbs will enable Change Notification on all site links in the Active Directory domain where it is run by changing the options value to 1.

Both scripts are in the ChangeNotificationScripts.zip file, located here.

How to Configure IPv6 Using Group Policy

Tuesday, February 10, 2009

Update: I have updated the IPv6Configuration.zip file mentioned below with the new recommendations documented in the article, A 5 Second Boot Optimization If You’ve Disabled IPv6 on Windows Client and Server by setting DisabledComponents to 0xFF.

By default, all modern versions of Windows and Windows Server enable and use IPv6 as the default networking protocol. These versions of Windows will normally use IPv6 for all network communication and will step down to IPv4 as necessary.

You may decide to disable Windows IPv6 for several reasons. Perhaps your IPv4 network doesn't support it, and you want to disable unnecessary protocols. You may have also read that IPv6 breaks Outlook Anywhere on Exchange 2007 Client Access servers.

Most people think that you disable IPv6 by simply unchecking the Internet Protocol Version 6 (TCP/IPv6) checkbox, as shown above. This method disables IPv6 on the particular LAN interface and connection. For other network adapters or connections, users have to repeat the steps to disable IPv6. However, disabling IPv6 this way does not disable IPv6 on tunnel interfaces or the IPv6 loopback interface. It also must be done manually and cannot be instrumented or enforced using Group Policy.

In order to truly disable IPv6, you must disable it in the registry in the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents

Normally, the DisabledComponents value does not exist. If the value does not exist or the value data is 0, IPv6 is enabled on all interfaces.

Microsoft wrote KB article 929852 to document how to disable certain Internet Protocol version 6 (IPv6) components in Windows Vista (and later) manually using the registry. At the end of the article, Microsoft helpfully wrote, "Note: Administrators must create an ADMX file in order to expose the settings in step 5 in a Group Policy setting." Nice. So, I decided to do just that.

I wrote the attached ADMX and ADML files to enable the configuration of IPv6 using Group Policy. Copy each file to the computer you will use to configure the policy.

IPv6Configuration.zip - This ZIP file contains both the ADMX and ADML files:

IPv6Configuration.admx - Copy this file to %SYSTEMROOT%\PolicyDefinitions
IPv6Configuration.adml - Copy this file to %SYSTEMROOT&\PolicyDefinitions\en-US (Replace en-US with your country's language, if necessary)

Now log into the computer and use the Group Policy Management Console (GPMC) to configure the IPv6 settings. The new policy will be located under Computer Configuration > Policies > Administrative Templates > Network > IPv6 Configuration, as shown below:

Group Policy Management Console

Here, you can configure the following IPv6 settings:

Enable all IPv6 components (Windows default)
Disable all IPv6 components (the setting you probably want)
Disable 6to4
Disable ISATAP
Disable Teredo
Disable Teredo and 6to4
Disable all tunnel interfaces
Disable all LAN and PPP interfaces
Disable all LAN, PPP and tunnel interfaces
Prefer IPv4 over IPv6

Note that you must restart the computer for the configuration to go into effect.
Please to enjoy!

How to Disable Subnet Prioritization

Monday, January 26, 2009

Windows uses a scheme called "subnet prioritization" to attempt to reduce network traffic by re-ordering DNS round-robin records so that the records that are "closest" to the host are the only records used.

For example, suppose there are three A records for the same name in DNS, appserver.domain.com. One with IP 10.0.8.100, one with 10.0.15.100, and one with 10.0.26.100.

If a Windows client with the IPv4 address of 10.0.15.20 performs a DNS query for appserver.domain.com, subnet prioritization will re-order the IP addresses so that it will always use the 10.0.15.100 address.

Subnet prioritization is enabled by default in both the Windows DNS server and the DNS client.

DNS server subnet prioritization (AKA, netmask ordering) can be demonstrated using the Windows NSLOOKUP command. Repeated lookups of appserver.domain.com from the client always give the same results:

C:\nslookup appserver.domain.com
Server: dns.domain.com
Address: 10.1.1.10

Name: appserver.domain.com
Addresses: 10.0.15.100, 10.0.8.100, 10.0.26.100

Here, the DNS server is reordering the IP addresses, based on the requestor's IP address. If true DNS round-robin is working, the records would rotate in a (A, B, C), (B, C, A), (C, A, B) fashion. Subnet prioritization obviously throws a wrench in round-robin DNS if you're using that as your load balancing or fault tolerance solution.

To disable subnet prioritization on DNS servers:

Open the DNS Management console

Navigate to the DNS server and open its properties

Click the Advanced tab

Uncheck Enable netmask ordering and check Enable round robin

Click OK

But this only solves half the problem because the Windows client will reorder the DNS results, too. Repeated nslookups will now show that the IP address for appserver.domain.com is rotating correctly, but pinging appserver.domain.com from the client will still always resolve to 10.0.15.100. You must still disable subnet prioritization on the client.

To disable subnet prioritization on Windows DNS clients:

Run Regedit

Navigate to HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters

Click Edit > New > DWORD Value

Name the new value PrioritizeRecordData (its value data will be 0)

Close Regedit

Note: Both of these changes go into effect immediately. There is no need to restart services or the computers.

Getting Networking to Work in Hyper-V Beta

Friday, March 7, 2008

First, I thoroughly recommend reading Ben Armstrong's article, "Understanding Networking in Hyper-V," for an explanation of how networking changes on a Hyper-V enabled host. He explains that the real NIC on the host is converted to a virtual network switch and a new virtual NIC is created on the host to access the network using the virtual switch.

Sometimes networking doesn't get setup properly on the host when the Hyper-V role is installed. Here's how to fix it:

When networking is not configured properly after Hyper-V is installed, you'll see only the one physical adapter in Network Connections (assuming, of course, that you have only one network adapter).

1. Open network properties of the NIC and uncheck all the connections on the adapter (Client for Microsoft Networks, IPV4, IPV6, ...everything) and click OK. Obviously, this will disrupt network communication to and from the server, so plan this work accordingly.

2. Click Virtual Network Manager in the Hyper-V console and create a new external network bound to the real NIC. This will convert the real NIC on the host to a Microsoft Virtual Switch and create a new virtual NIC for the host to use for its network adapter (see step 4).

3. In each Hyper-V guest, select the External Virtual Network for the VM's network adapter.

4. Back on the host, you will now see two NICs in the Network Connections window. Local Area Connection (the original real NIC) is now a Microsoft Virtual Switch and is using only the Microsoft Virtual Network Switch Protocol. You will also see a new virtual NIC (usually named "Local Area Connection 3," in my testing). I've renamed it here to Virtual Local Area Connection.