Hi rene, i don’t understand this ip route 3.3.3.3 255.255.255.255 192.168.23.3 but your next hope is r2…did you use recursive static route in this scenario ?
Hello Anas
Yes, you are correct, Rene has configured a recursive static route. When a packet with a destination address of 3.3.3.3 is to be sent, this routing table entry is matched. However, the next-hop IP of this entry (192.168.23.3) must then be reachable as well, so a recursive lookup of that address takes place. The appropriate route is matched, with a next-hop IP of 192.168.12.2 which is R2, and the packet is sent.
For more information on recursive routing, take a look at this NetworkLessons Note on recursive routing.
I hope this has been helpful!
Laz
thank you for the lesson; one question what is the difference between VPN and secure tunneling you just introduced?
Hello Berthol
A VPN is a general term used to refer to a mechanism that establishes a secure connection between two remote sites over an insecure network like the Internet. More about VPNs, in general, can be found at this NetworkLessons note on VPNs.
This particular configuration in the lesson is a type of VPN. A VPN in essence is a tunnel, but this lesson shows how to implement a VPN using specific protocols and mechanisms including an IPSec tunnel.
It really simply has to do with terminology and the context in which it is used.
I hope this has been helpful!
Laz
Hello, I have a question. Therefore, when building site to site IPsec, both private and public networks are entered into the same routing protocol. Then it can be private networks be exposed to the outside world?
Hello Yuchan
When building a site to site VPN using IPSec Tunnel, the private IP addresses used internally in the remote networks are kept separate from the public IP addresses used over the intervening Internet. This is part of the functionality of a VPN.
In this particular lesson, Rene chose to use addresses in the private range to represent the interconnection between R1 and R3. The following diagram reimagines the topology using address ranges that resemble a situation where you are routing the IPSec tunnel over the Internet:
The green addresses are private while the purple are public. The IPSec Tunnel will tunnel only private addresses.
Now indeed, both R1 and R3 will have both public and private addresses entering the same routing protocol, assuming you have configured a routing protocol here. That does not mean private networks will be exposed to the public Internet. For communication between R1 and R3, the crypto access list is used to match traffic, encrypt it, and direct it through the tunnel. For traffic that does not match, typically in a real-world scenario, such traffic would be NATted to gain access to the Internet.
I hope this has been helpful!
Laz
1 Like
Hello Laz!
I just wanted to verify that I am understanding the encapsulation that takes place whenever a packet matches the access list configured on the crypto map in R1.
Since we are using tunnel mode with ESP, that means we are encapsulating the original packet that matched the crypto map inside a new packet with a new IP header that will use the IPSEC tunnel peer’s IP’s as the source/destination IP addresses. In this case that would be a packet with a source IP of 192.168.12.1 and a destination IP of 192.168.23.2 if any traffic being routed by R1 matches the crypto map, such as a ping with Destination IP of 3.3.3.3 and source IP of 1.1.1.1.
It is due to that encapsulation that R2 knows how to forward those packets to the loopback of R3 without needing any routes configured towards that loopback correct? Since R2 has directly connected networks for 192.168.12.0/24 and 192.168.23.0/24, when a packet with a destination IP address matching any of those networks comes into the router, It knows how to forward those encrypted packets without having to look at the inner IP header that actually has the destination IP of 3.3.3.3 and source of 1.1.1.1.
But, since R2 doesnt have any routes configured for the loopbacks of R1 and R3, any packet with a destination IP of either of those Loopbacks will be unrouteable by the router and the packet would be dropped since it doesnt have any entries that would match a destination of 3.3.3.3 or 1.1.1.1. Because of this, in the example for the lesson where we pinged 3.3.3.3 from R1, if we had not used the source command to specify our loopback IP as the source IP address of the packet, the ping would have failed. This would be due to the packet not matching the crypto map access list, and thus not being encapsulated into a ESP IP header that R2 would know how to route (via its directly connected network routes). Therefore, for the network shown in this lesson, in order to have any connectivity between the loopbacks of R1 and R3 those packets would have to be encapsulated using the ESP IP header after matching the crypto map access list, otherwise R2 would need to have routes configured on it that would enable it to find a match for any packets with destination IPs of 1.1.1.1 or 3.3.3.3. Is my understanding correct?
As a final question, is the access list configured on a crypto map only used to match the traffic that should be encrypted, and traffic that should not be encrypted? for example, will an access list configured on a crypto map drop any traffic that does not match the statement, or simply not encrypt it? in the example for the lesson, we only use a permit statement for packets being sent between the loopbacks, but does an access list on a crypto map not have an implicit deny everything at the end like a regular access list does?
Thank You Laz!
Hello Paul
Your understanding of how ESP encapsulation works in tunnel mode is correct. The original IP packet is encapsulated in a new IP packet with new source and destination IP addresses. This is what allows R2 to forward the packets to R3’s loopback without needing any specific routes configured for that loopback. R2 will simply forward the packet based on the outer IP header, which contains the IP addresses of the IPSec tunnel endpoints, and R2 has routing information for those networks.
You’re also correct in stating that if R2 does not have routes to the loopbacks of R1 and R3, it will drop any packets with those destination IPs. This is why the source IP must be specified when pinging from R1 to 3.3.3.3, to ensure the packet matches the crypto map and gets encapsulated.
Concerning your final question, the access list on the crypto map is used only to identify interesting traffic, that is, traffic that we want to encapsulate. The ACL doesn’t act as a filter that will permit or deny traffic, but it acts as a mechanism to identify traffic to encapsulate, and traffic not to encapsulate. Traffic that does not match the ACL is not denied, it is simply sent without encapsulation. Does that make sense>?
I hope this has been helpful!
Laz