VPN, IPsec, IPfw, Natd, oh my! HELP!
noneofyourbusiness
My company offers remote access from home through a Nortel Contivity VPN
gateway on the Internet (which uses IPsec w/ ISAKMP only, no PPTP). The
client is for windows-only. I have a cable modem line to my house for
Internet acess, which terminates on a FreeBSD 4.0 box. Since I'm only
provided with one publically routable IP address, I'm running NATd to
provide Internet access to my internal machines (implemented with
non-routable (10.0.0.0/8) addresses). I also have firewall rules
implemented with the ipfw toolset. My internal clients are windows-based.
I've been unsuccessful (so far) with the VPN client running on an internal
windows machine (i believed this is called 'transport mode'). Anyways,
based on some troubleshooting I've been able to do on the firewall, I can
1) see my internal windows machine talking back-and-forth (bi-directional)
to the remote vpn gateway over UDP port 500 multiple times (say about 20
times each way, back and forth, one packet at a time)...
2) then my internal client sends a series of packets (about twenty-five
times) over "port 50" to the remote gateway, with no apparent response back
(from the gateway). The reason I put quotes around the word port above, is
that my ipfw log states it with a "P:50" in the log file, such as:
Jun 3 16:17:03 myBSDmachine /kernel: ipfw: 1100 Accept P:50 10.2.1.47
<company VPN gateway> in via ed1
Jun 3 16:17:03 myBSDmachine /kernel: ipfw: 1100 Accept P:50 10.2.1.47
<company VPN gateway> out via ed0
where ed1 is the interface to my internal network and ed0 to the
Internet. These two entries repeat about 25 times in a row.
3) then that's about it. I get a couple more UDP port 500 handshakes...
which may be when I disconnect the client.
From the client perspective, it definitely validates my password & appears
to connect... but I have NO connectivity to the corporate network.
The whole time, I never see any TCP traffic in the firewall logs (when I'm
logging all denied packets & packets with a src or dest of the gateway).
I'm wondering if the remote gateway is initiating a TCP (or UDP even)
connection to me on a "new port", and hence, NAT doesn't/can't forward that
new connection to my internal windows machine since there's no association
to reference. The problem is I don't know IPsec protocols and dialogs well
enough to know if this is the problem, and if so, which ports I need to tell
NAT to forward to the internal client.
So is it possible to get an IPsec client running in transport mode to work
through a Freebsd NAt'd firewall & how do I do it? Do I simply map inbound
ports 50 & 51 to one internal 10.x address? Or can I get it working
"dynamically" with all internal clients? How?
If not, do you know for sure? And what/where do I have to look to get
tunnel mode working on the FreeBSD box concurrently with "normal" internet
browsing for the same internal client? IOW, how do I tell the firewall to
route corporate-based resources over the VPN tunnel, versus Internet
resources over the same interface, but outside the tunnel? Do you establish
some sort of static routes for the corproate based traffic?
thanks for all help,
Brian
__________________________________________________________________________
I was searching the FreeBSD archives and found a similiar question/response,
but not the full answer:
From owner-freebsd-questions Thu Jun 15 7:10: 0 2000
Delivered-To: freebsd-...@freebsd.org
Received: from plains.NoDak.edu (plains.NoDak.edu [134.129.111.64])
by hub.freebsd.org (Postfix) with ESMTP id 9DF2E37C39E
for <ques...@FreeBSD.ORG>; Thu, 15 Jun 2000 07:09:56 -0700 (PDT)
(envelope-from ting...@plains.NoDak.edu)
Received: (from tinguely@localhost)
by plains.NoDak.edu (8.9.3/8.9.3) id JAA27285;
Thu, 15 Jun 2000 09:09:54 -0500 (CDT)
Date: Thu, 15 Jun 2000 09:09:54 -0500 (CDT)
From: Mark Tinguely <ting...@plains.NoDak.edu>
Message-Id: <2000061514...@plains.NoDak.edu>
To: ghor...@alumni.indiana.edu, ques...@FreeBSD.ORG
Subject: Re: IPSEC through natd
Sender: owner-freeb...@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
> My company uses the Nortel VPN client (IPSEC w/ ISAKMP according to
> the docs) for VPN access to our network. Unfortunately, my cable modem
> service only provides one IP. To get around this, I use natd and ipfw on
> my FreeBSD box. Is it possible to use my VPN client from a win98 box
> on private side of my FreeBSD box?
does the Win98 box use tunnel or transport mode?
The tunnel mode could be endpointed on the FreeBSD/NAT machine, but
not forwarded to the Win98 machine.
--mark.
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the me
----------------------------------------------------------------------------
----
Gregory Bond
> Can someone give me a hand on this one???
IIUC, you simply cannot use IPSec transport mode with natd, because
the packet re-writing that natd does causes the checksum of the
encapsulated packets to fail. You have to do terminate the IPSec
tunnel on the gateway itself.
But I'm open to correction from the real experts on IPsec.
Gordon Burditt
>gateway on the Internet (which uses IPsec w/ ISAKMP only, no PPTP). The
>client is for windows-only. I have a cable modem line to my house for
>Internet acess, which terminates on a FreeBSD 4.0 box. Since I'm only
>provided with one publically routable IP address, I'm running NATd to
>provide Internet access to my internal machines (implemented with
>non-routable (10.0.0.0/8) addresses). I also have firewall rules
>implemented with the ipfw toolset. My internal clients are windows-based.
I believe IPsec is fundamentally incompatible with NAT if you have
to put a non-public IP into the configuration for the system on
the public side. Also, translating IP addresses in VPN'd packets
tends to break authentication since the MAC no longer matches.
You might get away with tunnel mode between the company LAN and
the gateway FreeBSD machine, but you'd have to turn off VPN entirely
on the Windows machines. (Presumably your home LAN is reasonably
secure from outside snooping, unless one of your kids works for a
competitor). Compile a FreeBSD kernel with IPSEC enabled and
install the racoon port.
>I've been unsuccessful (so far) with the VPN client running on an internal
>windows machine (i believed this is called 'transport mode'). Anyways,
>based on some troubleshooting I've been able to do on the firewall, I can
>
>1) see my internal windows machine talking back-and-forth (bi-directional)
>to the remote vpn gateway over UDP port 500 multiple times (say about 20
>times each way, back and forth, one packet at a time)...
The UDP port 500 stuff is the key exchange. This part is probably
working.
>2) then my internal client sends a series of packets (about twenty-five
>times) over "port 50" to the remote gateway, with no apparent response back
That's Protocol 50 (esp). That's how the encapsulated encrypted
packets are transmitted.
>(from the gateway). The reason I put quotes around the word port above, is
>that my ipfw log states it with a "P:50" in the log file, such as:
>
>Jun 3 16:17:03 myBSDmachine /kernel: ipfw: 1100 Accept P:50 10.2.1.47
><company VPN gateway> in via ed1
>Jun 3 16:17:03 myBSDmachine /kernel: ipfw: 1100 Accept P:50 10.2.1.47
><company VPN gateway> out via ed0
>
> where ed1 is the interface to my internal network and ed0 to the
>Internet. These two entries repeat about 25 times in a row.
>
>3) then that's about it. I get a couple more UDP port 500 handshakes...
>which may be when I disconnect the client.
>
>
>From the client perspective, it definitely validates my password & appears
>to connect... but I have NO connectivity to the corporate network.
The problem: the corporate network is trying to send to a non-public
IP, which doesn't get routed anywhere.
>The whole time, I never see any TCP traffic in the firewall logs (when I'm
>logging all denied packets & packets with a src or dest of the gateway).
Except for the key exchange, you won't see un-encapsulated TCP or
UDP. All of it is encapsulated and encrypted in Protocol 50 (esp)
or Protocol 51 (ah). tcpdump won't be able to dump that (it's encrypted).
>I'm wondering if the remote gateway is initiating a TCP (or UDP even)
>connection to me on a "new port", and hence, NAT doesn't/can't forward that
>new connection to my internal windows machine since there's no association
>to reference. The problem is I don't know IPsec protocols and dialogs well
>enough to know if this is the problem, and if so, which ports I need to tell
>NAT to forward to the internal client.
It's worse. If the company LAN can't send packets to what your
client machine thinks is its IP, the connection won't work. The
packets never reach you at all. NAT can't translate packets where
the IP address is put INSIDE the data payload, especially if it's
encrypted or NAT doesn't know the packet format. IPSec doesn't
really have any idea about sending stuff to an IP different from
what the other endpoint thinks its IP is.
>So is it possible to get an IPsec client running in transport mode to work
>through a Freebsd NAt'd firewall & how do I do it? Do I simply map inbound
>ports 50 & 51 to one internal 10.x address? Or can I get it working
>"dynamically" with all internal clients? How?
I'd say your best hope is to establish a transport mode WITH THE
GATEWAY machine ONLY (a windows machine probably makes a poor
gateway, and you can only handle one machine this way), or use
tunnel mode between the gateway machine and the company LAN (turn
off VPN on the machines on your LAN other than the gateway).
>If not, do you know for sure? And what/where do I have to look to get
>tunnel mode working on the FreeBSD box concurrently with "normal" internet
>browsing for the same internal client? IOW, how do I tell the firewall to
>route corporate-based resources over the VPN tunnel, versus Internet
>resources over the same interface, but outside the tunnel? Do you establish
>some sort of static routes for the corproate based traffic?
If you use tunnel mode, a gifN interface is used to collect traffic
to go through the tunnel. Assuming you know the relevant IP blocks of
your corporate LAN, you can use static routes. You will probably need
to run NAT on two interfaces, one for the VPN and one for the Internet
at large.
Gordon L. Burditt
Michele Possamai
> Can someone give me a hand on this one???
>
> My company offers remote access from home through a Nortel Contivity VPN
> gateway on the Internet (which uses IPsec w/ ISAKMP only, no PPTP). The
> client is for windows-only. I have a cable modem line to my house for
> Internet acess, which terminates on a FreeBSD 4.0 box. Since I'm only
> provided with one publically routable IP address, I'm running NATd to
> provide Internet access to my internal machines (implemented with
> non-routable (10.0.0.0/8) addresses). I also have firewall rules
> implemented with the ipfw toolset. My internal clients are windows-based.
>
> I've been unsuccessful (so far) with the VPN client running on an internal
> windows machine (i believed this is called 'transport mode'). Anyways,
> based on some troubleshooting I've been able to do on the firewall, I can
>
> 1) see my internal windows machine talking back-and-forth (bi-directional)
> to the remote vpn gateway over UDP port 500 multiple times (say about 20
> times each way, back and forth, one packet at a time)...
>
that's for key exchange.. so security
install racoon from ports to make that work..
>
> 2) then my internal client sends a series of packets (about twenty-five
> times) over "port 50" to the remote gateway, with no apparent response back
> (from the gateway). The reason I put quotes around the word port above, is
> that my ipfw log states it with a "P:50" in the log file, such as:
>
that doesn't mean port 50 but protocol 50
esp I think.. (check /etc/protocols)
that's used for ipsec security
>
> Jun 3 16:17:03 myBSDmachine /kernel: ipfw: 1100 Accept P:50 10.2.1.47
> <company VPN gateway> in via ed1
> Jun 3 16:17:03 myBSDmachine /kernel: ipfw: 1100 Accept P:50 10.2.1.47
> <company VPN gateway> out via ed0
>
since you're connecting on a 10.x.x.x ip I guess it's running in a tunnel...
>
> where ed1 is the interface to my internal network and ed0 to the
> Internet. These two entries repeat about 25 times in a row.
>
> 3) then that's about it. I get a couple more UDP port 500 handshakes...
> which may be when I disconnect the client.
>
> From the client perspective, it definitely validates my password & appears
> to connect... but I have NO connectivity to the corporate network.
>
> The whole time, I never see any TCP traffic in the firewall logs (when I'm
> logging all denied packets & packets with a src or dest of the gateway).
> I'm wondering if the remote gateway is initiating a TCP (or UDP even)
> connection to me on a "new port", and hence, NAT doesn't/can't forward that
> new connection to my internal windows machine since there's no association
> to reference. The problem is I don't know IPsec protocols and dialogs well
> enough to know if this is the problem, and if so, which ports I need to tell
> NAT to forward to the internal client.
>
> So is it possible to get an IPsec client running in transport mode to work
> through a Freebsd NAt'd firewall & how do I do it?
yes you can.
I have it working at home.. not with my company but with a friend of mine..
check out http://www.daemonnews.org/200101/ipsec-howto.html
that'll explain a lot..
you'll have to tweak lots of stuff but this could be a big start for you..
> Do I simply map inbound
> ports 50 & 51 to one internal 10.x address? Or can I get it working
> "dynamically" with all internal clients? How?
make a route to that 10.x.x.x network on your freebsd box..
that way connections to that 10.x.x.x network will automaticly be forwarded over
that ipsec connection and your network at home has access to that...
don't forget to adjust firewall rules if you're using them
>
>
> If not, do you know for sure?
I'm sure you can do it..
> And what/where do I have to look to get
> tunnel mode working on the FreeBSD box concurrently with "normal" internet
there's some tunnelmode in ipsec..
you'll find some pointers in that site I gave you a few lines back..
change 'transport' to 'tunnel' somewhere..
or you could use gif.... but I doubt that'll work in your case..since you need
connection from both sides to get that to work. and you're the only one
connecting in this case (as far as I understand)
noneofyourbusiness
Gordon, after reading your post, the lightbulb started to turn on and I had
a few ideas as to why it wasn't working. Michele, you confirmed my
belief... the URL you referenced in your reply, in-turn, references RFC
2663, "IP Network Address Translator (NAT) Terminology and
Considerations"... which spells out my problem to a T & explains that it *IS
IMPOSSIBLE* to run IPsec in transport mode through NAT (reguardless if the
internal IPs are routable or not)!!! The rest of this post is to document
the answer for future people in need.
The reason running IPsec in transport mode through NAT is impossible is
described in section 7.0 of RFC 2663 (http://rfc.net/rfc2663.html). The
root cause is that NAT, by nature, changes the IP header of a packet when it
replaces the IP addresses and checksum. This change invalidates the IPsec
checksum functionality & the receiving end, therefore, discards all packets
communicated. The reason the UDP port 500 dialog occured successfully is
that it (IKE) is not protected by IPSEC AH and ESP. That's why the
conversation that I saw consisted of UDP 500 bi-directional & only protocol
50 outbound. The remote corporate gateway was/is dropping all of my
protocol 50 packets due to invalid checksums!!!!
Here is short paraphrase from the RFC:
Application layer security techniques that do not make use of or
depend on IP addresses will work correctly in the presence of NAT
(e.g., TLS, SSL and ssh). In contrast, transport layer techniques
such as IPSec transport mode or the TCP MD5 Signature Option RFC 2385
[Ref 17] do not.
In IPSec transport mode, both AH and ESP have an integrity check
covering the entire payload. When the payload is TCP or UDP, the
TCP/UDP checksum is covered by the integrity check. When a NAT device
modifies an address the checksum is no longer valid with respect to
the new address. Normally, NAT also updates the checksum, but this is
ineffective when AH and ESP are used. Consequently, receivers will
discard a packet either because it fails the IPSec integrity check
(if the NAT device updates the checksum), or because the checksum is
invalid (if the NAT device leaves the checksum unmodified).
It may be of interest to note that IKE (Session key negotiation
protocol) is a UDP based session layer protocol and is not protected
by network based IPsec security. Only a portion of the individual
payloads within IKE are protected. As a result, IKE sessions are
permissible across NAT, so long as IKE payload does not contain
addresses and/or transport IDs specific to one realm and not the
other. Given that IKE is used to setup IPSec associations, and there
are at present no known ways of making IPSec work through a NAT
function, it is a future work item to take advantage of IKE through a
NAT box.
noneofyourbusiness <nob...@nowhere.com> wrote in message
news:tkBS6.26060$DG1.4...@news1.rdc1.mi.home.com...
Michele Possamai
in that case it would be possible.. I have that at home..
But I use it in a gif tunnel.... that might be a big difference..
noneofyourbusiness schreef:
--
-----------------------------------------------
Michele Possamai Tel: 015-8881131
Casema IT Applicatiebeheer
mpos...@office.casema.nl
Image is nothing, bandwidth is everything.
-----------------------------------------------
Urban A. Haas
> First, I'd like to thank Greg, Gordon and Michelle for the helping hand.
> Gordon, after reading your post, the lightbulb started to turn on and I
had
> a few ideas as to why it wasn't working. Michele, you confirmed my
> belief... the URL you referenced in your reply, in-turn, references RFC
> 2663, "IP Network Address Translator (NAT) Terminology and
> Considerations"... which spells out my problem to a T & explains that it
*IS
> IMPOSSIBLE* to run IPsec in transport mode through NAT (reguardless if the
> internal IPs are routable or not)!!! The rest of this post is to document
> the answer for future people in need.
>
> The reason running IPsec in transport mode through NAT is impossible is
> described in section 7.0 of RFC 2663 (http://rfc.net/rfc2663.html). The
> root cause is that NAT, by nature, changes the IP header of a packet when
it
> replaces the IP addresses and checksum. This change invalidates the IPsec
> checksum functionality & the receiving end, therefore, discards all
packets
> communicated. The reason the UDP port 500 dialog occured successfully is
> that it (IKE) is not protected by IPSEC AH and ESP. That's why the
> conversation that I saw consisted of UDP 500 bi-directional & only
protocol
> 50 outbound. The remote corporate gateway was/is dropping all of my
> protocol 50 packets due to invalid checksums!!!!
>
I'm not sure this is 100% correct. The only addresses that should be
modified by NAT are on the outermost layer of the packet, the AH / ESP layer
with the encapulaseted layer completely transparent. This would be fine
except (and this is what should be screwing everything up):
NAT only supports IP's TCP and UDP protocols. AH and ESP, being different IP
protocols, as indicated in a prior post, don't work with NAT. There are
others, other VPN modes and protocols built on IP, but not really TCP or UDP
(since the protocol number is different) don't work with NAT at all.
From my experience, anything that's not TCP or UDP doesn't work with NAT.
The reason the Key Exchange works, is it's UDP. Once the alternate protocol
kicks in, they just don't make it past the NAT boundary. That should be the
real issue. Remember we're talking protocols, not ports here.
noneofyourbusiness
SMC, Linksys and others sell include a feature called "IPsec Pass-through"
that allows a VPN to work through NAT. My question is what exactly does
this feature do? It very well may be addressing what you're noting.. that
non TCP and UDP protocols like ESP don't work with the standard NAT solution
& IPsec pass-through somehow plugs the packet through w/o changing <enough>
of the header to force ESP to discard the packet. I also noticed that
ipmasq for Linux, in it's latest releases, also supports a VPN pass-through
"patch"...
Problem is, of course, I can't determine what and how exactly this IPsec
pass-through works to try and implement on BSD...
Urban A. Haas <uh...@urbantechnology.com> wrote in message
news:UiTT6.811$Ey1....@newsfeed.slurp.net...
J.C.A.
> Can someone give me a hand on this one???
You probably could do a static port redirection to one and only one
Windows client. But you need to know exactly what ports the VPN
client uses. The other option is getting additional non-RFC 1918
addresses from your cablemodem provider. Do static redirection to
them. Set up aliases on your outside interface, redirect them an
internal IP on your LAN (i.e. static NAT).
Personally, I believe part of your problem is Nortel. I have had a
trouble ticket in with them for over 1 year (case was opened Oct 1999)
on the SNMP agent for a Baystack 303 that was purchased with an
Assurance NBD contract. This case affects all NMS products; HP
OpenView, Spectrum, et. al. If you can't get the ifTable and
dot1dbridge MIB tree right, it's time to throw it in the trash.
They finally told me two months ago that "Sorry, you're SOL. It's a
discontinued product. Have a nice day. We have no intention of
upgrading the firmware any farther if there are still issues. It
doesn't matter that your case was opened on Oct 1999 and it's now
March 2001." The case was passed through four or five engineers
because of such a high turn over in the company. Given this track
record with Nortel. You may get a complete answer from Nortel on this
in 3 to 9 months if you don't find a bug in their client or
concentrator on what ports need redirecting behind a NAT gateway.
You'd get faster results engineering the ACL or rules for redirection
yourself. But you only get a single client up that way.
If you have any pull and can return it, do yourself a favor. Return
that Nortel garbage and get a Cisco VPN concentrator. My employer has
a 3004 which will be upgraded to the concentrator that supports 10K
users within a fiscal year or two. I can do everything on a client
machine over the VPN connection through my FreeBSD 4.2 machine running
natd and ipfw. Upgrade IOSes via tftp, authenticate to the NetWare
5.x tree, our NT domains or Win2K domains. I could probably set up a
NetWare/IP client and mount NetWare 4.x volumes on a client machine.
Granted, it probably uses PPTP which is the way to do it if you're
behind a NAT gateway.
I'm just sharing my experiences with Nortel products. IMO, you're
doomed if you have Nortel or Alcatel equipment in your network. This
comes from much personal experience and consumption of OTC pain
relievers; ibuprofen and acetaminophen.
- -
John A.
nx...@my-deja.com
cindy
"J.C.A." wrote:
>
> "noneofyourbusiness" <nob...@nowhere.com> wrote in message news:<tkBS6.26060$DG1.4...@news1.rdc1.mi.home.com>...
>
> > Can someone give me a hand on this one???
>
> You probably could do a static port redirection to one and only one
> Windows client. But you need to know exactly what ports the VPN
> client uses.
I'm using OpenBSD with ipf and ipnat.
This is exactly what I did and it works great.
My ipf.rules lets in port 500 and protocols 50 and 51 in. (These
are the port and protocols used by the Nortel VPN used by my
employer.) It only accepts input from my employer's IP block.
ipnat.rules specifically does not translate the windows machine I
use for the VPN (everything else gets translated). It also
redirects all input on port 500 to port 500 that machine.
I had a lot of confusion setting this up and had become convinced
that it wasn't possible before someone on the openbsd newsgroup
set me straight.
I hope this is helpful.
Cindy
--
Sorry for the SPAM block -
My real address is Cindy at Ballreich dot net
Mitch Tobias
>
> My company offers remote access from home through a Nortel Contivity VPN
> gateway on the Internet (which uses IPsec w/ ISAKMP only, no PPTP). The
> client is for windows-only. I have a cable modem line to my house for
> Internet acess, which terminates on a FreeBSD 4.0 box. Since I'm only
> provided with one publically routable IP address, I'm running NATd to
> provide Internet access to my internal machines (implemented with
> non-routable (10.0.0.0/8) addresses). I also have firewall rules
> implemented with the ipfw toolset. My internal clients are windows-based.
>
> ----
I ran into a similar problem using the Nortel Client (ESP Security) with a
home network very similar to yours: Road Runner cable modem --> FreeBSD 4.0
w/IPFW and NAT --> internal Windows PC's. I run the Nortel Extranet Client
on the Windows PC with internal address 192.168.0.2
The solution that worked for me was to add a rule near the top of my ipfw
ruleset such as: allow ip from <company's VPN gateway> to any
Also, my natd.conf contains:
interface ed0
use_sockets yes
same_ports yes
unregistered_only yes
dynamic yes
pptpalias 192.168.0.2
This has worked for me. Hope it helps....
James T. Dennis
> Actualy I thought you were gonna run the ipsec tunnel stuff on your nat-router
> in that case it would be possible.. I have that at home..
> But I use it in a gif tunnel.... that might be a big difference..
> noneofyourbusiness schreef:
What is gif (in this context)?
Mike Andrews
:> noneofyourbusiness schreef:
IPV6 generic tunnel interface device; try `man gif`.
--
"I don't have any solution but I certainly admire the problem."
-- Ashleigh Brilliant
J.C.A.
>> You probably could do a static port redirection to one and only one
>> Windows client. But you need to know exactly what ports the VPN
>> client uses.
>
> I'm using OpenBSD with ipf and ipnat.
> This is exactly what I did and it works great.
>
> My ipf.rules lets in port 500 and protocols 50 and 51 in. (These
> are the port and protocols used by the Nortel VPN used by my
> employer.) It only accepts input from my employer's IP block.
>
> ipnat.rules specifically does not translate the windows machine I
> use for the VPN (everything else gets translated). It also
> redirects all input on port 500 to port 500 that machine.
>
> I had a lot of confusion setting this up and had become convinced
> that it wasn't possible before someone on the openbsd newsgroup
> set me straight.
>
> I hope this is helpful.
I didn't doubt it was doable. But was it worth the effort? My
employer's Cisco 3004 works without a problem.
I just heard the quarterly earnings report and Nortel lost $19.2
billion and is getting ready to lay off another 10K of employees.
This, the stupidity of their VPN client and the almost two year issue
I've had with a Baystack 303 SNMP agent makes me have more contempt
for Nortel than I do for Sprint.
To add insult to injury, I received an e-mail from Nortel support that
my SNMP agent case from Oct 1999 was assigned to yet another engineer.
The previous five must have gotten laid off along with the firmware
developers.
cindy
"J.C.A." wrote:
>
> I didn't doubt it was doable. But was it worth the effort? My
> employer's Cisco 3004 works without a problem.
Well, like most things, once I got a clue it was almost no effort
at all. Getting the clue was worth the effort.
>
> I just heard the quarterly earnings report and Nortel lost $19.2
> billion and is getting ready to lay off another 10K of employees.
> This, the stupidity of their VPN client and the almost two year issue
> I've had with a Baystack 303 SNMP agent makes me have more contempt
> for Nortel than I do for Sprint.
>
> To add insult to injury, I received an e-mail from Nortel support that
> my SNMP agent case from Oct 1999 was assigned to yet another engineer.
> The previous five must have gotten laid off along with the firmware
> developers.
Yeah, that's a drag. However, our IT staff never asked me what to
do. They just said "here's the VPN, use it", so that's what I'm
doing. It seems to work pretty well. If they change it, I'll
learn to deal with it.