Exam 300-730 topic 1 question 128 discussion

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