First and obvious question here: can't you ask for the network behind the Edge to be something outside of the 192.168.0.0/16 range?? That would be the resolution to all your problems, but since you are working hard to get this resolved as it is, I guess that may not be an option... I just had to ask, you know....
First I would say you need to be very specific on those manual NAT rules and specify that whenever traffic from 192.168.2.0/24 goes to 172.16.1.0/24, the destination should be translated to 192.168.1.0/24 and then another rule that says whenever 192.168.1.0/24 goes to 192.168.2.0/24, the source should be translated to 172.16.1.0/24 and finally be sure BOTH rules are installed only on the Edge box and none on the HQ firewall, that way you are being very granular on the traffic to be NATed and ensure on the HQ side they will only know about the 172 range, when it concerns to the customer side. Something that smells fishy to me is the VPN domain of the Edge being only the 172 range, I know the idea is to ensure that traffic originated on the HQ side and directed to that range is encrypted but I think that particular detail is related with the fact that you cannot initiate a connection from the customer side unless one has been done from the HQ first. If the traffic between the 192.168.1.0/24 and 192.168.2.0/24 ranges on the HQ networks doesn't have to hit the HQ firewall at any point, I believe you can freely add 192.168.1.0/24, to the VPN Domain of the Edge and in that way ensure traffic originated from that range and directed to the HQ side will be considered for encryption by the Edge box. The deal here is that I'm not completely sure if the firewall will first figure out if the traffic that arrives to it should be encrypted and then applies the NAT rules, or if it is the other way around and the NAT goes first. If in fact internal traffic between those two ranges reaches the HQ firewall at some point, then things get more complicated and I'm still thinking of a way around it. If I find a way to do so, I'll let you know. This is a scenario I think I could be facing soon at a customer's site, so it is a good exercise for me to work on it before hand and help you a bit in the mean time. Please post here any new developments and I will continue trying to help you in any way I can. Regards On 11/9/06, Harald Astrand <[EMAIL PROTECTED]> wrote:
Hi, I am trying to set up a site-to-site VPN between our gateway cluster and a customer VPN-1 Edge device that we will manage. The gateway cluster is running R55 HFA_17 and the VPN-1 Edge is running 6.0.76. The customer is using a private subnet (192.168.1.0/24) behind the VPN-1 edge, but at the HQ we are using 192.168.0.0/16. I would therefore like the VPN-1 Edge to translate 192.168.1.0/24 into 172.16.1.0/24 before sending it over the VPN connection. The customer only needs to access 192.168.2.0/24 in the HQ network. I have now reach a point where some things are working: 1. I can successfully connect from a client in the HQ (192.168.2.1) to a machine in the customer network (192.168.1.1) if I use 172.16.1.1 as the destination address. 2. If I have done the connection in step 1, the user of 192.168.1.1 in the customer network can successfully access 192.168.2.1 in the HQ. However, if a user in the customer network (192.168.1.1) tries to access 192.168.2.1 without any preceeding packet from the HQ he is not able to reach the machine. In the logs of both the VPN-1 Edge and the R55 I can see that the packets are accepted and if I use tcpdump on the HQ firewall I can see the return packet from 192.168.2.1 but they never reach 192.168.1.1. The VPN encryption domain is currently 192.168.2.0/24 for the HQ firewall and 172.16.1.0/24 for the VPN-1 Edge. Is 192.168.1.0/24 also required in the VPN domain for the VPN-1 Edge and in that case how would I prevent the HQ firewall to route packets to a 192.168.1.0/24 address over the VPN tunnel (as I said earlier we want to use all addresses in 192.168.0.0/16 inside the HQ and we only want to route packets to 172.16.1.0/24 over the tunnel)? The network address translations on the VPN-1 Edge looks like: Source Destination Source Destination Any 172.16.1.0/24 Original 192.168.1.0/24 192.168.1.0/24 any 172.16.1.0/24 Original A static route for 172.16.1.0/24 has been configured on the VPN-1 Edge to point to the local LAN of the customer to fix anti-spoofing errors messages that occured before. The VPN-1 Edge is currently managed from our Smart Centre and is not configured to be an externally managed gateway. Any help would be very much appreciated! Regards, Harald ================================================= 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] =================================================
-- Sergio Alvarez (506)8301342 ================================================= 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] =================================================
