CPUG

The Check Point User Group

A Resource For The Check Point Community.  Fast.  Useful.  Independent.

1. CCSA/CCSE One-Week Dual-Certification Training Course with CPUG in San Francisco!
    Courses Starting 12/8, (2009) 1/19, 2/9, 3/9, 4/6, 5/4, 6/8, 7/6, 8/3.
2. Join Us On LinkedIn - We now have a CPUG group.


Go Back   CPUG: The Check Point User Group > Check Point Firewall-1/VPN-1 And Related Products > VPN's (Virtual Private Networks)
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 2007-03-07
Junior Member
 
Join Date: 2006-06-28
Posts: 28
Rep Power: 0
thebuffman has an average reputation (10+)
Default Encrypting From Wrong Interface

I have been tiredlessly trying to figure out a solution to my firewall issue where it wants to encrypt tunnel traffic from the internal interface instead of from the external interface. The fix I've found after Nokia and consultants could not figure one out was from an article from CheckPoints SK. It is article sk31211. It involves using dbeditor to modify information that cannot normally be modified via smartdashboard. I will post it in the footer for all those without access. I also found a post by Phoneboy to someone who had a similar issue:

http://oldfaq.phoneboy.com/gurus/200110/msg00470.html

I would only recommend this solution if you have one interface used for tunnelling. Because I have multiple interfaces for tunnelling I need a different solution. Good luck!

===========================================

Solution

When establishing a site-to-site VPN where both sites have cluster High Availability (HA) and multiple external interfaces, special modifications are required. It is important to enable the parameter IPSec_main_if_nat (true) in the $FWDIR/conf/objects_5_0.C file. This parameter forces a response from the IP defined on the general tab of the relevant Security Gateway.


Interface resolving aids in determining the appropriate IP of a VPN peer. Likewise, source-address determination ensures the IP used by a Gateway makes sense according to the specific VPN peer
which which you are communicating. This ability is necessary when VPNs are terminated to multiple interfaces of a Gateway, for the following reasons:

1. If a peer begins an IKE exchange using one IP for the destination module and the response is sourced from a different IP, this can cause the peer to reject the response. Another outcome is the IKE initiator will finish the exchange, but with the new IP of the peer. This may seem harmless, but can have serious consequences. For example, assuming the second IP injected into the exchange cannot be routed to the module, communication will fail.

2. If the IP in the response packets differs from what the Initiator is using for the module, this may be blocked by security devices between the communicating peers. This is due to the fact that the Gateway will route return packets via the appropriate exit interface, according to the direction of the remote peer. In other words, the IP used as the source differs from the IP of the exit interface. If there are devices performing anti-spoofing capabilities between the peers, they will likely drop such packets.

Default cluster parameter definition
IPSec_cluster_nat - forces a response from a defined cluster IP (true), only present for cluster objects

IPSec_orig_if_nat - forces a response from the IP/cluster IP that was initiated to (true), present for cluster and gateway objects

IPSec_main_if_nat - forces response from the IP on the general tab of the relevant gateway object (false), present for cluster and gateway objects

Individual usage
IPSec_cluster_nat - cluster responding from one of the cluster IPs defined on the cluster object; the cluster IP used will be the one associated with the exit interface. The response IP is not necessarily that which is represented on the general tab IP, but will be a cluster IP.

IPSec_orig_if_nat - used to ensure outbound IKE and RDP packets have a source IP address the same as the destination IP address of the previous inbound message, from the same peer

IPSec_main_if_nat - Gateway always responding from the IP address defined on the general tab of the gateway object; this is true, even if the gateway object is a member of a cluster and present in a cluster object.

Combined parameter usage
IPSec_cluster_nat & IPSec_orig_if_nat - When both of these parameters are enabled (which is the default for cluster objects), the behavior closely resembles having IPSec_cluster_nat activated only. The difference is if the exit interface uses a different cluster IP than that to which it was was initiated, response packets will continue to use the cluster IP as initally communicated by the peer.

IPSec_cluster_nat & IPSec_main_if_nat - The Gateway will respond to clients according to the IP listed on the General tab of the corresponding object. In the case of a cluster, the
IP on the general tab of the cluster object is used.

IPSec_main_if_nat & IPSec_orig_if_nat - This combination results in orig_if_nat overriding the main_if_nat property. This is the same as if only the IPSec_orig_if_nat property were enabled.

With all relevant properties disabled, the Gateway will respond from the physical IP of the exit interface, regardless of whether or not the Gateway is a member of a cluster.

Note:
All parameters are held per Network object, and are editable via GuiDBedit.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


All times are GMT -7. The time now is 23:55.


Powered by vBulletin® Version 3.7.4
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.2.0