Allowing VPN Pass Through in a Nortel VPN/FireWall Connectivity Device

Posted on 2005-04-15
Last Modified: 2011-10-03
I use two types of VPN Clients, Microsoft VPN and Checkpoint VPN to access external sites.  Both of these connections work from one of my networks, lets call it OFFICE1, which uses SmoothWall FireWall.

When I try to use the Microsoft VPN from the network OFFICE2, which uses Nortel VPN/FireWall Connectivity 1050, it does not work, but the Checkpoint VPN does.  So, the problem has to be with the Nortel Device.  I'm am a little familiar with the Nortel Device, but not sure how to allow the MS VPN connection going outbound.

There aren't any outbound Filters set up (that I know of), and I have 3 VPN Tunnels set up with offsite companies.  Is there some option I have to turn on that allows VPN Pass Through?  (The Nortel Device has Software Version V04_80.124)  It's my understanding that MS VPN uses LT2P/IPsec.  I'm not sure what Checkpoint uses.

To clarify, the VPN Client Connections have nothing to do with the VPN Tunnels, and the Tunnels may be unimportant information.  This may or may not be an easy question, but I have employees waiting to work from OFFICE2 that need to use the MS VPN Client.

Thanks for your help in advanced.
Question by:excelacom
    LVL 7

    Expert Comment

    are the MS clients in office1 connecting to the same server as the MS clients from office2 ?

    Generally how vpn clients communicate with vpn servers is a funciton of the VPN server's capabilities/configuration.

    Newer implementations generally adopt some sort of 'nat-transversal' scheme, which basically will encapsulate non-port-aware protocols like ESP/GRE or nat-unfriendly communications (IKE) in UDP or sometimes TCP packets so that they can be port translated through nat-overload interfaces.

    So, that being said, I'm curious about the destination servers to which the MS Clients are connecting. The other thing that should be investigated is how you have your nat pools set up at the two offices...maybe you have some one-to-one NAT at Office1 that's permitting the MS clients to go through and not in Office2 because it's all overloading to a single address.

    The other thing is that if the MSServers are different to which the clients are connecting, maybe one of the servers isn't configured to support nat-transversal.


    Author Comment

    The MS clients from office1 & office2 are going to the same VPN Server.  Whatever configuration that needs to be made has to be done on the Nortel Device, because that is the only point of failure.

    There is not a one-to-one mapping on either firewall (the VPN Server is on an ISA FireWall, and it will allow multiple logins from the same IP).  So when employees go outside of our network, they all have the same external IP.

    Thanks for you help.
    LVL 7

    Expert Comment

    Well, since the checkpoint client works fine from office 2, I might be inclined to still look some more at the MS client side, just to be certain. The Contivity switch shouldn't really care about whether the client-server traffic is MS or CP. If NAT-T has been enabled on the servers and the client supports it, it should just work.

    Might this apply to clients at Office2?
    L2TP/IPsec NAT-T update for Windows XP and Windows 2000;en-us;818043

    i.e. perhaps patch was applied at office1 and not office2? Or is there a way to have a laptop that works at office1 try making the same connection from office2?

    here's something else that might be worth reading:
    IPSec NAT-T is not recommended for Windows Server 2003 computers that are behind network address translators;en-us;885348


    Author Comment

    I have moved computers that worked from office1 to office2 and the MS VPN did not work.  One compuer had Windows 2000 and another had XP.

    Not sure if this will help, but below are some trace logs the Nortel Device. is an example external IP (shown below) that represents the VPN Server and the 172.x.x.x IP was the computer trying to make the VPN Connection.

    The connection gets to the point where it is Verifying the User/Pass and just hangs there.  So the VPN Client is reaching VPN  Server, but hanging after that.

    04/19/2005 16:00:30 0 CSFW [03] Free SN_tuple for destroy conv; conv=5e9ca7c, tuples=6017b68, num_tuples=2
    04/19/2005 16:00:36 0 CSFW [03] Alloc SN_tuple for new conv; conv=5e9ca7c, tuples=57c2a90
    04/19/2005 16:00:36 0 CSFW [03] Create new conv 5e9ca7c
    04/19/2005 16:00:36 0 CSFW [03] Creat flow 5f7a154 h 5e9ca7c s:ac19008f:1935 d:97c8c622:1723 p:6 d:0
    04/19/2005 16:00:36 0 CSFW [03] Create new flow 5f7a154 add to domain 2(714f778)
    04/19/2005 16:00:36 0 CSFW [03] Creat flow 5f768a8 h 5e9cabc s:97c8c622:1723 d:ac19008f:1935 p:6 d:1
    04/19/2005 16:00:36 0 CSFW [03] Add peer-flow 5f768a8 to domain: 714f77c key 2625
    04/19/2005 16:00:36 0 CSFW [03] Alloc SN_tuple for new conv; conv=5e9653c, tuples=57eb1b8
    04/19/2005 16:00:36 0 CSFW [03] Create new conv 5e9653c
    04/19/2005 16:00:36 0 CSFW [03] Creat flow 5f7c054 h 5e9653c s:ac19008f:0 d:97c8c622:0 p:47 d:0
    04/19/2005 16:00:36 0 CSFW [03] Create new flow 5f7c054 add to domain 2(714f778)
    04/19/2005 16:00:36 0 CSFW [03] Creat flow 5f7dc6c h 5e9657c s:97c8c622:0 d:ac19008f:0 p:47 d:1
    04/19/2005 16:00:36 0 CSFW [03] Create new unknown peer-flow(5f7dc6c) for flow:5f7c054
    04/19/2005 16:00:36 0 CSFW [03] Drop packet 6a1d390:(,gre), reason 1
    04/19/2005 16:00:36 0 CSFW [03] Add peer-flow 5f7dc6c to domain: 714f77c key 2753
    04/19/2005 16:00:36 0 CSFW [03] svcmgr_remove_flow_from_domain -> rm flow 5f7c054 from ts 714f77c
    04/19/2005 16:00:36 0 CSFW [03] svcmgr_remove_flow_from_domain -> rm flow 5f7dc6c from ts 714f77c

    Author Comment

    Also, point I had forgotten to mention is the MS VPN Client runs over PPTP not L2TP.  Sorry for the confusion.
    LVL 7

    Accepted Solution

    Dang. The MS patch would have been the low-hanging-fruit answer :P

    so: it looks like the nortel box's debug output shows the beginning of the failure here:
    04/19/2005 16:00:36 0 CSFW [03] Drop packet 6a1d390:(,gre), reason 1

    Showing that it's dropping the GRE packet (IP Protocol 47, part of the pptp specification) due to 'reason 1'

    Inlooking through the nortel documentation:

    I found this:
    IPsec-aware NAT

    IPsec-aware NAT provides a means of protecting against the alteration of TCP/IP headers, usually performed by NAT. IPsec-aware NAT is used when an IPsec tunnel passes through a Contivity gateway performing NAT translation, but does not terminate at the Contivity gateway. This allows inter operability with IPsec implementations that do not support the UDP wrapper solution to perform NAT on IPsec traffic. Unlike NAT traversal, IPsec-aware NAT is always on and cannot be configured.

    It doesn't appear that they make any provision for pptp, which uses GRE as it's encapsulating protocol, rather than ESP, which shares very similar characteristics (stateless, portless).

    So, you are indeed correct. It's definitely how the Nortel handles the natting of stateless/portless protocols...they've made a special accommodation for IPSec, but not PPTP.

    Suggestions at this point:

    a) Open a case with Nortel to see if they have some sort of workaround (I can't find mention of PPTP in the docs, but I don't have a support logon, which may provide you more access)
    b) Use secpol.msc to build secure, IPSec connections from the clients to the server.
    c) burn an additional public IP address or range for 1-1 nat from the client to the server - perhaps utilizing a application-mode server at the client site so that the clients could RDP into it and use it's statically natted 1-1 nat translation to get to the MS Server.
    d) get a different firewall/vpn solution.

    Probably not the news you wanted to hear, but it's a direction :-/


    Author Comment

    Thanks a lot for you help.  We will open a ticket with Nortel to see what our options are with that device.

    Featured Post

    IT, Stop Being Called Into Every Meeting

    Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

    Join & Write a Comment

    In this tutorial I will show you with short command examples how to obtain a packet footprint of all traffic flowing thru your Juniper device running ScreenOS. I do not know the exact firmware requirement, but I think the fprofile command is availab…
    In the world of WAN, QoS is a pretty important topic for most, if not all, networks. Some WAN technologies have QoS mechanisms built in, but others, such as some L2 WAN's, don't have QoS control in the provider cloud.
    After creating this article (, I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
    After creating this article (, I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…

    732 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    20 Experts available now in Live!

    Get 1:1 Help Now