Part of the migration at the office is migrating everybody’s mail to the new mail system. Our previous system implemented RPC over HTTPS, allowing remote access to the exchange server using an HTTPS proxy server. This is great for the number of remote users we have. The new company uses RPC over HTTP, but does not have it publically accessible at this time, which means all users have to be “on the network” to access their email, short of using OWA that is.
In doing this, I decided to move our virtual VPN server, back to a physical server due to the load, and the number of connections we’d now have to host again. Configuring remote access on Windows 2003 is usually a case of a few clicks.
Tonight was a little different. Usual steps are as follows:
- Install Windows
- Do your windows updates (as required)
- Install “Routing and Remote Access” service from the “Add/Remove Windows Components”
- From the “Administration” menu off the “Start” menu, select “Routing and Remote Access”
- Right click the server, and select configure, and follow the wizard.
That’s the usual process anyway. Unfortunately I came across a little stumbling block. Whilst the server was accepting remote connections, it wasn’t routing the connections anywhere but the internal network. Further investigation showed that the server was handing out IP addresses in the 169.254.0.0/16 network range. This is Microsoft’s “can’t find a DHCP server” range. Along with the IPs being assigned in that range, I was also seeing the following entries in the log files
Event Type: Warning Event Source: RemoteAccess Event Category: None Event ID: 20169 Date: 3/3/2009 Time: 12:34:06 AM User: N/A Computer: DALVPN01 Description: Unable to contact a DHCP server. The Automatic Private IP Address 169.254.103.168 will be assigned to dial-in clients. Clients may be unable to access resources on the network. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
This was a little frustrating, as it meant I could access the corporate office, but couldn’t access anything else. “Anything else” would include the internet, as well as the email servers located at the main branch.
I started comparing the settings between the old virtual server, and the new physical server, from the DHCP Relay settings, and all looked good there. Then it struck me. The server had dual NIC cards that were configured in a team, as well as a DRAC. The dual NICs were configured as a team, which redundancy on the switch side, but the DRAC was not yet plugged in. I was making the assumption that the server software would automatically assume that it could get an IP from the interface that was up, rather than any random interface.
I found the issue hidden under the properties of the server settings, rather than the DHCP relay settings. Right clicking on the server, and selecting properties, then navigating to the “IP” tab, you can select the interface that you want to attempt to issue DHCP requests out on.
This little drop down, selecting “Team 1” instead of the “Local Area Connection 3”, allowed the server to correctly route the DHCP, DNS, and WINS requests out the right interface. Logic would depict using the active interface, but… Everybody has come to know that Microsoft isn’t always logical, and there was probably some exotic reason to have set it to do this, but I daren’t try figuring it out myself.
As always… disclaimer