technology, networking and IP telephony
Posts tagged VPN
Nortel VPN Client – Checking for banner text
7November 5, 2008
by Michael McNamara in VPNRouter
With the recent surge in gas prices many employers and employees have taken to telecommuting. The surge has given rise to an avalanche of trouble tickets and support calls from folks trying to use their employers virtual private network solution from their home personal computers and broadband connections.
One typical problem that some users might encounter when using the Nortel VPN client is the “Checking for banner text” message. During the initial stage of connecting the Nortel VPN client will display the “Checking for banner text” message and then either become unresponsive or report to the user that the connection was lost.
Let me paraphrase from the Nortel documentation:
A common reason for the banner message to stop responding is a firewall or router, placed somewhere along the path from the remote computer to the gateway, which blocks ESP or Authentication Header (AH) traffic. The firewall can be a personal firewall installed on the remote computer, a firewall or router at the Internet Service Provider (ISP), or a corporate firewall. In this situation, IPsec Internet Security and Key Management Protocol (ISAKMP) traffic that negotiates the tunnel establishment goes through the tunnel, but the ESP- or AH-encapsulated traffic inside the tunnel does not get through. When the banner text is retrieved through the established tunnel, the banner message or other traffic secured by the ESP or AH never reaches the client and the Nortel VPN Client continues to wait for a response from the gateway until a timeout period is reached. To resolve this issue, ensure the following traffic is allowed to pass through the firewalls along the path:
UDP protocol (17) port 500, both inbound and outbound
ESP protocol (50), both inbound and outbound
AH protocol (51), both inbound and outbound
The same scenario occurs as in the previous section if Network Address Translation Transversal (NAT-T) is configured and the firewall blocks the UDP port selected for NAT-T along the path. To resolve this issue, you’ll need to ensure the port that is being utilized can pass through the firewalls on a personal, corporate, or ISP level. You’ll need to contact whomever is managing the VPN router to determine which UDP port you might need to open.
Cheers!
Nortel VPN Router Configuration Guide
126September 19, 2008
In this post I’ll provide an example of how to configure a Nortel VPN Router. We’ll configure the remote office VPN router for a tunnel with 3DES/SHA1 encryption and DH2 using pre-shared keys, routing all traffic to the main office across the tunnel (no split tunneling). You should start by connecting up to the local console port on the VPN router (the diskless 1100,1050,1010 require a special RJ45 -> DB9 console cable). Log into the VPN router with the default username of “admin” and the default password of “setup” and reset it to factory defaults. You’ll find the option under “R” for “Reset System to Factory Defaults”.Welcome to the Contivity Secure IP Services Gateway Copyright (c) 1999-2004 Nortel Networks, Inc. Version: V05_00.136 Creation date: Aug 20 2004, 15:50:15 Date: 07/23/1980 Unit Serial Number: 11221 Please enter the administrator's user name: admin Please enter the administrator's password: Main Menu: System is currently in NORMAL mode. 1) Interfaces 2) Administrator 3) Default Private Route Menu 4) Default Public Route Menu 5) Create A User Control Tunnel(IPsec) Profile 6) Restricted Management Mode FALSE 7) Allow HTTP Management TRUE 8) Firewall Options 9) Shutdown B) System Boot Options P) Configure Serial Port C) Controlled Crash L) Command Line Interface R) Reset System to Factory Defaults E) Exit, Save and Invoke Changes Please select a menu choice (1 - 9,B,P,C,L,R,E):
The first step will be to configure the IP addressing for the private LAN and public WAN interfaces. Using the serial console select “L) Command Line Interface” from the menu options.
CES>
Upon entering the CLI environment the prompt will be changed to “CES>”. You must now enter privileged mode using the “enable” command entering the default admin password of “setup”.
CES>enable Password: *********
Let’s take care of the easy stuff first. I’m currently working in the Eastern time zone;
CES#clock timezone est CES#clock set 15:22:30 12 JANUARY 2005
You can discern from the syntax above that #clock set <hh:mm:ss> <day> <month> <year>
Now you must enter configuration mode using the commands listed below. We’ll reset the admin password before anything else.
CES#configure terminal Enter configuration commands, one per line. End with Ctrl/z. CES(config)# CES(config)#adminname admin password <standard password>
We’ll configure the private LAN IP Address. In the example below I’m using 10.2.203.1 as the LAN address of the branch office VPN router.
CES(config)#interface FastEthernet 0/1 CES(config-if)#ip address 10.2.203.1 255.255.255.0 CES(config-if)#exit
Next we’ll configure the MANAGEMENT IP Address. The LAN address and management IP address must be on the same subnet.
CES(config)#ip address 10.2.203.10 Management address set to 10.2.203.10 successfully ! Next, make sure Mgt addr and private LAN addr are on same subnet CES(config)#
You should use the IP addressing that’s been assigned to the equipment your configuring in place of the IP addressing used above. Next we’ll assign the public WAN IP Address provided by the Internet Service Provider (ISP) which in this case happens to be Verizon DSL;
CES(config)#interface FastEthernet 1/1 CES(config-if)#ip address 70.256.1.10 255.255.255.0 %Warning: The IP address type is changed from DHCP dynamic to static CES(config-if)#exit CES(config)#ip default-network 70.256.1.1 public CES(config)#ip name-server 151.197.0.38 151.197.0.39 199.45.32.43
NOTE: FastEthernet 0/1 is the PRIVATE LAN while FastEthernet 1/1 is the PUBLIC WAN
Let’s disable those services we won’t be using and enable those we will be using;
CES(config)#no tunnel protocol pptp public CES(config)#no tunnel protocol pptp private CES(config)#no tunnel protocol l2tp public CES(config)#no tunnel protocol l2tp private CES(config)#ipsec encryption 3des-sha1 CES(config)#ipsec encryption aes256-sha1 CES(config)#no ipsec encryption aes128-sha1 CES(config)#no ipsec encryption des40-md5 CES(config)#no ipsec encryption des40-sha1 CES(config)#no ipsec encryption des56-md5 CES(config)#no ipsec encryption des56-sha1 CES(config)#no ipsec encryption hmac-md5 CES(config)#no ipsec encryption hmac-sha1
Let’s configure the “Base” default Branch Office Group with the standard settings.
CES(config)#bo-group ipsec /Base CES(config-bo_group/ipsec)#encryption 3des-sha1 CES(config-bo_group/ipsec)#encryption ike 3des-group2 CES(config-bo_group/ipsec)#antireplay enable CES(config-bo_group/ipsec)#no compress CES(config-bo_group/ipsec)#initial-contact enable CES(config-bo_group/ipsec)#exit
Let’s add a designator for the local network (to be used later – replace with your IP network)
CES(config)#network add LocalNetwork ip 10.2.203.0 mask 255.255.255.0
Let’s add a sub group for our IPsec tunnel configuration;
CES(config)#bo-group add /Base/AcmeHealth CES(config)#bo-conn add Acme-1 /Base/AcmeHealth CES(config)#bo-conn Acme-1 /Base/AcmeHealth CES(config/bo_conn)#conn-type peer2peer CES(config/bo_conn)#local-endpoint 70.256.1.10 CES(config/bo_conn)#remote-endpoint 192.1.1.124 CES(config/bo_conn)#tunnel-type ipsec CES(config/bo_conn)#ipsec authentication text-pre-shared-key password987 CES(config/bo_conn)#routing type static CES(config/bo_conn)#state enable CES(config/bo_conn)#routing static CES(config/bo_conn/routing_static)#local-network LocalNetwork CES(config/bo_conn/routing_static)#remote-network 0.0.0.0 mask 0.0.0.0 state enable cost 1 CES(config/bo_conn/routing_static)#exit
Let’s setup the DHCP relay agent forwarding our DHCP/BOOTP requests to 10.2.16.40;
CES(config)#no service dhcp enable CES(config)#ip default-network 70.20.130.1 public CES(config)#ip dhcp-relay 10.2.203.1 CES(config)#ip dhcp-relay 10.2.203.1 enable CES(config)#ip helper-address 10.2.203.1 server 1 10.2.16.40 CES(config)#ip forward-protocol dhcp-relay
Since we’re routing everything over the IPSec tunnel (the remote-network was 0.0.0.0 with a mask of 0.0.0.0) we need to change the default route preference.
CES(config)#ip default-route-preference private private
That’s the short approach to using the CLI interface to configure the Nortel VPN Router. There is a somewhat old and slow web interface that you can also use to configure the VPN router. You only need to point a web browser to the mangement IP address.
Cheers!
Update: Wednesday December 10, 2008
Here’s the pinout for the special RJ45 to DB9 serial cable used to access the diskless VPN routers;
Cheers!
Juniper SSL VPN Appliance and Windows Vista 64-Bit
11August 12, 2008
by Michael McNamara in Juniper
Update: September 1, 2009
Juniper has released software 6.5 for the Juniper SSL VPN (Secure Access) appliances which now supports running WSAM on Windows 64-bit operating systems. I’ve posted a new article that details the new software which can be found here; http://blog.michaelfmcnamara.com/2009/09/juniper-ssl-vpn-secure-access-6-5-available/
Almost six years ago we deployed a Neoteris Secure Access 1000 appliance which was designed to publish Intranet based web applications to Internet clients. Neoteris was acquired by Netscreen and then Netscreen was acquired by Juniper. Over a year ago we upgraded our legacy hardware with two Juniper SA4000s running them as a cluster in a high availability design (active/standby). The solution has been very successful with the exception of the occasionally home PC that for one reason or another refuses to install the client software.
We recently upgraded to software release v6.2R1 which promised full support for Windows Vista 64-Bit and Juniper’s Windows Secure Application Manager (WSAM). Juniper’s Windows Secure Application Manager is essentially a mini VPN client that tunnels traffic across an SSL connection with the SA4000 appliances. It provides raw connectivity for non-HTTP based applications. While the documentation indicated that Windows Vista 64-Bit was fully supported we were unable to make it work after a few customers reported having issues. We opened a ticket with Juniper and waiting four business days before Juniper was able to confirm our findings; they too were unable to make it work. We were informed the ticket was to be escalated to design but I immediately found it odd that no one else had already reported this problem. In short Juniper informed us that Windows Vista 64-Bit is not supported and the documentation indicating it was support was “incorrect”. Needless to say I’m not very happy with Juniper as this point and it certainly seems that Juniper has some serious QA issues in their software and documentation teams. Let’s not even talk about the 9 business day turnaround which is essentially two weeks.
I recently had a discussion with a physician, remember I work for a large healthcare provider, who had tried in vein to help himself by Googling for any hints or tips to getting WSAM working with Windows Vista 64-Bit. So here are some tips that will hopefully get picked up by Google.
- You must be an Administrator to install the software components
- You’ll need to be running Windows XP (32-Bit) Service Pack 2 or later
- If you have a pop-up blocker enabled make sure you exempt the Juniper URL
- If you have your firewall enabled make sure you unblock WSAM
I’ve also seen issues if ActiveX, JavaScript, or Cookies are disabled from within Internet Explorer. The WSAM software is a Layered Service Provider (LSP) application and as such other software, malware, spyware, etc can sometimes interfere with it’s proper operation. You can have a look here for a utility that might help to clean up any LSP issues that you might have.
The Windows Secure Application Manager can not be run from within a Windows Terminal Server or Citrix session.
Cheers!
Update: August 13, 2008
I recieved a few questions about Juniper’s Windows Secure Application Manager (WSAM) and I thought I would pass on the questions and answers.
Q. Does Juniper’s WSAM support a proxy server?
A. No Juniper’s WSAM does not support a proxy server. The client will need direct Internet access on TCP 443 (https).
Q. Where are the log files, there’s nothing in C:\Program Files\Juniper Networks\Secure Application Manager?
A. The log file is actually stored in the following location; C:\Documents and Settings\<username>\Application Data\Juniper Networks\Secure Application Manager
Update: September 18, 2008
As noted in the comments Juniper has released a customer bulletin concerning the problem. Here’s the official response I received from the Juniper TAC, I haven’t received any follow-up from the sales team which the Juniper TAC referred me to.
“KB12097 was posted to our Knowledge Base Support site and engineering has implemented a check in the WSAM installation that will display an error to the user if they are attempting to install WSAM on a 64-bit Operating System. This fix should be available in the next maintenance release of IVE OS 6.2. As for future support for WSAM on 64-bit systems, this has been revisited by PLM and it is now on our roadmap.”
Update: October 5, 2008
I’m amazed at the number of views that this post has garnered. It seems there are quite a few folks out there trying to figure out why Windows Vista 64bit won’t work with WSAM. I thought I should point out that the Juniper Network Connect client is compatible with Windows Vista 64bit (and 32bit). This may be an option for users although those users will need to speak to their System Administrators since it will require additional configuration and perhaps even licensing.
Cheers!
