Wednesday, 11 September 2013

Creating a SSTP split tunnel in UAG

I like to provide remote access by publishing applications on UAG, but there are times when a full VPN tunnel gets around a number of issues, but may reduce your security posture.  I don't like to make changes to the security unless they are respected or being used by responsible people.  For most people using the SSTP VPN tunnel feature in UAG would be adequate, but there are times when a user needs a split tunnel.

I was told that SSTP in UAG did not support split tunnels, but there seems to be a workaround with this blog post: http://blogs.technet.com/b/fsl/archive/2011/01/26/uag-sstp-split-tunnel.aspx

In trying this myself, I did the following:

I went to the following location: C:\Program Files\Microsoft Forefront UAG\Endpoint Components\3.1.0 (The location of your files may be different depending to what service pack level you are at with UAG). 

Copy the 'sstp.pbk' file to the desktop, and rename the original file in the original location (I chose 'sstp.pbk_old').  Go back to the desktop and double click on the 'sstp.pbk' file you just copied.


You will be presented with the following box, where you need to select 'Properties':


Highlight 'Internet Protocol Version 4 (TCP/IPv4)', and then click on the 'Properties' button:


From this screen, you will need to selected the 'Advanced' button:


From this box, uncheck the 'Use default gateway on remote network' option, and close all the boxes.


Take the modified 'sstp.pbk' file and copy it back to the original location.

To prove the difference it makes, I took a 'route print' using the original 'sstp.pbk' file, and a 'route print' of the modified 'sstp.pbk' file.

I haven't tested this in anger, but looks like it will solve the issue we currently encountering.

Tuesday, 10 September 2013

UAG ActiveX issues on IE10

I saw something today that I had not encountered before.  I had a user connecting to my UAG setup, but it seemed like the UAG client would install when running as administrator, but would not run.

After running a remote session, I spotted that there was an extra icon that I had not seen before on the IE10 address bar:

 
It turns out this is an ActiveX filter built into Internet Explorer.  Although with it running, the UAG components can not execute, meaning only web applications will run.

This feature can be disable by going to the cog icon, clicking on "Safety" and then unchecking "ActiveX Filtering"


Wednesday, 21 August 2013

Importing UAG applications to another server

Today, I had to build two additional UAG servers with the same applications as the original one I deployed.  I used the following procedure to achieve this:
  1. On the original UAG server, export the configuration and give it a password.
  2. Configure the new UAG server with the appropriate networking information, including LAN and WAN IP details, static routes on the server, ensure the networking is reflected in TMG.
  3. Patched up the new UAG server to the same level as the original server.
  4. Import the configuration to the new UAG server.
  5. Activate the configuration.
  6. Change the hostname on the truck (and remember to change the hostname on OWA, if you are using this feature)
  7. Ensure the right certificate is in the certificate store and associated with the trunk.
  8. SSL Network Tunnelling IP addresses will need to be added, if you are using this feature.
  9. Check the AD authentication service account password (and secret keys for RADIUS authentications, if being used) as these were removed from one restore, but not the other!
Hope that helps, if you have to do the same.

Wednesday, 14 August 2013

UAG File Access Script Errors Post SP3...

Today, I was looking at UAG SP3 installation, where we were configuring OWA, CRM and SharePoint.

We encountered an issue with File Access, it was working prior to SP3, but since SP3, when you try to access the console, we were getting the following script error:

A bit of Googling, brought up this blog article that I know solved the issue with other UAG users: http://itcalls.blogspot.co.uk/2013/03/uag-2010-file-access-application-fails.html but it didn't resolve my issue.

