B2B VPNs and NAT to Public IPs

[runcmd]

Being fairly new to B2B VPNs, I have limited experience--I setup one in the past that was pretty straight forward, which did not require a NAT. Now I must establish a B2B VPN (Star Topology) with a site whose internal network conflicts with a private IP range in use on my network.

Details: Both sides are running CheckPoint R55. The VPN will only include one or two computers in each of the two encryption domains. In order to make things simpler for myself, I would like the other site to purchase public IPs for the NAT. I'm thinking that by having them purchase a public IP to NAT behind, we will avoid any private IP conflicts in the future. (Is this a good proposal?) However, their technical person states that they can avoid purchasing additional public IPs, and avoid creating a NAT to another Private IP range, by using a NAT of the following configuration on their side...

RULE:
+----------+-------------+--------+---------+--------+
|  Source  | Destination |  VPN   | Service | Action |
+----------+-------------+--------+---------+--------+
| Lan      | EncDmn      | TheVPN | * Any   | accept |
+----------+-------------+--------+---------+--------+

ADDRESS TRANSLATION:
+--------------------------------+------------------------------------+
|        Original Packet         |         Translated Packet          |
+--------+-------------+---------+---------+-------------+------------+
| Source | Destination | Service | Source  | Destination | Service    |
+--------+-------------+---------+---------+-------------+------------+
| Lan    | EncDmn      | * Any   | Gateway | = Original  | = Original |
+--------+-------------+---------+---------+-------------+------------+

The way I understand the above...
Lan = Their Network Object
EncDmn = My Participating Nodes
Gateway = Appears to be a CheckPoint gateway?

They did not include information on how the "LAN" NAT is defined inside the object properties. Neither did they include any IP information on what they intend to use for the NAT. What I don't understand from this picture is the translated packet. Why is the source a gateway? Are they actually using the public IP address of their gateway for the NAT? Can you do that? Due to the lack of more thorough information, am I being snowed?

[northlandboy]

Yes, they can do that. They're planning on hiding their internal network behind their gateway's IP address. Since the gateway's IP address is a public one, it's not going to clash with your network.

This is perfectly valid, and will work as long as the connections are only from them to you.

Presumably at some point they will tell you what the IP is, as you'll need it to define the remote gateway. From your point of view, when you're configuring the VPN, the only object in what you define as their encryption domain will be their remote gateway.

[RobertGraham]

OHHHHH! Now I get it. Somehow when I first looked at this post, I didn't understand what they wanted to do. It must be the old skool ASCII diagrams that remind me of the old RFCs - they scare me. Nevermind....


There can be some problems with this though. As northlandboy stated, assuming they are initiating connections to your side and not the other way around, it's no big deal and everyone's happy. Just be aware for the future - it won't really scale.

Incidentally, this is poor practice on their side as Check Point's philosophy is that the firewall should be invisible (stealthful). Their firewall IP will show up in the logs of all the machines they connect to on your side. This may or may not be significant depending upon the beholder's security practice beliefs. Either way, it's not really your problem.

[runcmd]

Thanks so much for the feedback, and sorry about the ASCII work. I'm one of those guys that only read the "picture books" as a kid. Let me see if I understand correctly. Is this how you'd do it?... (Bogus IPs used intentionally)

ME:                                       COMPANY XYZ:
              +------{ Internet }------+
(MY_FW)       |<=( Encrypted Tunnel )=>|   (XYZ_VPN_Peer)
320.55.55.1   |                        |   330.22.22.1
+-------------+-+                    +-+-------------+
| My_Gateway    |                    | XYZ_Gateway   |
+-+-------------+                    +-+-------------+
  |                                    |
  + 10.1.1.0/24                        + 330.22.22.1/32
  | (MyNetwork)                        | (XYZ_NET)
  |                                    |
  +-+- (XYZEncDmnGrp)                  +-- 330.22.22.1
    +-- 10.1.1.1                           (NAT to 10.1.1.1)
    +-- 10.1.1.2

Both computers on my network are added to a "XYZEncDmnGrp" group, which needs to pass data to the 10.1.1.1 computer on the XYZ network, through the 330.22.22.1 NAT (which also happens to be their gateway). XYZ sets up the NAT on their side of the VPN tunnel to hide their 10.1.1.1 address behind 330.22.22.1. Back on my side, I name the Interoperable Device "XYZ_VPN_Peer" and assign it 330.22.22.1. I now create the network object "XYZ_NET" (representing their internal network), which is also defined as 330.22.22.1/255.255.255.255. Next, I define the VPN Domain for "XYZ_VPN_Peer" as the "XYZ_NET" network object, and make it a member of the "XYZ_VPN" community. For the sake of simplicity, let's say we're just going to allow FTP outbound through the tunnel with no inbound traffic...

+--------------+--------------+---------+---------+--------+
|  Source      | Destination  |   VPN   | Service | Action |
+--------------+--------------+---------+---------+--------+
| XYZEncDmnGrp | XYZ_NET      | XYZ_VPN | FTP     | accept |
+--------------+--------------+---------+---------+--------+ 
| XYZEncDmnGrp | XYZ_NET      | XYZ_VPN | * Any   | drop   |
| XYZ_NET      | XYZEncDmnGrp |         |         |        |
+--------------+--------------+---------+---------+--------+

