Thanks for the responses so far
folks....
Well, it probably comes as no
surprise that I would have no control over the fact that I have to use a public
ip addr for my external fw-1 interface. So, I understand this is not
optimal, but what exactly are my choices?
1. Edit the topology in
order to diseminate the routable ip addr?
2. Use Manual IPSec?
(Not sure of the technical reasons this would work... but it was quoted as a
possible solution)
3. Anything else?
I know Check Point supports
SecuRemote connections through Check Point firewalls to internal
firewalls. Certainly, the majority of these configurations would have
internal networks nat'ed. Right? I am just having a hard time
believing that Check Point has troubles with SR connections to internal
firewalls.
Christian
This is right. Checkpoint FW-1 uses external interface address information in
encryption also. So unless you are planning to use Manual IPSec which is pain to
maintain, better allocate real IP address to FW-1 external interface. Using
private IP for FW-1 external interface is opposite to checkpoint's FW-1
brain and I won't go to that route at all. (assuming you have to think about
future upgrades etc..). I tried what you are trying to do with FW-1 4.0SP4. But
in my case I was NATing FW-1 external interface on Firewall itself. That worked
for Securemote , but when I tried to use site-to-site encryption it simply
refused, since it was using private IP address information in encryption, but
remote firewall gets packet from NATed real address and the whole concept just
failed.
If you are not planning to use Encryption, only in that case I suggest using
this, since in that case no external client would need to talk to FW directly,
you packets would simply routed and Firewalled at FW-1 box. But if planning to
use Encryption I suggest give up this idea, unless Checkpoint support this
officially?
Rajeev
Aaron Turner wrote:
Uh yeah. Don't do NAT at the router.
That's just going to cause you all
kinds of pain. The firewall
really really needs a routeable IP. Your
problem is that when the
client downloads the encryption domain/network
topology from the firewall,
it finds out the *actual IP* of the firewall
and tries to talk to that
rather than the routeable IP. Of course it
can't actually talk to
the RFC1918 address which generates the timeout and
no log entry.
You probably can edit the downloaded topology file that SecuRemote creates
(it's plain text) and edit it accordingly, but my guess is that it still
won't work or that if it does you'll find it breaking for your users on a
regular basis (like everytime they update the topology).
--
Aaron Turner
[email protected]
Security
Engineer
Vicinity Corp.
Cell:
http://www.vicinity.com
On Wed, 13 Sep 2000, Christian D. Anschuetz wrote:
>
> Hello:
>
> I have been unable to get SecuRemote
to work with our firewall (version 4.0,
> sp7 for NT).
Unfortunately, the problem is not one of the more common
>
configuration issues, but rather probably the result of the following
>
environment:
>
> SR Client --- Internet ---- Router --- (Nat'd
1918 addr) --- FW
>
> As you can see, the firewall's external
address is actually an RFC 1918
> address that is Nat'ed at the router
(with a dedicated, non-shared public IP
> address). No filtering
is taking place at the router at all (in fact,
> telnetting to the SR
ports succeeds no problem).
>
> Problem manifests itself
as: Key exchange occurs; attempts to access
> internal network
causes prompt; after time-out the message "No response from
> server -
check user name and password"; NO LOG INFORMATION WHATSOEVER.
>
> Any ideas? I am stumped.
>
> Many thanks in
advance.
>
> Christian
>
>
>
> This
is a repost - Never saw the message hit the list. If you've seen this
> before, my apologies and please disregard.
>
>
>
>
================================================================================
> 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
================================================================================
--
********************************************************************
Rajeev Kumar ([email protected])