If you use the Cisco VPN Client with Windows XP, you may have noticed that all of your DNS requests go via the VPN, rather than the local network. You can test which DNS server you are using through the use of the NSLOOKUP command. The Cisco VPN Client creates a disabled Local Area Connection, to which it assigns null values until connected. When you connect using the client this connection profile becomes enabled and is set with the appropriate DNS, WINS, gateway and IP address from the other end of the VPN, usually by a DHCP server. By default when you install the client the priority of the Cisco VPN connection is higher than the default local connection assigned to your ethernet NIC or wireless card and it is this that causes two major problems for users:

You cannot connect to local named servers, but you can access them by IP. The only common workaround suggested for this (see Google Groups) is to manually add them to your HOSTS file. This is not a solution that you could widely roll out to a network of users, and is a dirty hack.
Your DNS resolution is SLOW. This is because your request has to go to the DNS server at the other end of the VPN, before being returned to you locally, whereby it sends you out over your local LAN to the internet as normal via your broadband router.

To test which DNS server you are using by default when connected normally, first disconnect from the VPN client and pop open a command window:

Start -> Run -> type "cmd"
type "nslookup".

You'll see something along the lines of:

C:\Documents and Settings\Administrator>nslookup
Default Server: 192.168.0.1
Address: 192.168.0.1

>

Type "exit" and then open up your Cisco VPN Client, connect via VPN, and repeat the NSLOOKUP command. You'll see the change to your default DNS server:

C:\Documents and Settings\Administrator>nslookup
Default Server: core.office.junto.co.uk
Address: 172.30.2.1

>

Now all DNS requests will go through the VPN, and not your local router. Slow and pointless (security caveats aside). Why does the Cisco VPN Client change this, and can we alter it at the client level? We don't really want to bother our over worked Cisco technician back in the office, and often he's an expensive contract resource anyway.

Most importantly why does the Cisco VPN Client connection always seem to have a higher priority than the standard local ethernet connection or wireless connection under Windows XP? My initial thought was that Cisco designed it to be this way, and there was no way to change it, but now I believe that the simple answer is one of installation order. Hence, as the connections are installed, the last one to be installed seems to be given the highest priority. Someone more knowledgeable with XP networking might be able to clarify this.
Whether or not this is true or not, the fix is to change the priority of the connections. A bit of digging around gives you some advanced settings to network connections:

Start -> Control Panel -> Network Connections
Then under the menu option Advanced -> Advanced Settings
Change the priority of your default local connection, to be above that of the Cisco VPN Client. The Cisco VPN Client often installs for most people as "Local Area Connection 2".

Now try the NSLOOKUP command again. You'll see something along the lines of:

C:\Documents and Settings\Administrator>nslookup
Default Server: 192.168.0.1
Address: 192.168.0.1

>

You're back to using your local DNS server, but still connected to the VPN. Problem solved. Nice! You should now be able to see your local servers inside your LAN by name, plus general browsing should be faster.
Some caveats:

There may be security considerations to allowing DNS requests via the local LAN rather than the VPN. DNS works so that it rolls down the list of DNS servers, so the local LAN will ask the world for an internal DNS name first. That could give information away in terms of your local private LAN set up.
I'm using an up-to-date-patched version of Windows XP Professional SP2
I'm using the Cisco Client 4.0.4. Newer versions have given me grief.
In the properties of the VPN profile in question (Cisco VPN Client -> Connection Entry -> Modify) the Transport tab has the option "Allow Locale LAN Access" checked.
This may also be a solution for other VPN clients, but I haven't tried it.

Share

An article by Shawn

No Comments

Nov
17
2011

Development

Prevent ASP.NET web.config inheritance, and inheritInChildApplications attribute

If you have ever had the scenario where you have a main ASP.NET web application and then need to create one or more sub virtual folders that contain completely independant applications (different authentication, error pages, etc), then you have probably run up against the need to prevent the normal web.config inheritianace. Do do this is pretty simple, just setup the PARENT web.config like this

<!-- Root web.config file -->
<?xml version="1.0"?>
<configuration>

  <location path="." inheritInChildApplications="false"> 

    <system.web>

      <compilation debug="false" />

      <!-- other configuration attributes -->

    </system.web> 
  </location>
</configuration>

The one catch when doing this is that you'll probably notice Visual Studio compain about the "inheritInChildApplications" attribute. Turns out this is because the Schema XSD files for web.config that shipped with VS2005/2008/2010 left out support for this attribute (Note: this doesn't prevent your app from work, it just means VS IDE will complain).

To fix this, open up the following files located in %ProgramFiles%\Microsoft Visual Studio XX\Xml\Schemas (XX is 8.0, 9.0, or 10.0 depending on your version)

DotNetConfig.xsd
DotnetConfig20.xsd
DotnetConfig30.xsd
DotnetConfig35.xsd

For each of the files -- Find the <xs:element name="location"> tag and change it to look like this

