Re: Remote access between firewalls

[R Bruce Hoffman <bruce.hoffman@xxxxxxxxxxxxxxxxx>]

well, clearly, I am not understanding something about this configuration 
here...

user --- FW --- internet --- PIX --- server(https://)

this config, for the user, is just go to https:// and at the PIX, there 
is only a static map from outside to inside address. No 7.1 requirement. 
All security (other than port restriction) is handled by the certs and 
software on the server.

user --- FW --- internet --- PIX --- local network
 /\
with Cisco VPN client

this config, establishes a VPN from the inside addresses at the user's 
end through both firewalls and exposes the inside addresses of the local 
network to the user's platform, using SSL encryption on the VPN tunnel. 
The user, for all intents and purposes, essentially has access to your 
local network addresses as if they were there.



Burns, Bryan wrote:
> SSL to a web server requires 7.1,  SSL VPN doesn't.  This is my understanding.
>
>
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of R Bruce Hoffman
> Sent: Wednesday, April 25, 2007 3:16 PM
> To: Midrange Systems Technical Discussion
> Subject: Re: Remote access between firewalls
>
>
>    SSL through the PIX to the web page would just be a static mapping, plain
>    old NAT/PAT... the benefit there would be that no client is required and
>    anyone with a password can use it, unless you are also deploying client
>    certificates. You're just passing security on to the web server.
>    That, by itself, and the client through the PIX, don't require 7.1 so I'm
>    curious... what's driving the 7.1 upgrade? (Not that it's a bad thing...)
>
>    Burns, Bryan wrote:
>
>  I'm also looking at doing an SSL connection through the PIX to a webpage that 
> a user signs on to.  From there, they'll just use an emulator like Mochasoft.  
> That's what our consultant recommended.  We'll have to upgrade the PIX to 7.1 
> though.
>  Any thoughts on this one?
>  Thanks,
>  Bryan
>
>  
>
>