See Comments inline...
Ken Claussen MCSE CCNA CCA
"In Theory it should work as you describe, but the difference between theory
and reality is the truth! For this we all strive"
-----Original Message-----
From: Ben Nagy [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 10, 2001 8:08 PM
To: Claussen, Ken; 'erratic whimsicality'; '[EMAIL PROTECTED]'
Subject: RE: IPSEC tunnel between Nokia and Cisco
> -----Original Message-----
> From: Claussen, Ken [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 11, 2001 3:05 AM
> To: 'erratic whimsicality'; '[EMAIL PROTECTED]'
> Subject: RE: IPSEC tunnel between Nokia and Cisco
>
>
> Giorgo,
> Your solution is much easier to maintain. I would put the
> single VPN router behind the firewall and allow UDP port
> 500(ISAKMP) and protocols 50 (ESP) and 51 (AH) to tunnel from
> your IP to the remote VPN router.
I have an architecture bias against running IPSec through firewalls. I
prefer to terminate VPN traffic at, before or in parallel to firewalls, in
general. Just a gut-feel thing, though.
KC> I tend to agree here, from a security perspective it is best not to put
this router on you internal network. I was thinking more of ptting in a
(dedicated if possible) DMZ environment where even after it exits the crypto
tunnel it requires access validation by the firewall to reach the intended
machines, or any machines for that matter.
Oh, and being _really_ pedantic, I prefer to use IPSec in tunnel mode with
ESP only and not worry about AH. One less protocol to open, and it's no loss
from a crypto point of view.
KC.Again I agree AH is really not worth it unless it is strictly a LAN
situation because of the lack of payload encryption.
> I have worked with IPsec
> tunnels between different vendor platforms and it can be a
> bit (or alot) tricky. It is much easier to maintain if both
> ends are Cisco routers.
I haven't really found this - just my opinion, of course. All the interop
I've done has been easyish. In fact, as long as _one_ side is a Cisco it's
even easier because of the high quality of the debug messages.
KC> True enough about the debug messages. Cisco routers with
debug crypto isakmp
debug crypto ipsec
debug crypto engine
debug ip packet detail (crypto map match access list)
spew forth an extroidinary amount of detail about the proceedings.
I was thinking of interoperability between Cisco and Raptor. I have seen
issues with key exchange and time-outs.
Especially after issueing the clear crypto sa and clear crypto isakmp
commands. The Raptor will not honor the SA delete notification request (so
it seems, lack of Raptor debugs makes it hard to verify) and then when the
Cisco attempts to rekey the SA the Raptor doen't acknowlege the request. I
have seen it take 25-45 minutes to reestablish the SA, and usually not until
the Raptor sends the SA request. On the other hand, Cisco to Checkpoint I
have had pretty good experieinces with.
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
http://lists.gnac.net/mailman/listinfo/firewalls
