Search
	display results
words begin exact words any words part
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [FW1] SecuRemote 4166/Win2K changes from udp to esp mid-sessi on

To: "'Steven Lee'" <[email protected]>
Subject: RE: [FW1] SecuRemote 4166/Win2K changes from udp to esp mid-sessi on
From: "Minder, Brian" <[email protected]>
Date: Fri, 12 Jan 2001 13:38:08 -0500
Cc: "'[email protected]'" <[email protected]>
Sender: [email protected]
The tcpdumps below are from a non-NAT'ed client scenario.  With a client
behind a NAT device, the session fails with "Communication to site SITENAME
has failed" on the client when the udp->esp change happens.  After the
session fails, the client must be rebooted in order to reconnect.  The NAT
device is doing both NAT and PAT.

Thanks,

-Brian

--
Brian Minder <[email protected]>
Systems and Network Engineering, onehealthbank.com> -----Original Message-----
> From: Steven Lee [mailto:[email protected]]
> Sent: Friday, January 12, 2001 1:39 PM
> To: Minder, Brian
> Subject: Re: [FW1] SecuRemote 4166/Win2K changes from udp to esp
> mid-session
> 
> 
> Do you see this consistently with Win2K's SecuRemote with *and*
> without a NAT device in between? I have seen problems with some
> supposed NAT devices (like the Cisco 675 DSL router) that may or
> may not do port translation...depending... In those cases, I've
> suggested using something like the Linux Router Project as a device
> that will do NAT and PAT (so that I don't have to mess with the
> forced UDP mode).
> 
> Steve
> 
> "Minder, Brian" wrote:
> 
> > I'm forcing udp encapsulation by virtue of being generally 
> skeptical of
> > autonegotiation.  By the same token, I would rather force a 
> port on a switch
> > into 100Mb-Full Duplex than hope the switch and the 
> server/NIC can come to a
> > common understanding.
> >
> > I'll pull out the forced mode and try it, but part of me 
> hope it doesn't fix
> > the issue.
> >
> > Thanks,
> >
> > -Brian
> >
> > > -----Original Message-----
> > > From: Byoung Sun Yu [mailto:[email protected]]
> > > Sent: Friday, January 12, 2001 10:47 AM
> > > To: 'Minder, Brian'; [email protected]
> > > Subject: RE: [FW1] SecuRemote 4166/Win2K changes from udp to esp
> > > mid-session
> > >
> > >
> > >
> > > I haven't seen this before, but let me suggest one thing.
> > > Why do you force udp encapsulation? You don't have to 
> force it. FW can
> > > automatically detect whether it is behind the NAT device or
> > > not. There are
> > > some exceptions that NAT devices which does not change port
> > > number even in
> > > Hide NAT. In such cases, you might want to 'force' it. But in
> > > general, you
> > > are not supposed to use forced mode for encapsulation.
> > >
> > > So I suggest to try without forced mode. But I'm just
> > > suggesting this to see
> > > if there is any difference and to find any work around to
> > > this problem.
> > >
> > > In my experiences, CP's product on W2K needs to be more
> > > polished regardless
> > > it is FW or SR. I wouldn't be suprised if you see this kind
> > > of weirdness.
> > >
> > > Thanks,
> > >
> > > Sun Yu, CISSP
> > > Lucent Worldwide Services
> > >
> > >
> > > > -----Original Message-----
> > > > From: [email protected]
> > > > 
> [mailto:[email protected]]On Behalf Of
> > > > Minder, Brian
> > > > Sent: Friday, January 12, 2001 8:39 AM
> > > > To: [email protected]
> > > > Subject: [FW1] SecuRemote 4166/Win2K changes from udp to esp
> > > > mid-session
> > > >
> > > >
> > > >
> > > >
> > > > I'm testing SecuRemote build 4166 on Win2K and I've noticed
> > > consistent
> > > > oddness.  While I have "force_udp_encapsulation (true)" on
> > > > the client, the
> > > > session seems to change back and forth from udp to esp over
> > > > time.  Clients
> > > > with routable addresses continue to function, but this breaks
> > > > clients who
> > > > are connecting from behind a NAT device.  Anyone have any
> > > > insight as to what
> > > > might cause this?  I am not experiencing this issue with other
> > > > builds/platforms.  Dumps of portions of the session are below.
> > > >
> > > > Thanks,
> > > >
> > > > -Brian
> > > >
> > > > Here's the problem environment:
> > > >
> > > > P440 running 4.1-SP2/IPSO-3.2.1
> > > > Hybrid IKE w/ TACACS
> > > > Win2K SP1 w/ SecuRemote 4166 with 
> "force_udp_encapsulation (true)"
> > > >
> > > >
> > > >
> > > > The symptoms are:
> > > >
> > > > The client connects, is challenged, and authenticates.
> > > Everything is
> > > > working great, sometimes for quite a while.  A tcpdump of the
> > > > connection
> > > > shows something like the following:
> > > >
> > > > 13:23:34.332713 roadwarrior.2746 > myfirewall.2746:  udp 196
> > > > 13:23:34.335601 myfirewall.2746 > roadwarrior.2746:  udp 588
> > > > 13:23:34.688933 roadwarrior.2746 > myfirewall.2746:  udp 148
> > > > 13:23:34.689969 myfirewall.2746 > roadwarrior.2746:  udp 172
> > > > 13:23:34.989065 roadwarrior.2746 > myfirewall.2746:  udp 172
> > > > 13:23:34.989882 myfirewall.2746 > roadwarrior.2746:  udp 108
> > > >
> > > > After some period of time there's some keying traffic, and
> > > > the session is
> > > > suddenly over esp!  At this point a client who is connecting
> > > > from behind a
> > > > NAT device gets the message "Connection with site SITENAME
> > > > has failed" and
> > > > has to reboot (not just restart SecuRemote) to reconnect.
> > > >
> > > > 13:32:51.297712 roadwarrior.isakmp > myfirewall.isakmp: 
>  isakmp v1.0
> > > > exchange QUICK_MODE encrypted
> > > >         cookie: 957753f17d529538->a7d1bae62e962ec0 msgid:
> > > > 42fd0406 len: 164
> > > > 13:32:51.300268 roadwarrior.isakmp > myfirewall.isakmp: 
>  isakmp v1.0
> > > > exchange QUICK_MODE encrypted
> > > >         cookie: 957753f17d529538->a7d1bae62e962ec0 msgid:
> > > > 5dc43f5f len: 60
> > > > 13:32:51.311456 myfirewall.isakmp > roadwarrior.isakmp: 
>  isakmp v1.0
> > > > exchange QUICK_MODE encrypted
> > > >         cookie: 957753f17d529538->a7d1bae62e962ec0 msgid:
> > > > 42fd0406 len: 60
> > > > 13:32:51.339565 roadwarrior.isakmp > myfirewall.isakmp: 
>  isakmp v1.0
> > > > exchange QUICK_MODE encrypted
> > > >         cookie: 957753f17d529538->a7d1bae62e962ec0 msgid:
> > > > 5dc43f5f len: 60
> > > > 13:32:51.428555 myfirewall.isakmp > roadwarrior.isakmp: 
>  isakmp v1.0
> > > > exchange QUICK_MODE encrypted
> > > >         cookie: 957753f17d529538->a7d1bae62e962ec0 msgid:
> > > > 42fd0406 len: 60
> > > > 13:32:51.538545 myfirewall.isakmp > roadwarrior.isakmp: 
>  isakmp v1.0
> > > > exchange QUICK_MODE encrypted
> > > >         cookie: 957753f17d529538->a7d1bae62e962ec0 msgid:
> > > > 42fd0406 len: 60
> > > > 13:33:08.798800 esp roadwarrior > myfirewall spi 0x9B73C1CA
> > > > seq 1 len 124
> > > > 13:33:08.799560 esp myfirewall > roadwarrior spi 0x90B9CDF6
> > > > seq 1 len 124
> > > > 13:33:09.134993 esp roadwarrior > myfirewall spi 0x9B73C1CA
> > > > seq 2 len 76
> > > > 13:33:15.235756 esp roadwarrior > myfirewall spi 0x9B73C1CA
> > > > seq 3 len 452
> > > > 13:33:15.249257 esp myfirewall > roadwarrior spi 0x90B9CDF6
> > > > seq 2 len 84
> > > > 13:33:41.612521 esp roadwarrior > myfirewall spi 0x9B73C1CA
> > > > seq 4 len 124
> > > > 13:33:41.613161 esp myfirewall > roadwarrior spi 0x90B9CDF6
> > > > seq 3 len 124
> > > > 13:33:41.979623 esp roadwarrior > myfirewall spi 0x9B73C1CA
> > > > seq 5 len 76
> > > >
> > > > Even better, sometimes after a rekey the client is using udp
> > > > encapsulation
> > > > while the FW is using esp, or vice versa:
> > > >
> > > > 13:51:12.284988 roadwarrior.isakmp > myfirewall.773:  isakmp
> > > > v1.0 exchange
> > > > QUICK_MODE encrypted
> > > >         cookie: 957753f17d529538->a7d1bae62e962ec0 msgid:
> > > > 14cd7e32 len: 60
> > > > 13:51:12.374089 myfirewall.773 > roadwarrior.isakmp:  isakmp
> > > > v1.0 exchange
> > > > QUICK_MODE encrypted
> > > >         cookie: 957753f17d529538->a7d1bae62e962ec0 msgid:
> > > > 7e5149e2 len: 60
> > > > 13:51:12.385145 roadwarrior.isakmp > myfirewall.773:  isakmp
> > > > v1.0 exchange
> > > > QUICK_MODE encrypted
> > > >         cookie: 957753f17d529538->a7d1bae62e962ec0 msgid:
> > > > 14cd7e32 len: 60
> > > > 13:51:12.484044 myfirewall.773 > roadwarrior.isakmp:  isakmp
> > > > v1.0 exchange
> > > > QUICK_MODE encrypted
> > > >         cookie: 957753f17d529538->a7d1bae62e962ec0 msgid:
> > > > 7e5149e2 len: 60
> > > > 13:51:19.253692 esp roadwarrior > myfirewall spi 0x9B73C1CD
> > > > seq 1 len 452
> > > > 13:51:19.265618 myfirewall.2746 > roadwarrior.2746:  udp 76
> > > > 13:51:44.409883 esp roadwarrior > myfirewall spi 0x9B73C1CD
> > > > seq 2 len 124
> > > > 13:51:44.410559 myfirewall.2746 > roadwarrior.2746:  udp 116
> > > > 13:51:44.810868 esp roadwarrior > myfirewall spi 0x9B73C1CD
> > > > seq 3 len 76
> > > > 13:52:17.206839 esp roadwarrior > myfirewall spi 0x9B73C1CD
> > > > seq 4 len 124
> > > > 13:52:17.207597 myfirewall.2746 > roadwarrior.2746:  udp 116
> > > > 13:52:17.545791 esp roadwarrior > myfirewall spi 0x9B73C1CD
> > > > seq 5 len 76
> > > >
> >
> > 
> ==============================================================
> ==================
> >      To unsubscribe from this mailing list, please see the 
> instructions at
> >                http://www.checkpoint.com/services/mailing.html
> > 
> ==============================================================
> ==================
> 
> --
> Steven Lee, CISSP> Senior Network Security EngineerFAX
> AVCOM Technologies, IncPager
> 4636 E Marginal Way S, Ste B-100   http://www.avcom.com
> Seattle, WA 98134-2383             mailto:[email protected]
> 
> 


================================================================================
     To unsubscribe from this mailing list, please see the instructions at
               http://www.checkpoint.com/services/mailing.html
================================================================================
Prev by Date: [FW1] RE:
Next by Date: [FW1] VPN Broke
Previous by thread: RE: [FW1] SecuRemote 4166/Win2K changes from udp to esp mid-sessi on
Next by thread: RE: [FW1] Secure Client (SecuRemote) and RSA SecurID
Index(es):
- Date
- Thread