<xs:element name="location">
  <xs:complexType>
    <xs:choice>
      <xs:any namespace="##any" processContents="lax" />
    </xs:choice>
    <xs:attribute name="path" type="xs:string" use="optional" />
    <xs:attribute name="allowOverride" type="small_boolean_Type" use="optional" />
    <xs:attribute name="inheritInChildApplications" type="xs:boolean" use="optional" />
  </xs:complexType>
</xs:element>

Basically what you are doing is adding this one line to that complex type declaration

<xs:attribute name="inheritInChildApplications" type="xs:boolean" use="optional" />

And thatsit -- you're good to go.

Share

An article by Shawn

No Comments

Nov
9
2011

Scripting // Utilities // Windows // Windows 7

Sudo for Windows

With the existance of UAC in the windows world, I find my self looking for easier ways to run a command as administrator (usually via command line) without needing to turn off UAC.

Here are some useful links that helped me solve this very issue

Elevation Power Toys

http://technet.microsoft.com/en-us/magazine/2008.06.elevation.aspx (note, you also need to sysinternals suite installed in "%ProgramFiles%\Sysinternal Suite"

Elevate Utility

http://code.kliu.org/misc/elevate/

Sudo for windows

http://sourceforge.net/projects/sudowin/

Share

An article by Shawn

No Comments

Nov
2
2011

Development

ASP.NET HttpModule Event Life cycle

MSDN Article: http://msdn.microsoft.com/en-us/library/ms178473(v=VS.80).aspx

In my recent quest to integrate support for SiteMinder into the ASP.NET Membership process I found myself looking into the details of ASP.NET Http Modules. Once of the areas that I spent time on was understanding the exact order of events in the life cycle of a module. Here is what I found.

The HttpApplication is usually un-heard of and it works quietly behind the scenes - well not really. If you have written a HttpHandler or HttpModule or any application with some sort of complexity before - you probably already know what its all about. The HttpApplication is the base class for all ASP.NET application objects, therefore, an HttpApplication class is created for each request. However, not to get too deep into the world of the HttpApplication, I want to focus this post on the sequence of events that are executed - its pipeline.

BeginRequest
AuthenticateRequest
PostAuthenticateRequest
AuthorizeRequest
PostAuthorizeRequest
ResolveRequestCache
PostResolveRequestCache
PostMapRequestHandler
AcquireRequestState
PostAcquireRequestState
PreRequestHandlerExecute
PostRequestHandlerExecute
ReleaseRequestState
PostReleaseRequestState
UpdateRequestCache
PostUpdateRequestCache
EndRequest

Any HTTP module that subscribes to an HttpApplication event must implement the IHttpModule interface, also if you look at the list you will notice that each event has a corresponding post event. i.e AuthenticateRequest to PostAuthenticateRequest. These posts events are executed after its parent event has completed, therefore, PostAuthenticateRequest is raised after the AuthenticateRequest.

BeginRequest
This is the very first event that is raised when ASP.NET responds to a request and it is always raised. Listen to this event for new requests.

AuthenticateRequest
As the name implies, this event fires on authentication of the user. Therefore, if you would like to know who is accessing your site, the "Post" of this event would be ideal to set a listener. It simply states that the request has been authenticated or the identity of the user has been established.

AuthorizeRequest
Authorizing the request is the next step right after the request has been authenticated. Trap "Post" of this event to determine if the user is authorized to access the particular resource or not.

ResolveRequestCache
Ok, it gets tricky. This event occurs after the authorize event and data is requested from cache. If the cache exist, the event handler such as a page will be bypassed and the cached request will be served. You can do several things here. Blow your mind!

PostMapRequestHandler
A post event with no "Pre" - at least no access to it. This event get raised after the request has been mapped to a handler. So if you would like to know which handler will be executed, this is the place to be.

AcquireRequestState
This executes right after the handler has been mapped to the request and it grabs the current state such as session state. Trap the "Post" event if you need to mess around with the session.

PreRequestHandlerExecute
As the name implies, this event is raised just before the request handler that was mapped earlier on is executed such as a ".aspx" or ".asmx" page.

ReleaseRequestState
At this point in time all mapped handlers have been executed and state modules will start saving state data as required.

UpdateRequestCache
Completely opposite off the above, this event is raised to signal caching modules to save response data which may be used in future request during the ResolveRequestCache phase.

EndRequest
It has to end somewhere. The EndRequest is the last event raised.

I hope this post has helped you understand how the HttpApplication pipeline flows and also help you understand which events to trap to enable you to perform some tasks at the right time.

Share

An article by Shawn

1 Comment

IT Ramblings

Tool for working with .NET config file transforms

Multiple app.config files (just like web.config files)

Connection via Cisco VPN Client stops local DNS resolution

Prevent ASP.NET web.config inheritance, and inheritInChildApplications attribute

Sudo for Windows

ASP.NET HttpModule Event Life cycle

RecentPosts

IT Ramblings

Tool for working with .NET config file transforms

Multiple app.config files (just like web.config files)

Connection via Cisco VPN Client stops local DNS resolution

Prevent ASP.NET web.config inheritance, and inheritInChildApplications attribute

Sudo for Windows

ASP.NET HttpModule Event Life cycle

Tag cloud

RecentPosts