Booches.nl

Configure VPN client on IOS router

One way to remotely access a network is using the Cisco VPN client. Nowadays more and more implementations of SSL VPN are being done and Cisco stopped their development on their VPN client and pushes their Cisco AnyConnect client.

Still the Cisco VPN client is often used to remotely gain access to a network. The Cisco VPN client supports:

• Windows XP, Vista (x86/32-bit only) and Windows 7 (x86/32-bit only);
• Linux (Intel);
• Mac OS X 10.4 & 10.5;
• Solaris UltraSparc (32 and 64-bit);

The Cisco VPN client is available for download if you have a SMARTnet support contract and encryption entitlements. The client can be used in conjunction with VPN concentrators, PIX and ASA firewall and IOS routers. Below you can find a template configuration for enabling the Cisco VPN client on an IOS router (all used IP addresses and credentials are chosen randomly and don’t represent a real configuration). I used the setup from the picture below:

The configuration uses the local database to authenticate users and split-tunneling is configured to only encrypt traffic destined for the LAN network. With split-tunneling enabled you still can access all local resources and the internet.

aaa new-model
aaa authentication login userauthen local
aaa authorization network groupauthor local
!
username rene privilege 15 secret 5 $1$FkgJ$u3uU0rstyeaBXswW0EIX55
!
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
!
crypto isakmp client configuration group booches-vpn-client
key pr3sh@r3dk3y
dns 192.168.1.10 192.168.1.11
domain booches.local
pool vpnpool
acl 110
netmask 255.255.255.0
!
crypto ipsec transform-set vpn-ts-set esp-3des esp-sha-hmac
!
crypto dynamic-map dynamicmap 10
set transform-set vpn-ts-set
reverse-route
!
crypto map client-vpn-map client authentication list userauthen
crypto map client-vpn-map isakmp authorization list groupauthor
crypto map client-vpn-map client configuration address initiate
crypto map client-vpn-map client configuration address respond
crypto map client-vpn-map 10 ipsec-isakmp dynamic dynamicmap
!
interface FastEthernet0/0
ip address 83.137.194.62 255.255.255.240
ip nat outside
crypto map client-vpn-map
!
interface FastEthernet0/1
ip address 192.168.1.254 255.255.255.0
ip nat inside
!
ip local pool vpnpool 10.10.1.1 10.10.1.254
!
ip nat inside source list 100 interface FastEthernet0/0 overload
!
access-list 100 deny   ip 192.168.1.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 100 permit ip 192.168.1.0 0.0.0.255 any
access-list 110 permit ip 192.168.1.0 0.0.0.255 10.10.1.0 0.0.0.255

Juniper SA & Terminal Server with Novell Client SSO

Normally configuring SSO on a Terminal Server in conjunction with a Juniper SA isn’t that hard. On the Juniper you pass the user credentials to the Terminal Server. On a normal Terminal Server you have to check the following:

Disable Always prompt for password under:

Terminal Services Configuration –> Connections –> Properties of RDP-tcp –> Tabblad Logon Settings

On a Terminal Server, which is member of a Windows Domain, you have to check the following Group policy:

Disable Always prompt client for password upon connection under:

Computer Configuration –> Administrative Templates –> Windows Components –> Terminal Services –> Encryption and Security –> Policy “Always prompt client for password upon connection”

Now I had to configure Single Sign On to a Terminal Server where the Novell Client is installed. As soon as I pushed the user credentials to the Terminal Server, I noticed that the RDP session tries to logon as Workstation only. I found a nice thread on the Novell website to Enable TSClientAutoAdminLogon.

I added the following two registry keys to the registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Login
Value Type=REG_SZ, Name=TSClientAutoAdminLogon, Data=1
Value Type=REG_SZ, Name=DefaultLoginProfile, Data=Default 

I am able to logon to the Terminal Server using SSO after adding both registry keys to the registry. All registry entries under HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Login are displayed in the picture below.

VPN Filtering through Group Policy

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.

Source

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.

Microsoft Outlook through Citrix Access Gateway SSL IP VPN

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.

FUNNY ADD-ON

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.

HSRP and ACL’s

I added a Guest VLAN to a network environment with two multi layer switches running HSRP. To secure the internal network from the Guest VLAN, I added a ACL to the Guest VLAN SVI. The ACL is stated below:

ip access-list extended GUEST-DENY-RFC1918
remark Allow DHCP
permit udp any eq bootpc any
remark Deny RFC 1918
deny   ip 10.1.2.0 0.0.1.255 10.0.0.0 0.255.255.255
deny   ip 10.1.2.0 0.0.1.255 172.16.0.0 0.0.15.255
deny   ip 10.1.2.0 0.0.1.255 192.168.0.0 0.0.255.255
remark Allow HTTP / HTTPS
permit tcp 10.1.2.0 0.0.1.255 any eq http

permit tcp 10.1.2.0 0.0.1.255 any eq https

The ACL allows querying the DHCP server to obtain the necessary IP address. Next the ACL denies access to all RFC 1918 IP addresses, which are used on the internal LAN segment of the customer. The last two statements allow HTTP and HTTPS access to the Internet.

At first, I just applied the ACL to both the multi layer switches and thought I was ready. After configuring some other tasks and finishing my work, I always check the configuration. Looking at the show standby brief output, I noticed that the primary HSRP switch didn’t have any standby switch anymore, as show in the output below:

Interface   Grp  Pri P State   Active          Standby         Virtual IP
Vl1            1    200 P Active    local         10.1.0.3          10.1.0.1
Vl2            2    200 P Active    local         unknown         10.1.2.1

Because the only change was applying the ACL to the SVI, I already know where to search to correct the problem. Adding a deny ip any any log statement at the bottom of the ACL gave me the information I needed to know.

05:48:09.366: %SEC-6-IPACCESSLOGP: list GUEST-DENY-RFC1918 denied udp 10.1.2.2(1985) -> 224.0.0.2(1985), 360 packetsde

The ACL is blocking the multicast HSRP packets. Looking at the log output, you can see that the HSRP multicast IP address is 224.0.0.2 and port UDP/1985 is used. The multi layer switch is using his SVI IP address as source in the HSRP packet.

I changed the ACL on both multi layer switches by adding a statement to allow the HSRP packets. The new ACL is stated below:

ip access-list extended GUEST-DENY-RFC1918
remark Allow DHCP
permit udp any eq bootpc any

remark Allow HSRP PACKETS

permit udp host 10.1.2.[2|3] eq 1985 host 224.0.0.2 eq 1985

remark Deny RFC 1918
deny   ip 10.1.2.0 0.0.1.255 10.0.0.0 0.255.255.255
deny   ip 10.1.2.0 0.0.1.255 172.16.0.0 0.0.15.255
deny   ip 10.1.2.0 0.0.1.255 192.168.0.0 0.0.255.255
remark Allow HTTP / HTTPS
permit tcp 10.1.2.0 0.0.1.255 any eq http

permit tcp 10.1.2.0 0.0.1.255 any eq https

The HSRP packets weren’t blocked anymore after applying the new ACL to the SVI’s. The primary multi layer switch got his secondary switch back.

Applying an ACL to a SVI happens more often, so it is important to remember if you are running some sort of special protocol on the SVI or somewhere else in the configuration when applying an ACL.

Looking at the Internet I found a nice article on Aaron’s Worthless Words blog about multicast addresses, port numbers and associated protocols.