There are times when you will need to have multiple IP addresses on a server.  It could be for an additional receive connector in Exchange, or for another website in IIS, among other things.  This is not recommended if the server is a domain controller and/or DNS server.  Best practice for a DC/DNS server is to have a single NIC (or NIC team) with a single IP address.  Having more than one IP can and does cause DNS resolution issues, logon issues for clients, and other Active Directory weirdness.  However, I realize that there are situations where you don’t have any other way of accomplishing an objective, and you simply must have multiple IPs on your DC/DNS server.  I have been IN that situation more than once, which is the reason for this post.

Adding another IP address on a server can be accomplished either by adding a secondary IP address on an existing network adapter (shown above), or by adding another network adapter with its own IP address.

In any case, by default, the server will register all assigned IP addresses in DNS.  This may cause problems if clients resolve an IP for the server other than the one they need to access whatever service they are trying to use.  For example, if you have multiple IP addresses on an Exchange server, but only the first IP address bound to the default receive connector, clients running Outlook that were given the secondary IP address by DNS would have trouble connecting to Exchange.

There are several ways to prevent registration of multiple IP addresses in DNS, depending on the configuration (secondary IP or NIC) and role of your server.

Scenario 1: Windows Server with multiple network adapters; no secondary IP addresses on either adapter, nor is the server a DNS server.

Resolution: In this situation, the only action you should need to take is to prevent the server from registering the address from the 2nd NIC.  You can do that by going to the properties of the connection –> IPv4 settings –> Advanced button –> DNS tab.  Then, UNcheck the “Register this connection’s addresses in DNS” checkbox, as shown here:

Scenario 2: Windows Server with multiple network adapters running DNS server role.

Resolution: First, perform the same action as the resolution for scenario 1, to prevent the server from registering the 2nd NIC address in DNS.

Also, because the server is running DNS, you must configure DNS to only listen on the primary IP address.  By default, a Windows server running DNS registers all IP addresses that are being used by DNS.  To prevent this, open the DNS console right-click on the DNS server name on the left side and go to Properties –> Interfaces tab.  From here, select the radio button which says “Only the following addresses”.  Then, if necessary, add the primary address to the list below and remove all other IP addresses.  Here is an example:

Scenario 3: Windows Server with single network adapter and multiple IP addresses

This is the same as the example at the top of this post.  In this case, there is not a clean way to prevent registration of the 2nd IP address in DNS.

If you are in this situation, it would be best to remove the secondary IP address from the adapter and set the IP on another adapter.  Then, you can just follow the resolution for scenario 1 or 2.

If you absolutely must configure the server this way and you cannot add another network adapter, then you CAN use the resolution from scenario 1 and prevent the server from registering its addresses in DNS.  However, after that, you may have to go into DNS and manually create a DNS entry in the forward lookup zone for the server.  Any servers from recent years have at least 2 NICs in them, and lately are even being shipped with 4 onboard NICs.  So, having an extra NIC available won’t usually be an issue.

Another way to prevent dynamic registration of DNS records on a server (2000 and 2003, that is) is to modify the registry using the following Microsoft KB article:

http://support.microsoft.com/?id=246804

According to the article, it can be done globally, affecting all NICs on the server, or on a per-NIC basis.  If you decide to try this option, be CAREFUL!

When you set up a unicast Network Load Balancing (NLB) cluster, a large amount of broadcast network traffic will be generated on any switch to which a cluster node is connected. This is normal behavior for a unicast NLB cluster. You may not even notice this traffic unless you are running a packet capture from a machine connected to the same switch as the cluster nodes.

Normally, a switch builds a MAC address table by learning what ports a MAC address is communicating on. This automatic learning process only works if a given MAC address is unique across all the ports on a switch.

Because nodes in a unicast NLB cluster all share a common cluster MAC address, the network switch to which they are connected cannot learn which port the MAC address is tied to. Therefore it is never able to add the cluster MAC to its table. As a result, all traffic going to the cluster MAC is always broadcast out all switch ports.

