R1’s Policy NAT configuration will match packets with a Source IP of 10.0.0.0/24 (Seattle’s actual network) and a Destination IP of 10.2.2.0/24 (Denver’s masked network), and translate the Source IP to the 10.1.1.0/24 network (Seattle’s masked network). Recall that a Policy NAT is a type of NAT that involves making a translation decision based upon matching both the source and destination address. The first solution involves using Policy NAT on both routers to mask their internal network when speaking to the opposite side. Many other devices can also perform NAT and the concepts described will still apply. This article uses Routers as the device’s performing NAT. There are two ways of deploying Network Address Translation to facilitate this solution, one involves a NAT configuration on both routers, the other a NAT configuration on one router. This will be attained by making the Seattle network appear as 10.1.1.0/24 when speaking to Denver, and making the Denver network appear as 10.2.2.0/24 when speaking to Seattle. That would cause them to send packets to the Router, which can then send them through the VPN tunnel. The solution to the problem is to convince each host that the other host is on a foreign network. As a result, because of the overlapping networks, neither side will be able to speak to the other. If the packets are not sent to the Router, then the Routers are unable to forward them through the VPN tunnel to the other side. Therefore, any packet Host D sends to the IP 10.0.0.77 will be sent to the local network, and not to the Router. Host D will have the same problem, Host D is configured with the IP 10.0.0.88/24 and also believes that the range 10.0.0.0 – 10.0.0.255 exists on its own local network in Denver. Therefore, if Host A attempts to send a packet to 10.0.0.88, it will not send the packet to the Router. Since Host A is configured with the IP 10.0.0.77/24, Host A believes that every IP address in the range of 10.0.0.0 – 10.0.0.255 exists on its own local network in Seattle. Host A in Seattle ( 10.0.0.77) needs to speak to Host D in Denver ( 10.0.0.88). Both Seattle and Denver are using 10.0.0.0/24 for their internal network. In the example below, there are two sites – Seattle and Denver – connected with a VPN tunnel between R1 and R2. The problem can be circumvented, however, with clever use of Network Address Translation. In such cases, hosts on one side of the VPN tunnel will be unable to communicate with the hosts on the other. When receiving the duplicate reply the TTL is not increasing or decreasing.When connecting two sites together using a Virtual Private Network (VPN), a common issue that is encountered is trying to build a VPN with overlapping networks - where both sites happen to use the same Private IP addresses. When pinging from a secondary IP on another subnet (10.0.2.200) using the ping -i eth1:0 there is no DUP reply. When you ping an IP from another subnet (say pinging 10.0.1.200 while the primary IP on the machine is 10.0.0.200) it goes over the default gateway of 10.0.0.1 and gets the DUP ping reply. The VLAN "test" has a "l3-interface" pointing to the proper VLAN interface. The VLAN interface has the first IP of each range assigned. The switches each have RVI's from different subnets. Some things to note that I think is related: The network layout is pretty simple - here is a (poorly) drawn diagram: Server2 receives the ping request from Server1, sends ping reply to Server1 A simplistic explanation of what's happening is this: I'm having a issue with receiving duplicate packets in my network and I'm unsure what's causing it.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |