Well, couldn't you ( and this is going to take some work on your part
depending on how many users we are talking about here ) setup individual
workstation ( or, since users ip addresses may change, network ) objects for
all of the users, group them, and then change the rule from internal ->
allowed-external any in rule 2? This would cut down on the other extraneous
traffic somewhat. What happened when your rule internal -> nat-range any
was set? What were you seeing?
Kevin Martin
[EMAIL PROTECTED]
-----Original Message-----
From: Jerald Josephs [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 20, 2000 2:08 AM
To: [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [FW1] Outbound secure client connections
Unfortunately, FireWall-1 is not going to encrypt and encapsulate any
network
connections that originate from the Intranet and are addressed to the
SecuRemote
Client.
For one, FireWall-1 does not have a method where it can enumerate all of the
authenticated users which have a current connection and then dynamically
associate
an action that would enable it to encrypt outbound packets to the IP address
of
the SecuRemote client. It can only encrypt and encapsulate packets that
match an
existing entry in the state tables.
Secondly, SecuRemote or SecureClient would not accept any encrypted
encapsulated
packets originating from the encryption domain with the SYN bit set.
Finally, even if you use a third-party VPN solution, such as SSH, you would
have to find
some way to initiate a network connection back to your client and fold it
within the established
VPN. I know how to fold a network connection that I initiate from my SSH
client through the
already established SSH tunnel, but not the other way back. I would not
doubt, however,
that this can be done.
--- Jerald Josephs
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 19, 2000 6:47 PM
Subject: [FW1] Outbound secure client connections
>
> To all,
>
> Ok, I have gone through all of the instructions on Phoneboy's page and
read
> all of the messages in the group relating to getting internal services out
> to a secure remote client. Now, the idea is to let remote users access (
> once authenticated ) to access anything inside, but also to access
anything
> on that remote user's PC. This can be as simple as tftp'ing a file back
to
> him or sending an x session back out. I now having two rules :
>
> Source Destination Service Action
>
> 1) allusers@any internal_nets any client_encrypt
> 2) internal_nets any any accept
>
> From what I can see, any traffic to an already authenticated Secure Remote
> user, goes down the tunnels just fine, as it should. But, any other
> traffic which originates internally, also exits the firewall. Now this can
> be stopped at the router, which only allows IPSec traffic, but this should
> not have to be the case. So, the question is, how can I stop all outbound
> traffic from exiting the firewall, unless it is specifically destined to
an
> already established tunnel.
>
> Since the SR connections are NATed to an internal range of addresses, I
> tried to create a rule which only allowed internal networks to connect to
> that range of addresses :
>
> internal_nets nat_range any accept
>
> This was done with the rule processing set to inbound, but did not work
> properly.
>
> Thanks,
> John
>
>
>
>
>
>
>
============================================================================
====
> To unsubscribe from this mailing list, please see the instructions at
> http://www.checkpoint.com/services/mailing.html
>
============================================================================
====
============================================================================
====
To unsubscribe from this mailing list, please see the instructions at
http://www.checkpoint.com/services/mailing.html
============================================================================
====
================================================================================
To unsubscribe from this mailing list, please see the instructions at
http://www.checkpoint.com/services/mailing.html
================================================================================
