Re: [FW-1] Problem using SecuRemote Over NAT'ed connection

[Don <don@FW1-NOSPAMBLACKSUN.ORG>]

> When I look at the log viewer I see the SecuRemote connection coming into
> the FW and the source address is the external legal address (217.36.88.125)
> of the switch doing the NAT sitting infont of my secuRemote client. However
> once the user has been authenticated and the keys have been installed the
> source address changes to the INTERNAL illegal address (192.168.101.1) of
> the SecuRemote client. The data therefore comes into our internal network
> and to the destination server (172.16.0.5) but the response back to the
> SecuRemote client from my internal network is not routable as the reply
> address is invalid (192.168.101.1). Does this mean the UDP encapsulation is
> not working?
No this is exactly what is supposed to happen. When the firewall gets the
traffic back, it will re-encapsulate the traffic ad send it off to the
SR client.

> SecuRemote     ---->  Router(Int)       /  Router(Ext)         ---->
> FW-1(Ext)       / FW-1(Int)    ----> Server
> 192.168.101.1   ---->  192.168.101.2  /  217.36.88.125     ---->
> 192.168.50.4   / 172.16.0.1  ----> 172.16.0.5

> So far I have....
> 1.) created an Internal Certificate Authority
> Firewall# cd $FWDIR/bin
> Firewall# fwstop
> Firewall# fw internalca create -dn "o=organization, c=us"
> Firewall# fw internalca certify -o Firewall "o=organization, c=us"
> Firewall# fwstart
This is used for hybrid mode authentication and has nothing to do with
NAT'd users.

You do not mention what versions of Firewall-1 you are using however
versions after SP2 came with support for UDP encapsulation enabled by
default (Not necessarily true if you upgraded).

The most common causes for SR failures are:

Routing problem. Your SR clients are using an address that already exists
in your network somewhere. i.e. your network has a 192.168.1.x address
scheme and the client is connecting from 192.168.1.x.

Routing problems as a result of multiple network exit points. Traffic from
returnign tot he SR client leaves the network through a different path
than the one it enetered from.

Encryption domain problems. Your SR client has an address in the
Encryption Domain and it never bothers to encrypt the traffic in the first
place.

Misconfiguration of UDP encapsulation. You have to make sure that the
objects that you defined as per the instructions on Secure Client and NAT
exactly.

MTU problems. The MTU is too large as a result of the added encapsulation
for IPSEC, PPOE, or digital certificates and the don't fragment IP option
is selected.

IP NAT Pools were defined but defined wrong or incompletely.

-don

=================================================
To set vacation, Out Of Office, or away messages,
send an email to LISTSERV@lists.us.checkpoint.com
in the BODY of the email add:
set fw-1-mailinglist nomail
=================================================
To unsubscribe from this mailing list,
please see the instructions at
http://www.checkpoint.com/services/mailing.html
=================================================
If you have any questions on how to change your
subscription options, email
fw-1-owner@ts.checkpoint.com
=================================================