[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [FW-1] Problem using SecuRemote Over NAT'ed connection
Dean, Dunno if you have the same setup as we do ... so maybe the following is not what you are looking for, but just in case ... We are using Cisco routers inbetween, and they are keen on not using too many port translations unless really necessary. The first IP address with port 500 coming through is not translated automagically to a higher port number. Because of this, the FW-1 does not realize NAT is involved and consequently is not switching to udp encapsulation mode. We had to force translation for the first IP address using ip nat inside source static udp 192.168.6.198 500 interface Dialer1 666 on the Cisco router, after which things run smoothly. Greetings, -----Original Message----- From: Gorton Dean [mailto:[email protected]] Sent: maandag 11 februari 2002 13:54 To: [email protected] Subject: [FW-1] Problem using SecuRemote Over NAT'ed connection I have an increasing number of users that need to connect back to my company using SecuRemote over NAT'ed connections like business versions of ADSL that does hide node address translation. I've read several papers on how to do this such as Checkpoints "Hybrid Mode IKE for SecuRemote Authentication" (http://support.checkpoint.com/kb/docs/public/securemote/4_1/pdf/hybrid-2-10 .pdf) and the paper written by Eric White on phoneboy (http://www.phoneboy.com/docs/secureclient-nat.pdf) but to no avail. The problem is as follows. My clients can connect using IKE and browse my internal LAN over a normal dialup or ADSL connection that allocates them a legal IP address. Over any sort of NAT'ed connection they can perform a topology request and authenticate using their SecureID account but that's where the success turns to failure and I can get no response from my internal network over the client VPN. 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? 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 2.) Setup my user to use IKE 3.) Added the following to the Object.C file.... :isakmp.udpencapsulation ( :resource ( :type (refobj) :refname ("#_udp_encapsulation") ) :active (true) ) ...And... :userc_IKE_NAT (true) :userc_NAT (true) 4.)and added ...":force_udp_encapsulation (true) " to the $FWDIR\database\userc.C file on the client. If anyone can see what I've missed or shed any light on this your comments will be gratefully received. Dean Gorton Senior Network Analyst * [email protected] * Macmillan Limited, DISCLAIMER: This e-mail is confidential and should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Neither Macmillan Publishers Limited nor any of its agents accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Macmillan Publishers Limited or one of its agents. Please note that neither Macmillan Publishers Limited nor any of its agents accept any responsibility for viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the email and attachments (if any). No contracts may be concluded on behalf of Macmillan Publishers Limited or its agents by means of e-mail communication. Macmillan Publishers Limited Registered in England and Wales with registered number 785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS ================================================= To set vacation, Out Of Office, or away messages, send an email to [email protected] 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 [email protected] ================================================= ================================================= To set vacation, Out Of Office, or away messages, send an email to [email protected] 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 [email protected] =================================================
|