Today I looked at the configuration DMVPN (Dynamic Multipoint VPN). A Dynamic Multipoint Virtual Private Network is an enhancement of the virtual private network (VPN) configuration process of Cisco IOS-based routers. DMVPN prevents the need for pre-configured (static) IPsec peers in crypto-map configurations and ISAKMP peer statements. This feature of Cisco IOS allows greater scalability over previous IPsec configurations. An IPsec tunnel between two Cisco routers may be created on an as needed basis.
I have created a situation with GNS3, where I have two hub routers and one spoke router. This situation creates extra redundancy when connecting to the hub location. There are two ways to configure redundancy in DMVPN:
In the first scenario the hub routers are connecting to there own DMVPN network. This means that the spoke need to configure two tunnel interfaces to connect to two different DMVPN networks. In the second scenario both hub routers connect to the same DMVPN network. I configured the second scenario using GNS3. The figure below shows my practice setup.
The configuration from the three routers can be found below.
I configured EIGRP authentication as an extra feature. This setup was configured with GNS3, so I guess it needs more tweaking to implement it in a real network. It should however provide a solid base for configuring a redundant DMVPN solution.
When configuring a Remote Access VPN or a Site to Site VPN connection you have the ability to filter traffic entering and leaving the VPN connection. You have the ability to enable inbound IPsec sessions to bypass interface access lists. Group policy and per-user authorization access lists still apply to the traffic.
The sysopt connection permit-ipsec command allows all the traffic that enters the security appliance through a VPN tunnel to bypass interface access lists. Group policy and per-user authorization access lists still apply to the traffic. In PIX 7.1 and later, the sysopt connection permit-ipsec command is changed to sysopt connection permit-vpn.
Mostly I use this option and configure some extra ACL’s to filter trafifc. Some customers don’t want to use this option and want to specify all traffic with ACL’s. This is more secure, but is a bigger burden on the management of the firewall.
From IOS 7.1 and later you have the ability to configure VPN filtering through Group Policies. In short you configure an extended ACL, link this ACL to a Group Policy and link the Group Policy to the specific Tunnel Group. The syntax (source and destination) needs to be correct for the ACL to work.
For Site to Site VPN’s the remote network is the source and the local network is the destination. For Remote Access VPN’s the VPN IP pool is the source and the local network the destination, as specified below.
An ACL that is used for a vpn-filter must not also be used for an interface access-group. When a vpn-filter is applied to a group-policy/user name mode that governs Remote Access VPN Client connections, the ACL must be configured with the client assigned IP addresses in the src_ip position of the ACL and the local network in the dest_ip position of the ACL. When a vpn-filter is applied to a group-policy that governs an L2L VPN connection, the ACL must be configured with the remote network in the src_ip position of the ACL and the local network in the dest_ip position of the ACL.
Exercise caution when you construct the ACLs for use with the vpn-filter feature. The ACLs are constructed with the post-decrypted traffic (inbound VPN traffic) in mind. However, they are also applied to the traffic originated in the opposite direction.
More about this matter and examples configurations can be found here.
It has been a while since my last post, but time is short these days.
Today I had to troubleshoot a Microsoft IAG appliance. Microsoft IAG stands for Microsoft Intelligent Application Gateway. And indeed, intelligent it is. NOT. I have seen and configured multiple SSL VPN solutions like Juniper SA, Citrix Access Gateway, Citrix Secure Gateway and Cisco WebVPN. But to be honest, Microsoft IAG is the worst of all.
Microsoft IAG is installed on an appliance and is closely related to Microsoft ISA 2006, which is also installed on the server. Whenever you make some configuration changes to IAG, you have to active the new configuration inside IAG. After activating the configuration, I looked at the new ISA firewall policies and I really couldn’t believe my eyes. IAG configured ISA automatically, when activating the configuration.
A simple portal, where 2 websites and OWA are published and a network connect (SSL IP VPN), results in approximately 10 firewall policy rules in ISA. Okay, I could live with that, but I shivered while taking a closer look at the rules. It is not easy to discover what purpose a specific rule has, without looking to the different tabs while editing the rule.
Besides the crazy management of the appliance, me and a colleague had a lot of problems when testing the appliance. Currently the network connector is not supported on Windows Vista and you receive a lot of (useless) errors when using Internet Explorer 8. The logging functionality is also very basic and hard to find. I had problems with configuring and testing the network connector with the non-split tunneling and disable local area network access option, I couldn’t find any useful logging about the problem. For some reason only specific traffic is routed into the VPN tunnel. I ended up configuring split-tunneling and only route specific network segments into the SSL VPN tunnel.
My opinion till now, Microsoft IAG cannot be compared with other SSL VPN appliances I have seen. I guess Microsoft IAG could test positive when using the appliance in a solely Windows environment, where only Windows services, like OWA and SharePoint, are published to the internet.
Maybe the solution is a lot cheaper compared with the Juniper and Citrix solution, but for know I would rather buy a Cisco ASA 5505 or Cisco ASA 5510. I would definitely not configure the Microsoft IAG as a cooperate firewall terminating the Internet connection.
Microsoft IAS server is often used as RADIUS server to authenticate VPN users or in conjunction with ISA reverse proxy to authenticate OWA users or PDA synchronization.
Today I had to install an ISA reverse proxy server with ISA 2006 Standard and Exchange 2007. I wanted to install Microsoft IAS as RADIUS server to authenticate the OWA users. Normally I install IAS on one, but preferably, on two domain controllers. I logged in on a domain controller through RDP. I noticed that the OS of the domain controller was Windows Server 2008.
Cool, finally working with a Windows Server 2008. After getting familiarized with the new view and layout, I started to search for a way to add the needed Windows component IAS. After searching for a while I found how to add Windows component. Looking at the complete list, I couldn’t find the Internet Authentication Service.
Oops, did Microsoft remove the IAS functionality from its server platform??? After googling for a second, I found that IAS has been replaced by Network Policy and Access Server service in Windows 2008.
Microsoft TechNet told me the following:
Network Policy Server (NPS) is the Microsoft implementation of a Remote Authentication Dial-in User Service (RADIUS) server and proxy in Windows Server 2008. NPS is the replacement for Internet Authentication Service (IAS) in Windows Server 2003.
As a RADIUS server, NPS performs centralized connection authentication, authorization, and accounting for many types of network access, including wireless and virtual private network (VPN) connections. As a RADIUS proxy, NPS forwards authentication and accounting messages to other RADIUS servers. NPS also acts as a health evaluation server for Network Access Protection (NAP). Source
After installing NPS, I started the configuration. You really have to get familiar with the way Windows Server 2008 works. There are a lot of different wizard and multiple configuration options to choose from. Everything looks a bit more fancy. NPS is not only a replacement for IAS, but has also many enhancements.
More information about installing and configuration Network Policy Server can be found in the article Understanding the new Windows Server 2008 Network Policy Server on WindowsNetworking.com. Here you can read that NPS has a lot of functions related to Network Access Protocol (NAP). A very detailed example of using NPS to perform NAP can be found in Brian Posey’s series An Introduction to Network Access Protoction.
One of our customers wants you use their locally installed Microsoft Outlook through a Citrix Access Gateway (CAG). Sales people from that customer travel through the country and use the Outlook offline to read or prepare e-mail to send later. These people use UMTS technology to connect their laptops to the Internet. The customers wants these sales people to have the ability to use their Outlook offline and actually send/receive mail when connected to a network with Internet access.
The customer is using CAG’s to publish multiple services to the Internet, so together with my colleague Edwin Houben from DigiPulse, we started to look at a suitable solution. The CAG is located behind a CheckPoint firewall and traffic to the internal network needs to go through an ISA server firewall.
First we started to look at the ports Microsoft Outlook uses to connect to the Exchange server. Looking at the settings from a laptop, the connection is made by FQDN of the Exchange server. While performing a netstat -na we noticed that Outlook uses two ports to connect to the Exchange server.
The Outlook clients connects to the Exchange server on FQDN. So the laptop needs to have an IP connection to the Exchange server. So we decided to use the Citrix Secure Access Client to give the user the ability to establish an secure IP connection to the network.
Looking at the customers network, we had to configure access-lists on two locations to make the solution more secure. The first location is a Network Resource in the CAG. The Network Resource enables only the above ports to the Exchange server IP address. The second location is allowing the IP address of the CAG to connect to the Exchange server on the above port numbers through the ISA server.
After configuring both access-list, we did some testing and the solution works perfectly. You can now use the laptop on the internal network and externally with the Citrix Secure Access Client without making any changes in the Outlook configuration.
Later, the customer noticed that he couldn’t use Microsoft Outlook anymore in conjunction with the Citrix Secure Access Client. After digging a bit deeper in the traffic flow between Microsoft Outlook and the Exchange server, I noticed that, beside TCP/135, random ports above 1024 are used. So I changed the Network Resource and the ISA servers to allow TCP/135 and the range TCP/1024-2000. I haven’t used the complete range of registered port numbers, so I hope Exchange doesn’t use a port above TCP/2000.
I didn’t some Googleing (or Googling or whatever) on TCP port 135 and I found some “funny” things:
Some well known Root kits also use this port to transmit data back to home base and download more malware. I also suspect may be an entry point for some root kit /malware for un patched systems or systems that did not patch correctly. Source
Currently inbound scans are likely the Nachi or MSBlast worms. Source
The problem with port TCP 135 is that it is used for multiple services, which are listed below. So blocking port TCP 135 could affect communication between devices or the usage of services.
|Client/Server Communication||DCOM||DHCP Manager|
|Exchange Administrator||Microsoft Message Queue Server||RPC User Manager|
|RPC Service Manager||RPC Port Mapper||SCM used by DCOM|
|SQL Session Mapper||WINS Manager|