CCTA study materials
CCTA study resources

Connected keys with a missing protected subnet

CCTA · Put your knowledge to work in context.

All case studies

Connected keys with a missing protected subnet

Two sites establish a VPN and show a connected tunnel indicator. Existing application traffic between their original subnets works, but a new server network cannot be reached. The local definition includes the new range while the remote accepted selector remains limited to the original subnet. An external capture filtered only for the private server address is empty, and the path uses NAT traversal. Outbound counters for unrelated existing traffic continue increasing. A larger file transfer on an old subnet also stalls, although small requests pass. The team has not correlated the precise failing tuples with both peers’ selector and packet evidence. No universal encapsulation overhead or timeout value is supplied.

1. How should the new-subnet failure be investigated?

Read the worked answer

Compare the exact flow with both configured and accepted selectors, routes, policy and NAT behavior. Existing traffic and aggregate counters do not validate the new range. Capture the actual visible outer NAT-T transport and correlate suitable inner-flow evidence rather than filtering only private addresses externally.

2. What separate issue should be tested for the larger transfer?

Read the worked answer

Investigate packet size, actual path MTU, encapsulation and relevant feedback using bounded tests. Small-request success does not prove larger packets fit, and any size calculation requires the actual or explicitly supplied overhead. Validate the protected application after each justified scoped correction.