Booches.nl

Citrix Access Gateway: duplicate STA ID

I received complains from a customers who wasn’t able to add two new Citrix servers to his Citrix Access Gateway configuration. He could successfully add the first Citrix server, but he couldn’t add the second Citrix server, because the first was overwritten by the second. I looked at the problem and noticed that both Citrix server were using the same STA Identifier.

After asking some question about the installation of the Citrix server, I discovered that the second Citrix server was a clone of the fist Citrix server. That is why both servers have the same STA Identifier. The STA ID from a Citrix server can be changed by altering the file CtxSta.config. By default a Citrix server has two CtxSta.config files, located at the following destinations (default installation):

• C:\Program Files\Citrix\System32;
• C:\Inetpub\Scripts;

I had to change the STA ID in the C:\Inetpub\Scripts directory, because IIS was used to share port 80 on the server. The CtxSta.config file contains a UID, like the example below:

[GlobalConfig]

UID=STAA3D2D2970C9C

TicketVersion=10

TicketTimeout=100000

MaxTickets=100000

LogLevel=0

MaxLogCount=10

MaxLogSize=20

LogDir=c:\inetpub\Scripts\

; Allowed Client IP addresses
; To change, substitute * with client IP addresses. Use ";" to seperate IP addresses/address ranges.
; To specify a range of IPs always use StartIP-EndIP.
; For example, AllowedClientIPList=192.168.1.1;10.8.1.12-10.8.1.18;123.1.2.3

AllowedClientIPList=*

; SSL only mode
; If set to on, only requests sent through HTTPS are accepted
SSLOnly=off

I changed the UID on the second server and restarted IIS. I tried to add the Citrix server to the Citrix Access Gateway, which is now possible with the new unique STA ID. The last step is adding the second Citrix server to the Citrix WebInterface (server farm & STA ID).

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.