You currently have an ISA Server 2006 SE on your network.
And you may have an existent site-to-site VPN connection, or plan to add one. For several reasons, you may like to move the existent site-to-site VPN connection over a dedicated connection(say, to buy for that a new Internet connection). Or you may want to create the new VPN tunnel over a dedicated Internet connection.

Depending on the nature of the remote VPN gateway, another ISA Server 2006 or a third-party VNP gateway, and your requirements, you need to choose between the IPsec tunnel mode VPN site-to-site connection or the L2TP/IPsec site-to-site VPN connection(I do not count PPTP, as personal, I dislike the use of it these days due to security reasons).

If you connect to a remote third-party VPN gateways, likely, your only option would be the IPsec tunnel mode VPN site-to-site connection.
If you connect to another ISA Server 2006, you may like to use, per Microsoft's recommendations, the L2TP/IPsec site-to-site VPN connection.

In this part we will establish an IPsec tunnel mode VPN site-to-site connection between two ISA Server 2006 SE SP1 installed on Windows 2003 Standard Edition R2 SP2.

The network diagram:

The lab diagram:

Read more...

Some time ago, I've posted on the Vyatta Users forum about an issue regarding L2TP/IPsec remote access VPN.
For some reasons, things went sideways, and an ambiguous situation reigned.

On 26.08.2008, on the Vyatta Users forum, an announce was made, that a Security Reference document is available for download at http://www.vyatta.org/documentation.

Within that document, Chapter 4 Remote Access VPN Overview, section Remote Access VPN configuration, topic Remote Access VPN Deployment Issues, L2TP/IPsec part, Vyatta documented that issue.

Vyatta provide a solution using iptables for Glendale(VC4).
Starting with Hollywood(VC4.1), the issue can be addressed directly from the CLI, a configuration example being presented.

Vyatta kept their word, and both documented and addressed the respective issue.

For doing that, three big Hip Hip Hoorays from me today for Vyatta in the security area.

There are a couple of things concerning any security admin regarding its users like don't do anything stupid and keep your software(like OS, antivirus definitions...) up to date.

For the security admin, these things might be under her/his control if the machines are located on the corporate network.
The admin will make sure tha the OS' are patched on a timely basis, install on every user machine a personal antivirus and a personal firewall. He or she will keep the antivirus definitions up to date.

When these machines leave the corporate network for a period of time, and need access to the corporate network from remote locations, the admin is clueless about their state of health.

Were the latest security patches installed ?
Was the antivirus kept up to date, or even worse, is still the antivirus program enabled on these machines ?
Is the personal firewall still enabled on the users' machines ?
Have those machines become a sort of gateways for the user's home network, thus serving as a potential path to the corporate network for an attacker once the user uses a VPN connection to access the corporate network ?

Unfortunetely, there aren't by default any practical means available with ISA for the security admin to check the remote VPN users machines' health status(when I say practical, I exclude the administrative nightmare VPN Quarantine made available with ISA 2004/2006 by Microsoft, solution which will make most of the people abandoning the idea of using a remote access VPN quarantine with ISA).
NAP is a hot topic right now.
If you search for NAP, you may found out that this will be available on the future version of ISA, called TMG. But TMG is far away at this moment.

Luckily for the ISA admins, an enterprise grade VPN quarantine solution for ISA is available for quite a while now. This solution is called VPN-Q 2006. You can reach it at its vendor site, http://www.winfrasoft.com/. It will work with the VPN protocols available on ISA, PPTP and L2TP/IPsec. And very important, VPN-Q 2006 is a very easy to use and to implement solution.

Read more...

Just for the record:
If you have ever sent to your ISA Server 2004/2006 or attempted to sent through your ISA an IP packet that consists of only an IP header, you may have noticed that your ISA logs do not show anything.
Here is the explanation why:
http://support.microsoft.com/kb/936905

Windows Server 2003 simply drops those packets, without forwarding them to ISA.
These packets do not pass through ISA or if they target one of ISA's IP addresses, there is no reply packet, they are silently dropped, so there is nothing to worry about.
But you'll never know that someone made some "funky" attempts, assuming that you may want to know.