Based upon the above configuration, the 10.1.1.1 and 10.1.1.2 computers on my internal network would then be able to FTP to the 10.1.1.1 computer on the XYZ side of the VPN tunnel by means of the 330.22.22.1 address. ...But, if XYZ ever decides they need to add another computer to their side of this VPN tunnel, they're out of luck.

Right? (If so, I think I might still be better off just forcing XYZ to buy one more public IP and let them NAT the 10.1.1.1 behind that.)

[RobertGraham]

You have a huge error:

Based upon the above configuration, the 10.1.1.1 and 10.1.1.2 computers on my internal network would then be able to FTP to the 10.1.1.1 computer on the XYZ side of the VPN tunnel by means of the 330.22.22.1 address. ...

You are forgetting to NAT your addresses going out. This is necessary, otherwise the receiver will see the packet as coming from itself. That is to say, when your host sends it out the packet will be:

Src:10.1.1.1 Dst: 330.22.22.1; while the receiver will see Src:10.1.1.1 Dst: 10.1.1.1.

This won't work because it can't send traffic back since it thinks the packets are coming from itself (or more strictly spoofed coming in the Ethernet interface instead of from the kernel).

You have to NAT your network too. Once you do that, it should work no problem.

[runcmd]

Wow! This does get interesting!...

ME:                                       COMPANY XYZ:
              +------{ Internet }------+
(MY_FW)       |<=( Encrypted Tunnel )=>|   (XYZ_VPN_Peer)
320.55.55.1   |                        |   330.22.22.1
+-------------+-+                    +-+-------------+
| My_Gateway    |                    | XYZ_Gateway   |
+-+-------------+                    +-+-------------+
  |                                    |
  + 10.1.1.0/24                        + 330.22.22.1/32
  | (MyNetwork)                        | (XYZ_NET)
  |                                    |
  +-+-- 10.1.1.1                       +-- 330.22.22.1
    |   (NAT 320.55.56.1)                  (NAT 10.1.1.1)
    +-- 10.1.1.2
    |   (NAT 320.55.56.2)
    |
    +--+-- (XYZEncDmnGrp)
       +- 320.55.56.1
       +- 320.55.56.2

I did not realized that, even though XYZ has their 10.1.1.1 address behind 330.22.22.1, I'd still need to hide my 10.1.1.1 address from them so that the traffic knows how to get back from XYZ. Also, because I have two computers on my side that need to FTP to 10.1.1.1 on the XYZ side, I could not play the same trick of using the gateway IP for my NAT. I would be forced to purchase two additional public IP addresses, or use a private range that's outside of what XYZ is using (which is not my preferred method).

In the above example, I used 320.55.56.1 and 320.55.56.1 for the NAT. When I communicate with 10.1.1.1 on the XYZ side, the IP I'd FTP to is the 330.22.22.1 address and XYZ would see the traffic as coming from either 320.55.56.1 or 320.55.56.2, depending upon which computer is in use. When the traffic returns, their firewall will send it back to the 320.55.56.x address and my firewall will translate it back to the 10.1.1.x address.

If I understand correctly, in order to accomplish this, I'd need to create two nodes for each participating computer on my side... One node of 10.1.1.1, with a NAT of 320.55.56.1, and a separate node for 320.55.56.1, which would participate in the "XYZEncDmnGrp" group to allow the communication through the VPN tunnel.

Thanks, again, for all the help! Did I miss anything that time?

[northlandboy]

This is why I don't like using private IP addresses in VPNs to third parties.
But anyway, it sounds like you've more or less got it.

If the connections are only outbound from you, then you could use a single hide nat for both IPs, rather than a separate public IP for each system on your side.

[runcmd]

I established my B2B VPN today, based on the information that was shared, and everything went off without a hitch... To all that provided insight into this matter: THANK YOU! It's a wonderful feeling to switch on a VPN and have it all work on the first try. YAY! :-)

[BarryStiefel]

Originally Posted by runcmd

I established my B2B VPN today, based on the information that was shared, and everything went off without a hitch... To all that provided insight into this matter: THANK YOU! It's a wonderful feeling to switch on a VPN and have it all work on the first try. YAY! :-)

That is a sweet feeling. I remember far too many multi-hour international phone calls checking and rechecking VPN settings to try to get a tunnel to come up.

[runcmd]

Wow! Second one in just a few weeks... I need to establish another B2B VPN and when I explained that we require a public IP address for the NAT, they also want to use the public IP of their gateway. Scary! ...But not as scary as their first idea of using a randomly selected public IP address (that they don't own) for the NAT inside the encrypted tunnel. :-)

[joelmoses]

Ooo. Randomly selecting a public IP address is bad mojo.

We keep a public netblock of our own reserved for B2B VPNs. If the business partner has a public IP address scheme of their own (that they OWN), we ask to use that... But, if they don't have one of their own, we assign a range from that block. Keeps everyone happy, although it burns a considerable amount of public IP space. Okay, maybe not EVERYONE... :>

[runcmd]

Originally Posted by joelmoses

If the business partner has a public IP address scheme of their own (that they OWN), we ask to use that... But, if they don't have one of their own, we assign a range from that block.

You guys are too nice. We intend to just make them buy their own IPs. However, it sure would be fun telling your B2B partner that you've changed your mind and are reclaiming your IP--especially after they've already used the NAT address in other B2Bs. Heh, heh, heh. :-)