This may or may not be a problem, depending on the amount of traffic going to your cluster and the amount of other traffic which is already being handled by the network switch. If it is a problem, there are several ways to resolve it.

1. Switch to a multicast or multicast IGMP NLB cluster. You will need to make sure your switches support multicast for this to work. Cisco switches with a relatively recent IOS should have this capability, but you should check first, to be sure.

2. Move the unicast NLB cluster nodes to a separate switch, where they are the only connected devices.

3. Set up a separate VLAN or network (dedicated router/firewall interface) just for the cluster, which will contain the broadcast traffic.

4. Add static MAC table entries on your switch to tell it which ports are being used by the cluster nodes. This way, traffic going to the cluster nodes would only be sent out the applicable ports. Each time you add another cluster node, you would also need to add an entry to the switch MAC table.

Option 4 is the easiest, and one that I have used in production on a small cluster.

All of these options will work; it’s really just your preference as to which one you use. As long as you document it, you’ll be in good shape in any case, right?

Here are some useful links regarding NLB:

http://technet.microsoft.com/en-us/library/bb742455.aspx

http://technet.microsoft.com/en-us/library/cc786562%28WS.10%29.aspx

http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a0080a07203.shtml

Setting up RADIUS authentication between Cisco devices and Network Policy Server (NPS) in Windows Server 2008 is a bit different than in previous versions of Windows.

Here is a technet page with lots of good info on NPS:

http://technet.microsoft.com/en-us/network/bb629414.aspx

For now, I am just going to list the instructions needed to get up and going with NPS to allow your server to act as an authentication point for your Cisco switches/routers. This may work with other devices that can use radius authentication, but I have not tested it. YMMV.

1. Install the Network Policy Server service. It is a component under ‘Network Policy and Access Services’.

2. Open the Network Policy Server console from Administrative Tools.

3. Create a new radius client for the Cisco device. The process for this is very similar to the process in Server 2000/2003. You just need the device IP, choose the “radius standard” type, and make up a shared secret.

4. “Register server in Active Directory” by right-clicking on the “NPS (local)” item in the console. This will allow NPS to query AD when an authentication request comes in.

5.  Next, create a “Connection Request Policy”.  This is the step that is new to the process, and was not required before Server 2008.  Before, this was integrated into the remote access policy, as it was previously called.  The connection request policy doesn’t need to be anything complex.  The first step is to set the network access server type to “Unspecified”.

Next, add at least one condition to the policy.  I usually use the “day and time restrictions”, and then set it to ‘permitted’ 24×7.  Obviously, the condition(s) you choose should conform to your company’s security policy, so you may need something different here.

Finally, On the Settings tab, under Authentication, choose the radio button for “Authenticate requests on this server”.

6.  Create a Network Policy, formerly known as a remote access policy in previous versions of Windows Server.  On the Overview tab, configure the policy to use the network access server type of “Unspecified”.  In addition, set the access permission setting to “Grant Access”.

On the Conditions tab, add at least one condition.  Typically, this will be the Windows Group that is allowed to log in to the network devices.  As I said before, you may need to use different conditions than I show here due to your company security policy.

On the Constraints tab, the only change you should need to make is to enable the authentication method of “Unencrypted authentication (PAP, SPAP)”

Lastly, on the Settings tab, under Encryption, make sure that the “No Encryption” option is enabled.

7.  Point your network device(s) at this server for authentication.  The method for doing this varies depending on the make and model of your device.  With recent IOS images on Cisco switches, the commands will look something like this.

aaa new-model

aaa session-id common

aaa authentication login default group radius local

radius-server host 10.0.0.1 auth-port 1812 acct-port 1813 key putyoursecretkeyhere

8.  Finally, test it!

When testing access to your mail server from outside, you may notice that the SMTP banner looks like this:

