Cisco ROUTE FLG IPSec issue/question...
So, I am studying the IPSec section of Chapter 7: Implementing Routing Facilities for Branch Offices and Mobile Workers, and in example 7-27 Initiating an IPSec VPN Tunnel, the text mentions "even though the ping was successful, it appears the tunnel is down."
The text goes on to mention that the Crypto Map ACL and NAT ACL are working such that traffic from the private LAN is getting NAT'ed before it can be matched by the Crypto ACL, and therefore, the traffic is not getting flagged as "interesting".
Yet..The ping was successful?
I assume this traffic is defaulting to the private WAN (that EIGRP is running over..) as a path to get to the 10.10.10.0 network?
But if so, according to the text, ALL traffic is getting NAT'ed to the public IP address, per the debug ip nat command. Now, I am not 100% up to speed on exactly how NAT works, but it seems to me the traffic ONLY gets NAT'ed when it leaves the uplink to the internet/ISP connection.
THEREFORE, if the route in the example FLG network would default over to the private WAN, then NAT plays no part.
So to sum it up, please tell me if I have this right, according to that section of chapter 7:
1. The only current route to network 10.10.10.0 is through the private WAN, learned by EIGRP.
2. IPSec configuration has been made, but NAT configuration incorrectly NATs all traffic from 192.168.1.0 network prior to being matched by IPSec ACL, which keeps Tunnel down due to lack of interesting traffic.
3. Ping is successful, even though the Tunnel is down. FLG text attributes Tunnel being down due to NAT configuration, but makes no mention of why ping is still successful.
4. Seems to me the only way for ping to be successful is if traffic is routed directly from LAN interface (192.168.1.0 network) directly to Private WAN interface (the EIGRP-learned route to 10.10.10.0.)
5. IF Crypto Map is applied BEFORE the routing process can perform, then the traffic should be deemed interesting, and flow over the activated Tunnel.
Can someone please explain what exactly is happening with this example in the book? I am confused about the order of precedence of the routing table, IPSec configuration, and NAT configuration.
Thanks,
Russ
The text goes on to mention that the Crypto Map ACL and NAT ACL are working such that traffic from the private LAN is getting NAT'ed before it can be matched by the Crypto ACL, and therefore, the traffic is not getting flagged as "interesting".
Yet..The ping was successful?
I assume this traffic is defaulting to the private WAN (that EIGRP is running over..) as a path to get to the 10.10.10.0 network?
But if so, according to the text, ALL traffic is getting NAT'ed to the public IP address, per the debug ip nat command. Now, I am not 100% up to speed on exactly how NAT works, but it seems to me the traffic ONLY gets NAT'ed when it leaves the uplink to the internet/ISP connection.
THEREFORE, if the route in the example FLG network would default over to the private WAN, then NAT plays no part.
So to sum it up, please tell me if I have this right, according to that section of chapter 7:
1. The only current route to network 10.10.10.0 is through the private WAN, learned by EIGRP.
2. IPSec configuration has been made, but NAT configuration incorrectly NATs all traffic from 192.168.1.0 network prior to being matched by IPSec ACL, which keeps Tunnel down due to lack of interesting traffic.
3. Ping is successful, even though the Tunnel is down. FLG text attributes Tunnel being down due to NAT configuration, but makes no mention of why ping is still successful.
4. Seems to me the only way for ping to be successful is if traffic is routed directly from LAN interface (192.168.1.0 network) directly to Private WAN interface (the EIGRP-learned route to 10.10.10.0.)
5. IF Crypto Map is applied BEFORE the routing process can perform, then the traffic should be deemed interesting, and flow over the activated Tunnel.
Can someone please explain what exactly is happening with this example in the book? I am confused about the order of precedence of the routing table, IPSec configuration, and NAT configuration.
Thanks,
Russ
Currently working on: CCNA:Security
Up next: CCNA:Voice
Up next: CCNA:Voice