Exam 300-730 topic 1 question 128 discussion

FlexVPN route set remote" refers to the configuration option within a Cisco router where you specify the network routes that should be pushed to a remote FlexVPN client, essentially allowing the client to access specific networks across the VPN tunnel once connected; this is done by defining the remote network addresses on the FlexVPN server, which are then automatically added to the client's routing table when the VPN connection is established.

With the configs provided all seems to be fine. The spokes send their internal subnet (192.16.200.0/24) to the HUb and the "show crypto ikev2 sa detailed" cmd shows that the Hub sent its Internal network as well (192.168.100.0/24). If Pings make it from the Hub to the Spoke and the reply stops at the inside interface then we know a few thigs: 1-Routing from the hub to spoke is correct 2- Spoke can't send the reply to hub (but routing seems to be fine). Neither B or D seems to provide a solution when you verify what is already set. I feel something must be missing on this question.

First, note that from the spoke’s perspective, the **“remote”** network should be the subnet(s) behind the **hub** (that is, 192.168.100.0/24). In the partial configuration shown, the spoke’s authorization policy mistakenly sets **192.168.200.0/24** (its own LAN) as the **remote**. Consequently, the spoke does not encrypt or forward return traffic back toward 192.168.100.0/24, causing the ICMP echo-replies to drop. To fix this, you must tell the spoke that **192.168.100.0/24** (behind the hub) is the **remote** network so that return traffic is included in the encryption domain. Therefore, the correct action is: **D. Add the `route set remote ipv4 192.168.100.0 255.255.255.0` command to the spoke authorization policy.**

On the spoke, the show crypto ikev2 sa detailed command shows "Remote subnets" from the perspective of the spoke. Here, we see: Remote subnets: 10.0.0.1/32 and 192.168.100.0/24 These subnets are what the spoke sees as the hub's protected internal networks. This indicates that the hub has successfully communicated to the spoke that traffic to 192.168.100.0/24 should be encrypted. However, we do not see any mention of the spoke's own internal network (192.168.200.0/24) from the hub's perspective. For the hub to understand that it needs to build a route back to the spoke for 192.168.200.0/24, the hub's IKEv2 authorization policy must include the route set remote command specifying the spoke’s network.

D is the only answer that makes sense

D is the correct answer. look at remote subnet in show crypto result. @kylesam2017 correct. D for sure.

The correct action to resolve the issue is likely to "Add the route set remote ipv4 192.168.100.0 255.255.255.0" command to the spoke authorization policy. Here's the reasoning: 1) The source host that initiates the traffic is 192.168.100.3, which is behind the FlexVPN server (the spoke). 2) The captured ICMP echo replies from host 192.168.200.10 are making it to the inside interface of the spoke. 3) If the traffic from 192.168.200.10 is reaching the spoke but not making it back to the source (192.168.100.3), it suggests a routing issue on the spoke. By adding the route set remote command for the network 192.168.100.0/24 to the spoke's authorization policy, you inform the spoke about the network behind the FlexVPN server. This ensures that the spoke knows how to route the response traffic back to the source host, resolving the issue.

logical answer is C

isnt B ? the command should include the local network , not remote