This is just a symptom of the problem, which is that the SMTP traffic inspection rule is interfering with the SMTP data stream.  Another symptom would be to see email messages destined for this server seemingly stuck in the SMTP queue on a server outside the network.  This can ultimately cause delayed and undeliverable mail, especially for larger messages, such as those with attachments.

The resolution for this problem is to disable the traffic inspection rule for SMTP/ESMTP on the Cisco PIX or ASA firewall.

On a PIX, this can be done from the command-line using the “no fixup protocol SMTP 25” command.  It can also be disabled from the PIX Device Manager (PDM).

On an ASA, it’s a little different.  From the command line (assuming your policy map is named “global_policy” and your class is named “inspection_default”):

CiscoASA(config)#policy-map global_policy
CiscoASA(config-pmap)#class inspection_default
CiscoASA(config-pmap-c)#no inspect esmtp 

From the Adaptive Security Device Manager (ASDM):

1.       Go to Security Policy –> Open the inspection rule:

2.       Go to the Rule Actions tab and uncheck the box next to ‘ESMTP’

3.       Test from outside the PIX/ASA again by telnetting to port 25; your SMTP banner should now look like this (I have masked the name of the server for privacy).

That’s it.  I have made it standard practice to just disable this inspection rule on all Cisco ASA firewalls that I deploy to avoid problems.

Posted via email from Aaron Johnstone

1.  Log in to the Cisco ASDM
2.  Go to the Wizards menu and run the VPN Wizard.
3.  Choose the ‘Remote Access’ type on the VPN Tunnel Type page:

4.  Choose “Cisco VPN Client” for the VPN client type.
5.  Set your pre-shared key and your Tunnel Group Name
6.  Choose the client authentication method, either using the local user database or an AAA server group
7.  Add a DHCP pool to be used for users connecting using a VPN client; use a different subnet than one already in use on your LAN

8.   Configure the DHCP scope options, such as DNS, WINS, and default domain name
9.   Set the IKE and IPSec policies; I normally use the defaults, which currently are 3DES-SHA
10. Set the Address Translation Exemption and split tunneling options.  Typically, I use the internal network that the VPN-connected client will need access to and enable split tunneling.
11. Click Next, then Finish.
12. Go check the NAT exemption rules.  You should have a rule on the inside interface, exempting any traffic that is going to the VPN subnet (in this case 10.0.2.0/24) from NAT.  Should look like this:

13. That is it; you are done!  You should be able to set up your Cisco VPN client, connect to the network, and test by pinging one of the servers on the internal LAN subnet.

Posted via email from Aaron Johnstone

1. Install the Internet Authentication Service (IAS) Windows component

2. Open the IAS console

3. Add the Cisco ASA as a RADIUS client

4. Edit the remote access policy in the IAS console as needed; enable “Unencrypted authentication (PAP, SPAP)” on the Authentication tab of the profile

5. Connect to your ASA (assuming you are using the ASDM)

6. Go to the Properties tab, then to AAA Setup à AAA Server Groups

7. Create new server group

8. Add a server to the group

9. Test the authentication

10. Go into your VPN settings on the ASA (General à Tunnel Group à properties of the remote access VPN)

11. Go to the General à Authentication tab and change the Authentication Server Group property to the new AAA Server Group that you just created

12. Check the box to enable LOCAL authentication if the server group fails

13. Test it with an Active Directory user account from outside using the Cisco VPN client

Posted via email from Aaron Johnstone

tcpdump | grep isakmp

This displays all packets passing through the tcp/ip stack on the linux server, pipes the output to the “grep” command, and ends up only displaying packets which are related to “isakmp”, the key exchange when attempting to establish an IPSEC PSK VPN connection.  Use other strings after ‘grep’ to find other types of packets.  Or, leave off the pipe and grep if you want to drink from a firehose. :-)

Posted via email from Aaron Johnstone