I am a little confused by the original post, so I'll try to describe what you *should* be doing rather than trying to fix your original statement per-se.
Let's start with some myths and try to clear the air a little. There is no relationship between VPNs, NAT'ing and ARP'ing. It is quite possible that you need to use more than one of these functions to solve a problem, but in particular please note that there is absolutely NO connection between NAT and ARP.
How can I say such a controversial thing ? Because it's true, and I'll explain how in a moment. Before you read any further, you may wish to throw away all you learned on the Check Point CCSA/CCSE courses about NAT'ing and ARP'ing - all the examples are contrived and seldom explained by the instructor.
Now.. open your mind, connect to the force... and watch. (If you already understand this stuff, then I apologise !)
ARP: This is a routing trick that we use to get one IP device to send a packet to another device (on the same piece of wire) that DOESN'T actually have the address physically bound to it's (ethernet) interface. The correct term is actually PROXY ARPing, there is also STATIC ARPing which is NOT what we generally use for this kind of work. If you have control of the local routing, there is no NEED to ARP, although you may still elect to use ARPs since it can be less invasive to the infrastructure.
NAT: This is a routing trick that allows us to physically change the IP headers (source address or destination address) of a packet as it passes through our routing point (in this case the Check Point firewall). The only requirement for NAT is that the packet reaches one of our interfaces so that we can process it.
Now, can you see the link ? The link is that they are both routing tricks, and this is what leads people to think that they are inextricably linked. The reality is that you can use either without the other, depending on the requirement. If your routing brings the packet to your firewall, you can NAT it as it passes through, regardless of whether or not you have published a proxy ARP for it.
OK.. now let's consider the scenario with this new revelation in mind.
I have 2 firewalls, with the same internal subnets (a common enough thing with the prevalence of RFC 1918 addressing on internal LANs). How can we then set up a VPN between these 2 identical sites ?
This is the walkthrough.. so rn4it, work with me here step by step and all should be cool ! I'll refer to the firewalls as livesite and DR for my own reference.
I'll assume that you want connections to be able to start on either side of the VPN (rather than just in one direction). I'll also simplistically assume that each site has just a single server that needs to be connected to by the other. You'll need to engage brain in the NAT department, but if you really want me to do the whole job for you you'll need to pay me
The other nasty here, is that this is much easier to do when both firewalls have their own management server. This is because you are screwing with the encryption domains, and although it's not impossible, it's easier to see when you are handling just one side in each rulebase. Also, it won't be much of a DR solution when you lose the only management server on the death of the LiveSite
The common example subnet will be 192.168.1.0/24. The server is on 192.168.1.80 on each side.
1. Select an address subnet for the virtual addresses to be used for servers on the DR site when connecting from the LiveSite side. (example 192.168.200.0/24)
2. Select a different address subnet for the virtual addresses to be used for servers on the LiveSite when connecting from the DR side. (example 192.168.201.0/24)
3. On the Livesite rulebase, create an encryption domain for the LiveSite network containing both the 192.168.1.0/24 network and the 192.168.201.0/24. Create an encryption domain for the DR site for the 192.168.200.0/24 network only.
4. On the DR site rulebase, create an encryption domain for the DR Site network containing both the 192.168.1.0/24 network and the 192.168.200.0/24. Create an encryption domain for the LiveSite for the 192.168.201.0/24 network only.
5. In each security rulebase, create a pair of VPN rules as follows:
ENCDOM-LiveSite -> ENCDOM-DR == ANY == ENCRYPT
ENCDOM-DR -> ENCDOM-LiveSite == ANY == ENCRYPT
*** Now the NAT stuff that will make it all work ***
6. On the LiveSite NAT rulebase, you need 2 rules.
The first rule hides all outbound connections from LiveSite behind a virtual address in the VPN.
ENCDOM-LiveSite -> ENCDOM-DR == ANY || (H)192.168.201.254 -> =Orig == =Orig
The second rule translates incoming connections from DR site to real local destinations.
192.168.200.254 -> 192.168.201.80 == ANY || =Orig -> (S)192.168.1.80 == =Orig
7. On the DR Site NAT rulebase, you need 2 rules.
The first rule hides all outbound connections from DR Site behind a virtual address in the VPN.
ENCDOM-DR -> ENCDOM-LiveSite == ANY || (H)192.168.200.254 -> =Orig == =Orig
The second rule translates incoming connections from LiveSite to real local destinations.
192.168.201.254 -> 192.168.200.80 == ANY || =Orig -> (S)192.168.1.80 == =Orig
*** These rules will need to be ABOVE any outbound hide rules for standard Internet connectivity. ***
NOTES:
=====
This example uses the Traditional Mode for defining the VPN. Using VPN Communities may be convenient in some respects, but ultimately it hides a lot of control and makes certain more advanced configurations more difficult than they need to be.
There is NO ARP for the addresses used to create the virtual bridge.
The NAT rules are created manually to provide control over the NAT rulebase. Automatic NAT rules would not be able to create the same narrowly focussed intent.
The VPN Security rules in this example are deliberately wide, effectively bridging the LANs together. This is NOT RECOMMENDED for a production environment, and I would normally create specific source and destination IP addresses and services, even for VPN rules.
========================================
Find out about what I do for a living at
========================================
![[cheers]](/data/assets/smilies/cheers.gif "[cheers] [cheers]")