I ended up doing the following to get it to work:
  • In the UAG Management Console, remove File Access from the UAG application list
  • Activated the UAG configuration without File Access
  • Rebooted the server
  • Installed UAG SP3 Rollup 1 (following this previous blog article: http://blog.andytang.com/2013/07/service-packs-on-uag.html)
  • Activate the UAG configuration
  • Reboot the server
  • In the UAG Management Console, on the toolbar click on "Admin", then "File Access..."
  • When prompted if you want to enable NETBIOS, agree to this
  • Log into the File Access console using your NETBIOS domain administrator credentials
  • I can now browse the File Access structure without the script error
Enjoy!

Friday, 26 July 2013

UAG SP3 install fails and rollsback...

On site again this week, with another UAG installation, but this one offered something different as we were creating a gateway for mobile devices.

We encountered some issues installing service packs on the Celestix WSA UAG appliance.

As my previous post shows how to install SP2 and SP3, I had a failed install of SP2 this week.  The issue was not permissions, but failed after 10 minutes, after which the service pack would roll back.  A bit of a search brought up this Microsoft article:
http://support.microsoft.com/kb/2811066

I followed Method 1, which meant opening Notepad as an Administrator, then editing the following file:
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG\Machine.config

I added the following text, just before the </configuration> tag near the end of the file:
<system.transactions>   
<machineSettings maxTimeout="01:00:00" />
</system.transactions>
This effectively increases the timeout from 10 minutes to 1 hour, which resolved the issue for us.
 

Thursday, 4 July 2013

Service Packs on UAG...

In the past I've never encountered issues service packing the UAG software running on Celestix WSA appliances.  Recently I had a situation on site where the service packs would not apply by simply double clicking them, and after a bit of trial and error found the optimum way to get these installed.

I was using a Celestix WSA appliance, with build 2.4.0.0, which runs UAG 2010 SP1 Update 1.

I downloaded all the Windows and Celestix updates for the appliance, as well as TMG SP2, UAG SP2 and UAG SP3.

I found the best way to install the updates were as follows:
  • Run through the UAG quick start to get UAG online, but there is no need to create a portal (assuming this is a new install)
  • Apply the Windows updates and Celestix updates, then reboot
  • Apply TMG SP2, then reboot
  • Double clicking on UAG SP2 or SP3 will not install correctly, so follow the procedure in the point below.
  • Open up the Command Prompt as Administrator, then while holding down the shift key, right click on the UAG SP2 file, and select "Copy as path".  Right click on the command screen and paste this link in, then run it.  Follow the instructions to install UAG SP2 and reboot.
  • Open up UAG and check that the version number has changed from 4.0.1xxx.xxxxx to 4.0.2095.10000, then activate the UAG configuration.
  • Open up the Command Prompt as Administrator, then while holding down the shift key, right click on the UAG SP3 file, and select "Copy as path".  Right click on the command screen and paste this link in, then run it.  Follow the instructions to install UAG SP3 and reboot.
  • Open up UAG and check that the version number has changed from 4.0.2095.10000 to 4.0.3123.10000, then activate the UAG configuration.
You now have a UAG appliance up to service pack 3 ready for your portal.

Thursday, 30 May 2013

Planning a wireless network?

Having worked in IT for a number of years, I remember planning wired networks, where we could work out easily how many points were needed for a network.  It was two network points per desk for the computer and telephone, and the odd point for printers and fax machines around the office.

Fast forward to the current day, and as well as the wired network, we have to consider what the wireless requirement is.  We are all aware of bad wireless deployments, where laptops revert to using a cable.  Some of the challenges were discussed in a previous blog post, "They even have wireless internet now!"

There are a number of considerations, challenges and questions that need to be addressed prior to tackling a wireless network project.

Access
There is a need to understand what sort of access is required, and how you determine your policy and strategy can begin with the following questions:
  • What devices are you allowing to access the wireless network?
  • Will these devices be part of a BYOD (Bring Your Own Device) initiative, corporate devices supplied by the organisation or a mixture of the two?
  • Which parts of the network will these devices access, the corporate network or a guest network?
  • Will the devices be segmented by whether they fulfil a policy criteria, such as OS, AV, etc, using a NAC (Network Access Control) solution?
Devices
Understand the devices that will be access your network and determinerning whether these devices have a 5.0GHz AN wireless card, or a 2.4GHz BGN wireless card. Understand how many devices will be used, as some people carry three or four wireless enabled devices!

Understanding the number of devices and which frequency they can work in, means that channel conflicts can be dealt with at the planning stage, rather than trying to fix it post installation.

Coverage
Sounds straight forward, but you'll need to know which areas will require wireless coverage.

Roaming
Will your users need to roam with their devices?  Some wireless solutions deal better with roaming than others, so should a be a consideration when looking at the different vendor offerings.

Footprint
Wireless networks can go beyond the confines of your building or coverage area.  With correct access point placement or signal manipulation, the wireless footprint can be made to fit the building, reducing the likelihood of access from outside the area of coverage.

Density
Once you know which areas need wireless coverage, you'll need to understand the density requirements.  For example, a lecture theatre may have a requirement for up to 500 wireless devices connected at once, while the office down the hallway may have a requirement for one wireless device.  By understanding density, we can tackle how many radios are required in each area.

Bandwidth
Another consideration is bandwidth, what do these devices need to do once they have access to the wireless network.  Do they need basic web access, streaming video, video conferencing or voice over wifi?  These all have differing demands on bandwidth, so it is essential the bandwidth requirements are met to give a good user experience.

Encryption
It is shocking to see there are still a large number of unencrypted or open wireless networks out there.  We all know we should encrypted our networks, but depending on the solution this can cause large overheads on the network, especially with the traditional controller with controller-less access points, where the packets have to be sent back to the controller for decryption.  Open networks run quicker, but that doesn't mean we should configure them like that!  Protect that network, especially if it's offering corporate network access, and your footprint exceeds the building.

Threats
Is there a provision to the deal with the threat of rouge access points, which effectively extend your wired network via a wireless access point you are not aware of?  There are normally provisions for web filtering within an organisation, but what's to stop your corporate devices joining a neighbouring wireless network and getting unfiltered access (and the associated threats and malware) from the internet onto devices on your network?  How do you stop a device from becoming a wireless hotspot, even after they fulfil the policy laid down by your NAC solution?

The consideration with wireless is about access, but security comes a poor second when planning the network.  Ensure that there is a level of intrusion prevention on your wireless network, if you want to properly secure it.

(Can you spot the rogue access point here?)

To what end?
With a greater understanding of the various areas touched upon above, you can ensure you have a successful wireless deployment, that is secure, requiring little administration and exceeds the expectation of the user.