Bellow is the nmap command, just in case you want to test it yourself(-p55 means IP Protocol 55, will set the Protocols field within the IP header, I've entered a random number).
Note that if you use -p6 which means TCP, nmap will send an ACK segment to a random destination port.
Also if you use -p17 which means UDP, nmap will send an UDP packet to a random destinaton port.
And if you use -p255, and the destination host is on the local network, nmap will first send an ARP request for the destination IP address, and if an ARP reply is received, the IP packet that consists of only an IP header will be sent to the specified destination. If you replace the host destination with the entire local network, say 192.168.22.0/24, nmap will first send an ARP request for the every IP address from the specified network range, and for every host that sends an ARP reply, the IP packet that consists of only an IP header will be sent.

Or the hping3 command(--iproto 55 means IP Protocol 55, will set the Protocols field within the IP header):

Such a packet captured with Wireshark:

So, you've tried many combinations in an attempt to configure your Mac OS X L2TP/IPsec VPN clients to use IKE authentication with certificates with your ISA Server 2006, certificates issued for the Mac VPN Clients and ISA by an internal Windows Enterprise CA.

You may have a couple of certificates installed on ISA issued by this CA, so you have troubles identifying which certificate is ISA picking for IKE authentication, if this certificate has the "correct" fields required by the Mac OS X L2TP/IPsec VPN clients' security checks.

Till now this "game" left you fuming.
I've mentioned in the first part of this article about the posibility of using a separate CA to issue certificates just for the Mac OS X L2TP/IPsec VPN clients and ISA, certificates that can be used for IKE authentication.

If you have not gave up, and you are still searching for a solution, one such solution can be to use an OpenSSL CA to issue the needed certificates for IKE authentication.
Your Windows L2TP/IPsec VPN clients will continue to use the same certificates they used before for IKE authentication.
We will use this OpenSSL CA just to issue to ISA a "valid"(from the perspective of the Mac OS X L2TP/IPsec VPN clients) certificate and also to issue certificates for the Mac OS X L2TP/IPsec VPN clients.

I'm using an OpenSSL CA because it can easily issue the "correct" certificate for ISA that will work with Mac OS X L2TP/IPsec VPN clients.
We have seen that it is recommended to have installed on ISA a certificate with no EKU field and with the SAN field containing a DNS Name, a FQDN which the Mac OS X L2TP/IPsec VPN clients will use as their VPN server address.
Since only one certificate will be installed on ISA issued by this CA, you will know for sure what certificate will be used for the IKE authentications between ISA and the Mac OS X L2TP/IPsec VPN clients. No more "games".

Read more...

Using L2TP/IPsec for a VPN site-to-site connection is recommended when both VPN gateways are ISA 2004/2006 Firewalls. This is specified in clear in many docs on Microsoft's web site.

IPsec Tunnel Mode site-to-site VPN connections are used when interoperability with a VPN gateway from another vendor is required. ISA Server 2006 has passed the VPNC Basic Interoperability Test. If you scroll this document, you will find against which VPN gateways ISA Server 2006 was tested.

If you need to create an IPsec Tunnel Mode site-to-site VPN connection with a VPN gateway from another vendor, you may ran into a couple of unsupported settings or scenarios.

Let's point out some of them.

A easy to spot one will be the lack of support for Diffie-Hellman MODP Group 5 (1536-bit). Popular VPN gateways often use this group. ISA Server 2006 can use instead the stronger Diffie-Hellman MODP Group 14.

Read more...

When you are troubleshooting L2TP/IPsec remote access VPN connections using certificates for IKE authentication, a good place to start, you may think, would be the Event Viewer on your ISA Server, particularly the Security Audits.
I would add: maybe. It might be a good idea or not. Depends.

How is that, you may wonder ?

For example you may see that Event ID 541: IKE security association established, Mode: Key Exchange (Main mode) was logged.
So, you would say: IKE MM negotiations went fine, I have an established IKE MM Phase, and now IKE Quick Mode may start.

Wrong. You have an IKE MM Phase established just from ISA's point of view.
That does not imply that the client has also an established IKE MM Phase.

The client will send to ISA its third IKE MM message, an encrypted message, which contains the authentication payload along with the client's certificate.
ISA analyzes this message, everything appears to be fine, and it logs that IKE MM was establised.
After that ISA sends to the client its third IKE MM message, which contains the authentication payload along with ISA's certificate.

The client will take a look at this message. If the client(say it's a Mac OS X L2TP/IPsec VPN client or a Vista L2TP/IPsec VPN client) is configured to perform additional checks on ISA's certificate, it may not accept ISA's certificate, for example the SAN field on the VPN server's certificate does not contain the expected DNS name.

Let's exemplify the above described issue.

I recently wrote something about Mac OS X L2TP/IPsec as VPN clients and ISA as an L2TP/IPsec VPN server:
http://www.carbonwind.net/ISA/MacOSXVPNL2TP/MacOSXVPNL2TP1.htm
There we have seen that the Mac OS X L2TP/IPsec VPN clients perform certain checks on the VPN server's certificate. So a Mac OS X L2TP/IPsec VPN client can serve as a good example for a quick test.

Let's say I'm connecting from a Mac OS X L2TP/IPsec VPN client to an ISA 2006 L2TP/IPsec VPN server, and the VPN connection cannot be established. ISA has installed on it a certificate which contains within the SAN field the DNS Name isabranch.carbonwind.net.
The Mac OS X L2TP/IPsec VPN client is configured to connect to the vpn.carbonwind.net VPN server.

The Event Viewer/Security on ISA will log an Event ID 541: IKE security association established, Mode: Key Exchange (Main mode).

If we look at the Oakley.log on ISA, we can notice that indeed from ISA's point of view the VPN client was successfully authenticated and the IKE MM phase was established. And that ISA is using a certificate with the CN isabranch.carbonwind.net. If we look into the Computer Certificate Store on ISA, we will see that this certificate has within the SAN field the DNS Name isabranch.carbonwind.net.

ISA will send its third IKE MM message to the VPN client.
However, the Mac OS X L2TP/IPsec VPN client sends back a NOTIFY message, informing ISA that its certificate is invalid(ISA does not appear to be aware of the meaning of this message).
The Mac OS X L2TP/IPsec VPN client expected the SAN field from ISA's certificate to contain the DNS Name vpn.carbonwind.net.
So from the Mac OS X L2TP/IPsec VPN client's point of view, IKE MM was not quite established, the authentication of the VPN server failed.

If from the VPN client's point of view the VPN server would be successfully authenticated and the IKE MM would be established, the VPN client may send the first IKE QM message. But in our case, the Mac OS X L2TP/IPsec VPN client sends back an ISAKMP Informational Exchange message instead, so no IKE QM negotiations. The second authentication phase, user authentication(PPP authentication), will start only after IKE QM negotiations will be successfully completed, the L2TP tunnel started and a PPP authentication method selected.

Thus, it must be noted that the Event Viewer is just a quick troubleshooting tool for IKE negotiations, and it may be a little bit confusing. If you want to analyze deeper the IKE negotiations, check the Oakley.log on ISA.

I wrote within this article about the Vista L2TP/IPsec VPN client and the Verify the Name and Usage attributes of the server's certificate checkbox:
http://www.carbonwind.net/ISA/L2TP/l2tp2.htm
As said there, I've noticed that the Vista L2TP/IPsec VPN client checks the EKU field of the VPN server's certificate to see if contains Server authentication. If not, IKE authentication will fail.

If you want to find out more about the Verify the Name and Usage attributes of the server's certificate checkbox, see KB926182.

A couple of days ago, I found this article on the Routing and Remote Access Blog, titled Vista/LH: Security changes for remote access scenarios:
http://blogs.technet.com/rrasblog/archive/2006/11/01/vista-lh-security-changes-for-
remote-access-scenarios.aspx

Within this article, there is a confirmation that indeed the Vista L2TP/IPsec VPN Client checks the EKU field of the VPN server's certificate for Server authentication(1.3.6.1.5.5.7.3.1).

So if you plan to use your ISA Server as a VPN server and on the Vista machines to enable within the L2TP/IPsec VPN Client the Verify the Name and Usage attributes of the server's certificate checkbox, make sure that ISA has installed and will use a proper certificate for IKE authentication(check the Oakley.log on ISA to see what certificate is selected in case you have multiple certificates installed in the Computer Certificate Store, I wrote about this issue here). Otherwise, your Vista machines will be unable to connect using an L2TP/IPsec connection to your VPN server.

A lot of ISA admins have problems with their VPN clients which are not able to resolve single label names.

There is an interesting Microsoft document explaining how single label names are resolved by Windows XP or Vista:
http://download.microsoft.com/download/e/2/0/e2090852-3b7f-40a3-9883-07a427af1560/
DNS-GlobalNames-Zone-Deployment.doc

A simple way to fix that is to have a WINS server.
But that might be another problem, since people may not want to add a WINS server on their network.

Another solution to this is to install the DHCP Relay on ISA and give the VPN clients through DHCP Options the connection-specific DNS Suffix for the VPN adapter.
http://www.isaserver.org/tutorials/2004dhcprelay.html
However there is an issue with the DHCP INFORM packet sent by the VPN Client. It may be dropped by ISA as a spoofed packet.
To fix that, you need to add a registry entry on ISA:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RAT\Stingray\Debug\
FWSRV]"FWS_PNP_IPHELPER_QUITE_PERIOD"=dword:000005dc

Other option is to use the GPO and distribute the DNS Suffix search list.
http://technet2.microsoft.com/windowsserver/en/library/
5fe46cef-db12-4b78-94d2-2a0b62a282711033.mspx?mfr=true
http://support.microsoft.com/kb/294785

I was asked by someone if there is another way to give to the VPN clients the connection-specific DNS suffix for the VPN adapter.
The answer is yes, if you use CMAK profiles.

You can set the DNSSuffix key to the required value under [TCP/IP&EntryName Tunnel] section in the .cms file.
http://technet2.microsoft.com/windowsserver/en/library/
7a5bd80a-56aa-4cb9-b3c4-006886bf33e71033.mspx?mfr=true

You can do that through the CMAK wizard or by manually editing the .cms file and then re-run the CMAK wizard for that profile without making any changes in order that your manually inserted options to be incorporated into the self-extracting executable profile.

Jason Jones has two great articles about how to use CMAK:
http://blog.msfirewall.org.uk/2008/06/using-cmak-to-configure-isa-server-vpn.html
http://blog.msfirewall.org.uk/2008/06/using-cmak-to-configure-isa-server-vpn_10.html

Run as usualy the CMAK wizard to create a new profile.

When you've reached the Ready to Build the Service Profile window, put a checkmark into the Advanced customization checkbox and click Next.

In the Section name drop-down menu select [TCP/IP&EntryName Tunnel], in my case TCP/IP&ISA VPN Tunnel. In the Key name area enter DNSSuffix. And in the Value field type your DNS suffix, in my case, carbonwind.net. Click Apply.

As you can see, the entered values will be saved into the isavpn.cms file. Click Next. And build your cmak profile.

If we take a look at the isavpn.cms file, we can spot the new lines used for our DNS suffix.

As said before, if you already have a CMAK profile and do not want to make the modifications from the wizard, you can manually insert the above lines into your .cms file. And then simply re-run the CMAK wizard without making any modifications in order that the manually modified .cms file to be read and the modifications to be added to the self-extracting executable CMAK profile.

Install the CMAK profile on one of your VPN client machine and connect.

Open cmd.exe and run an ipconfig /all command. You should have a connection-specific DNS suffix on your PPP adapter.

In the first part, we've discussed about using certificate for IKE authentication.
Let's talk now about using pre-shared keys.
Pre-shared keys are a weak authentication method, but they can be useful for testing.
As we have seen, using certificate for IKE authentication can cause some problems.
Having some NAT devices along the path or connecting while we are behind a restrictive firewall can introduce certain issues too.
Pre-shared keys allow us to take a step by step approach in configuring our L2TP/IPsec VPN connections.
For example, we can configure ISA and the Mac L2TP/IPsec VPN clients to use a pre-shared key for IKE authentication, then make a first test while there is no other device(especially a NAT device which might break our connection) between the Macs and ISA. If this test is successful, we know that the second level of authentication (user authentication) is working too. After that we can make a test while the Mac is behind a NAT device(to see if NAT-T is working or if the NAT device is not breaking the NAT-T process).
If this test is successful, we can proceed and configure ISA and the Mac L2TP/IPsec VPN clients to use certificates for IKE authentication, then make a first test while there is no other device(especially a NAT device) between the Macs and ISA. And so on ...

It was a simple process to configure Mac OS X 10.4.8 or Mac OS X 10.4.10 to use pre-shared keys with L2TP/IPsec.
I did not encounter any problems.

Read more...

I'm not a Mac user. However, recently I had the chance to test the Mac OS X 10.4.8 and Mac OS X 10.4.10 as L2TP/IPsec VPN clients with ISA Server 2006 as L2TP/IPsec VPN server. I've decided to put a couple of notes regarding what I have observed.
In this part we will talk about using certificates for IKE authentication.
In a future part, we will talk about using pre-shared keys. Pre-shared keys are a weak authentication method, but they can be useful for testing.
I do not have currently access to a Mac OS X 10.5.x machine. When/if I will have access to such a machine, I will test to see what happens.

I've started configuring and connecting with a Mac OS X 10.4.8 machine. I thought I got it working, but when I attempted to connect with a Mac OS X 10.4.10 machine, I could not. So I needed to make some changes in order to make it work.

I've first prepared ISA.
I'm using an Enteprise CA(Windows 2003 Standard R2 SP2).

Read more...

Some time ago I've run into this interesting presentation from Microsoft Tech-Ed Israel, called The amazing world of …Microsoft Secure Remote Access & Application Security with IAG & UAG.

It contains some nice info about the two products, about Microsoft Secure Access Strategy. There is also a "UAG" vs. IAG 2007 table.

You can download it at:

http://download.microsoft.com/download/a/7/c/a7ccc02e-9404-4008-ac61-2bcd696c92ec/SEC479.ppt

I've recently had the chance to configure ISA Server 2006(domain member) as L2TP/IPsec remote access VPN server with a Mac OS X 10.4.8 as L2TP/IPsec VPN client.

I've used certificates for IKE authentication(the CA was an Windows 2003 Enteprise CA).

I've almost completed an article regarding this. I will publish it as soon as possible.

In a future part, we will talk about using pre-shared keys too. Pre-shared keys are a weak authentication method, but they can be useful for testing.

I did not have the chance to configure ISA 2006 Server(domain member) as L2TP/IPsec remote access VPN server with a Mac OS X 10.5.x machine as L2TP/IPsec VPN client.

Installing a certificate for IKE authentication on a Mac OS X 10.4.8 machine was a little painful. I've played a little bit with a Mac OS X 10.5.x machine, and I've noticed that the installation of a certificate is an easier process. But, as said before, I did not have the opportunity to test the L2TP/IPsec VPN connection from an Mac OS X 10.5.x machine as VPN client with ISA Server 2006 as L2TP/IPsec VPN server.

I've added a couple of posts on this blog linking to some of my previous articles.

You can find the entire list of the articles here:

http://www.carbonwind.net/Articles/articles.htm

Have fun,
Adrian

Jason Jones has got his ISA Firewall blog on line.

You can found Jason's super ISA Firewall blog, titled My, Myself and ISA Blog, at:

http://blog.msfirewall.org.uk/