NETWORK PRESENCE ABOUT SERVICES PRODUCTS TRAINING CONTACT US SEARCH SUPPORT
 


Search
display results
words begin  exact words  any words part 

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [FW-1] VPN and NAT will not work at the same time with NG FP1



Well Kevin, I thought it was just me. I have been working on this exact same problem the entire weekend. I have a Cisco 3640 (IOS 12.2) with a VPN to CP NG FP1. I too was able to talk bi-directional to the FW and Cisco, from the devices in the encryption domain to the Cisco worked. But from Cisco to a NAT'ed device in the encryption domain, it did not work. The error I received was an "invalid payload type". Not sure what that means but I think it has something to do with ESP.
 
I turned on debugging on the firewall and this is part of what I seen:
[ 1393]@gateway -- updatePayloadMap: received payload PA_ID.
[ 1393]@gateway -- updatePayloadMap: received payload PA_HASH.
[ 1393]@gateway -- updatePayloadMap: received payload PA_UNKNOWN.
[ 1393]@gateway updatePayloadMap: unexpected payload PA_UNKNOWN.
[ 1393]@gateway identifyPayloads: failed for phase 1 stage 5.
[ 1393]@gateway MMProcess5: identifyPayloads failed.
It seems that the Cisco device is sending an extra payload that NG does not know what to do with, or the NG ESP engine/module is not quite up to date.
 
May need to contact CP Support on this one.
 
Any input would be appreciated.
-J
-----Original Message-----
From: Palmer, Kevin [mailto:[email protected]]
Sent: Monday, February 18, 2002 7:42 AM
To: [email protected]
Subject: [FW-1] VPN and NAT will not work at the same time with NG FP1

FW-1 Mailing List,
 
I have run into a configuration problem connecting Check Point VPN-1 NG FP1 to other vendor's IPSec VPN gateways when NAT is configured on objects in CP's encryption domain. The following example should help. Some of the details have been omitted to create a more concise example.
 
VPN Host
(FreeS/WAN, LinkSYS BEFVP41, VPN-1*)
12.10.10.10/24
    |
    |
Internet
    |
    |
VPN-1 Gateway
12.11.11.98/27
    |
    |
Encryption Domain behind firewall
172.16.192.1/18
            |
    |
W2K Server
172.16.192.10/18
12.11.11.110/27 Static NAT
    |
    |
W2K Client
172.16.192.11/18
12.11.11.111/27 Hide NAT
 
* VPN-1 allows you to include the external subnet 12.11.11.0/27 in the encryption domain. Some vendor's IPSec VPN host and gateway products do not allow you to configure 12.11.11.0/27 as an encryption domain.
 
Testing
 
Ping From        Ping To          NAT      Result
12.10.10.10      172.16.192.10    YES      OK
12.10.10.10      172.16.192.11    YES      OK
12.10.10.10      172.16.192.10    NO       OK
12.10.10.10      172.16.192.11    NO       OK
172.16.192.10    12.10.10.10      YES      FAIL
172.16.192.11    12.10.10.10      YES      FAIL
172.16.192.10    12.10.10.10      NO       OK
172.16.192.11    12.10.10.10      NO       OK
 
During testing I discovered that the VPN works in both directions when automatic NAT on the network and/or workstation object(s) is disabled. The problem seems to be that the VPN Host sees the incoming encrypted packet from 12.11.11.110 or 12.11.11.111 instead of from 172.16.192.10, 172.16.192.11, or even 12.11.11.98. When NAT is disabled, the VPN works. What I want to know is "How do I disable NAT for connections with a destination of 12.10.10.10?"
 
Before you answer, I have setup the following NAT rules before the automatically created NAT rules. The extra NAT rules do not appear to be doing anything.
 
    Original Packet                        Translated Packet
No. Source            Destination          Source            Destination
1   172.16.192.10/18  12.10.10.10          Original          Original
2   12.10.10.10       172.16.192.10/18     Original          Original
3   Start of Automatic NAT rules ...
 
NG Specific Configuration Info
The following global property settings are selected/enabled.
"Automatic rules intersection"
"Perform destination translation on the client side"
"Automatic ARP Configuration"
NG Objects.C modification
properties nat_dst_client_side_manual true
 
The configuration illustrated above should be fairly popular. That means there is already someone out there with an answer or a number of there network engineers trying to figure this out as well.
 
Thank You for your interest and help with this issue.
 

Kevin Palmer
Network Engineer - MCSE+I, CCSE, CCNA



 
----------------------------------

ABOUT SERVICES PRODUCTS TRAINING CONTACT US SEARCH SUPPORT SITE MAP LEGAL
   All contents © 2004 Network Presence, LLC. All rights reserved.