May 25

Solving PPTP VPN Error 619 when behind a TMG 2010 firewall

I was recently configuring a test environment which had a Microsoft Threat Management Gateway (TMG) 2010 firewall between the private network and the Internet.  From a test Windows 7 client I was trying to establish an outbound PPTP VPN – but I kept getting Error 619 “A connection to the remote computer could not be established”.


I knew the VPN connection was OK, as when I ran it from the other side of the TMG firewall it connected straight away.

After digging around a bit I discovered that although I had set up a rule in TMG to allow PPTP requests through (from the Internal network to the External network in my case), there was another setting necessary to enable this to work (which was not obvious).


I found that disabling the PPTP FIlter on the PPTP protocol in TMG 2010 resolved this problem.  To change this setting, do the following:

1. Open Forefront TMG Management console


2. On the right hand side, click on the Toolbox tab, click on Protocols, expand VPN and IPSec, right click on PPTP and click Properties



3. Click on the Parameters tab and uncheck the PPTP Filter option in the Application Filters section:



4. Click OK and apply the change in TMG, then re-test the VPN, it should work now.

I haven’t got to the bottom of the ‘why’ behind this change but I hope it saves someone else the hours it took me to solve this problem.


Permanent link to this article:

Sep 06

Solving ‘An exception occurred in publishing: No such interface supported (Exception from HRESULT: 0×80004002 (E_NOINTERFACE)’ with Visual Studio 2012 RC

So I’m using Visual Studio 2010 RC and loving web deploy as a simple way to publish my projects to different environments.  However a problem cropped up today after installing some web tooling updates:

‘An exception occurred in publishing: No such interface supported (Exception from HRESULT: 0×80004002 (E_NOINTERFACE)’

I couldn’t even open the publish settings dialog to see if anything was wrong in there.  I tried restarting Visual Studio, then running it as Admin, no change.  I eventually found the following steps on a forum which resolved the problem for me:

  1. Run Command Prompt as Administrator
  2. regsvr32 actxprxy.dll
  3. Restart Visual Studio

And hey presto, project publishing was working again!

Hopefully this will be of use to someone else out there banging their head against a brick wall trying to figure this one out.

Permanent link to this article:

Aug 22

Configuring multiple public DHCP IP addresses on a Linksys WRT54G with OpenWrt

I hit a problem the other day whilst trying to map a bunch of public IP addresses (provided by Virgin Business) to various services within the network.  Essentially I’m running a VMWare ESXi server with several web servers on, and I want to use the public IP addresses to expose these servers to the Internet through the business broadband connection.

Rather than splash out on some expensive networking kit, I decided to have a go at hacking with OpenWrt (an open-source mini-Linux router firmware which can run on number low-end network devices).  I decided to plumb for a new Linksys WRT54G, as these are renown for their support of firmware upgrades like OpenWrt (also dd-wrt and tomato to name a few).

The Challenge

When you buy public IP addresses from your ISP, most will hand you a static block which are assigned specifically to your account.  However, some ISPs (Virgin Business in my case), assign your public IPs by DHCP (I initially bought 5).  So every time you connect a different device to the cable modem their DHCP server hands out a different public IP address.  Whilst this seems all very nice, it makes life more difficult when configuring a router to listen on all of those addresses.   DHCP hands out a public IP and stores the hardware MAC address of the device requesting an address in it’s lease table.  The problem with trying to grab more than one address from a single router is that it only has one physical network port (for WAN), and therefore only one hardware MAC address.  The trick here is to create multiple virtual interfaces in the router, each with their own (made up) MAC address, so they can each make a DHCP request to the ISP.

The Hardware

It turns out that there are a plethora of models of Linksys WRT54G, some with different hardware and supporting different firmware features.  The way to check is to turn the router upside down:


(N.B. I have highlighted the area to look at with the red box.)

In my case I had a WRT54GL v1.1, which I bought from eBuyer for £45.

The Firmware

I originally looked at tomato, but the project seems to be languishing and gathering Internet dust.  I settled on OpenWRT because I found the kmod-macvlan package which allows you to create virtual MAC interfaces on the router, which is exactly what I needed.  I followed the installation instructions here (scroll down to the Installing OpenWRT section).

Now, this is important: you must use the bcrm47xx targeted build of OpenWRT to get access to the kmod-macvlan package (this took me a while to figure out).  The one I used came from here:

After flashing your device (either via SSH if enabled, or via the web GUI), I suggest you enable the SSH daemon, life gets much easier that way.


Here’s an overview of my network setup:


OpenWRT comes with a package manager called opkg which is incredibly useful for installing/managing additional packages.

opkg update
opkg install ip
opkg install kmod-macvlan

This will get the latest list of packages from OpenWRT and install ip and kmod-macvlan packages which we need to configure the virtual MAC interfaces.

Next I modified /etc/rc.local to create the virtual MAC interfaces:

# set up virtual mac addresses as aliases on the main WAN i/f eth0.1

ip link add link eth0.1 eth2 type macvlan
ifconfig eth2 hw ether 58:55:ca:23:32:e9

ip link add link eth0.1 eth3 type macvlan
ifconfig eth3 hw ether 5d:a4:02:04:24:0d

ip link add link eth0.1 eth4 type macvlan
ifconfig eth4 hw ether 8C-89-A5-57-80-E7

ip link add link eth0.1 eth5 type macvlan
ifconfig eth5 hw ether 58:4f:4a:df:40:03

ifup -a

# default route
route add default gw dev eth0.1

exit 0

This script configures 4 additional virtual interfaces on top of the main WAN interface (eth0.1), each with it’s own unique MAC address (you can generate a random MAC address using the instructions here.  I’ve added a default route to Virgin’s router to make life easier when it comes to configuring the firewall (you can find out what your’s is by running ifconfig before making any of these changes).

For each new WAN interface I added a section to OpenWRT’s network config (in /etc/config/network):

config 'interface' 'wan2'
    option 'ifname' 'eth2'
    option 'proto' 'dhcp'
    option 'defaultroute' '0'
    option 'peerdns' '0'
    option 'gateway' '

This maps the WAN2 interface onto the eth2 hardware device, and specifies that it should obtain an address using DHCP.  The route and gateway entries are to force all outgoing requests through the main WAN interface (eth0.1).

After saving these changes you’ll need to reboot your router (use reboot –f).  You can then check the status with ifconfig – look at each interface and check they all have public IP addresses.


The next step was to configure some Network Address Translation (NAT) rules in the firewall to forward traffic coming in on certain public IPs to the relevant hosts on my internal network.  This was achieved relatively easily by adding the following sections to OpenWRT’s firewall config (in /etc/config/firewall):

config zone
    option name             wan1
    option network          'wan1'
    option input            REJECT
    option output           ACCEPT
    option forward          REJECT
    option masq             1
    option mtu_fix          1

# forwards from 1st WAN i/f to SP2010 Web01
config redirect
    option src              wan1
    option src_dport        3389
    option proto            tcp
    option dest_ip

The first block configures a firewall zone named wan1 which maps to the wan1 network, with some default rules (e.g. reject all input by default, accept all output by default).  The second block forwards tcp traffic on port 3389 (remote desktop protocol) from wan1 to a local IP of  This happens to be a SharePoint 2010 web server sitting on the ESX host.

Tidying Up

I had one other problem which was that my Linksys box was sitting on the 192.168.0.x network but needed an additional interface to talk to the Virtual Machines on the ESX server.  This was simply achieved by adding an alias section to the OpenWRT network config (in /etc/config/network):

config 'alias'
    option 'interface' 'lan'
    option 'proto' 'static'
    option 'ipaddr' ''
    option 'netmask' ''

After another reboot of the router everything was looking good.

Next Steps

The next thing I want to get working is OpenVPN server running on the Linksys, so I can support remote VPNs into the local network.  Naturally there’s a package for this, but it looks like it needs a bit of configuration, as always.

Happy hacking!

Permanent link to this article:

Feb 04

Claims Proxy – A C# Library for Calling Claims Protected Web Services

The ClaimsProxy library enables you to get a WIF cookie collection for a SharePoint site which is protected by Claims Based Authentication. It assumes that ADFS is configured as the Trusted Identity Token Issuer and that the down-stream identity provider is based on the StarterSTS / IdentityServer project.

In some recent work I needed to call some SharePoint 2010 web services from a client outside of the SharePoint farm.  Using traditional network credentials and Windows Authentication this was a straightforward matter, for example:

ICredentials credentials = new NetworkCredential('username', 'password', 'domain');
SharepointUserGroupsWCF.UserGroupSoapClient client = new SharepointUserGroupsWCF.UserGroupSoapClient();
client.ClientCredentials.Windows.ClientCredential = (NetworkCredential)credentials;
client.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;
client.Endpoint.Address = new EndpointAddress(webPath + "/_vti_bin/usergroup.asmx");

XElement groupXml = client.GetGroupCollectionFromSite();

However, when the target service is protected by Claims Based Authentication, it’s not so straightforward to call such services.  In my scenario I had a SharePoint 2010 site protected in a web application configured with Claims Based Authentication.  I had configured SharePoint to direct authentication to ADFS (Microsoft Active Directory Federation Server), and then I had a custom claims provider configured based on Dominick Baier’s Identity Server  open source STS product (formerly StarterSTS), however my approach could easily be adapted to work with any number of final claims providers.

Even if you just want the code, read this bit first.

I’ve implemented the code as a .NET 4.0 assembly, although it should be relatively easy to get it to compile under .NET 3.5.  The overall approach works as follows:

  • Use username + password to request a symmetric token from our custom STS (you could get a Windows token here or whatever you are using) – set the realm to that configured for ADFS
  • Use that token to request a bearer token from ADFS – set the realm to the SharePoint site realm as configured in ADFS
  • Use the token from ADFS to authenticate with SharePoint
  • From the resulting authentication response, extract the WIF (Windows Identity Foundation) cookie for authentication (commonly named FedAuth)
  • Return this cookie to the client

I have included a test application in the solution which demonstrates using the returned cookie to make a call to a web service in the SharePoint site.  I’ve left the responsibility of caching the cookie to the client (but included this in the test app).

IMPORTANT NOTE: There is one modification required to the library which I haven’t done yet.  If you read the finer details of WIF you will know that if the SAML token data is too large for a single cookie, then WIF spreads the data over multiple cookies named FedAuth1, FedAuth2 … FedAuthN.  The library assumes that there is only one FedAuth cookie at present – which will be sufficient for most applications – but its worth keeping an eye on if you’re running into troubles.  I will get around to sorting this at some point, but feel free to make a pull request on my Github repository if you get there first.

Download the ClaimsProxy library and sample application from Github

ClaimsProxy is straightforward to use:

// configure our SPServiceRequestor.
var requestor = new SPServiceRequestor
    DobstsEndpoint = "",
    DobstsUsername = "",
    DobstsPassword = "password",
    DobstsAdfsRealm = "",
    AdfsEndpoint = "",
    SharepointRealm = "",
    SharepointSiteUrl = "",
    IgnoreSslValidation = true,
    DebugMode = true,
    DebugEventCallback = (data) =>
     // your debug function here

string spCookieRaw = requestor.GetCookie();

N.B.: DobSts is our own implementation of the StarterSTS project.

Check out the sample application for a full example of how to use the library.

I’d welcome any comments / feedback on this – hopefully it will be of some use to others out there, it certainly has been to me.

Permanent link to this article:

Jan 12

Setting up Google Apps Single Sign On (SSO) with ADFS 2.0 and a custom STS such as IdentityServer

I recently had to undertake some work to enable users to seamlessly authenticate to Google Apps using an identity stored in a custom Secure Token Service such as the excellent IdentityServer open source STS by Dominick Baier.  The work involved is mostly configuration in Google Apps and ADFS but there are quite a number of steps and as it was non-trivial I thought I’d document it here for reference.  Note that Google Apps uses SAML 2.0 tokens and because ADFS is brokering the authentication, you shouldn’t have any problems with compatibility as ADFS 2.0 can issue SAML 2.0 tokens.

Here’s a quick architecture diagram:



Green arrows = user request flow

Blue arrows = service response flow


For those of you impatient, here’s a quick overview of the steps required:

  1. Enable SSO in Google Apps
  2. Enter correct ADFS urls into Google Apps
  3. Upload ADFS Token Signing Certificate so Google Apps can verify the SAML tokens
  4. Add Google Apps as a Relying Party in ADFS
  5. Test

I will now walk through each stage in detail, for those who like the details.

Enable SSO in Google Apps

The first stage is to enable Single Sign-on in Google Apps.  Log in to your administration console at /"><your-domain>/.  Click on Advanced Tools and in the Authentication section click on Set up single sign-on (SSO):


This will take you through to a configuration screen.  Make sure the checkbox next to Enable Single Sign-on is ticked, and then enter the following values:

page URL:

Sign-out page URL:

Change password URL:

Verification certificate: Upload the ADFS Token Signing cert (.cer file) which you can obtain from the AD FS 2.0 Management Console (under Service > Certificates).  Remember to click Upload.

Check the box next to “Use a domain specific issuer”.

Enter some network addresses into the Network masks box if you wish.


At this point Single sign-on is configured and enabled.  Note that this will take immediate effect on your access to Google Apps services so beware!  However it does not affect your login to the admin console – that is always accessed via a manual login, so you can get in and turn it off again.

Configure ADFS

Open up the AD FS 2.0 Management Console and navigate to the Relying Parties section.  Click Add Relying Party Trust and follow these steps:

Choose Enter data about the relying party manually


Provide a name for the trust (not important, only so you can easily identify it)


Choose AD FS 2.0 profile


Tick Enable support for the SAML 2.0 WebSSO protocol and enter /acs"><your-domain>/acs into the Relying party SAML 2.0 SSO service URL


Enter<your-domain> as the relying party identifier


Complete the wizard.

Then click on the newly added item and click Properties.  Click on the Signature tab and click add:


Here we add the Token Signing Certificate – it must be the same one that we uploaded in the Google admin console, and this should be the ADFS Token Signing Certificate.

Once you’ve done that click OK to close the Properties dialog.

Now click Edit Claim Rules and click Add Rule:


Select Transform an Incoming Claim from the Claim rule template drop-down:


Give the rule a name, select E-Mail Address as the Incoming Claim Type, set the Outgoing claim type to Name ID and the Outgoing name ID format to Email:


Finish the wizard.


I’ve assumed here that you’ve already got your custom STS configured as a Claims Provider in ADFS.  To test the end-to-end service, visit<your-domain>.  You should get redirected to ADFS.  Choose your STS and then enter your credentials.  You should then be redirected back to Google Apps and arrive at your mailbox, logged in.

If you hit problems, check these items:

- You’ve got the correct certificate uploaded to Google Apps and configured in ADFS

- The time on the ADFS server and custom STS servers is correct

- Google Apps SSO configuration is correct

- If all else fails, try Googling!

Permanent link to this article:

Older posts «