A - vpn is established
B - vpn is established
C - Split Tunneling has nothing to do with a site-to-site VPN.
D - we see traffic is comming in but no traffic is going into the tunnel so its likely a access policy wrong or missing
A & B are ruled out by #pkts encaps #pkts decaps: traffic is flowing based on these lines, so the VPN is established.
#pkts decaps: 17 - we are getting traffic in, so it is not blocked by the ACL.
Only C is left.
no no my friend...split-tunneling doesnt prevent vpns from operating but define what traffic should use the vpn tunnel and what traffic shoudnt so forget C...on FTD devices access policies shld also properly permit traffic provide vpn has been configured proper way...D sounds better
As others have pointed out also, the correct answer can only be D for the reasons provided by others however there MUST be a typo in D because traffic is being successfully received as indicated by the decaps and decrypt packets. So the actual correct answer would be "The access control policy is not allowing VPN traffic OUT."
A - cannot be true since the tunnel is established as we can see pkts decerypted and pkts encrypted --> zero
B: Same as above, tunnel is up so Phase1 and Phase2 are both up and interesting traffic is passing
C: Split tunneling works for remote access VPNs. It defines what traffic, when a user connects to a remote access VPN server, should go inside the VPN and what traffic should go out via his local home router.
D: Since there are no encapsulations happening encaps:0bytes.....it evidently shows a problem with the access list
Maybe it is another example of the stupid question/exhibit or a tricky one.
If VPN is established and especially Phase 2 with all security associations created then two firewall peers negotiated everything which is matching. Of course nothing to do with split-tunneling on the site-to-site tunnel. The only explanation for this assymetry of counters for packets entering the tunnel and exiting is either missing NAT exemption rules or indeed access control policy rule which should be configured only if we stopped trusting the traffic that exits the tunnel (former sysopt connection permit-vpn)
i would go with D and hoping this is just a typo (and it meant actually "out") because it seems to be the "less" wrong answer.
C makes no sense from both wording and technically. If you do something wrong according to what to send into the tunnel it would either not come up at all or would throw erros about "proxy identity mismatch" (we dont have debugs so this cant be validated)
I think the answer is D because if you look carefully at the access-list it is incorrectly formatted. There is an extra period between the mask of the source and the ip of the destination instead of a space - 255.255.255.0.10.0.10.0 instead of 255.255.255.0 10.0.10.0
A and B are incorrect because we can see the tunnel is up. We know it is up because we have 17 decap packets. This means traffic is coming from the peer to the ASA and it decrypts and sends it according to the routing table. C is incorrect because that is related to remote-access VPNs, not S2S VPNs. Since we have no encaps - which is traffic entering the ASA, being encrypted, and sent out the tunnel - this likely means the ASA has an inbound access-list on the 'inside' or whatever interface not allowing the interesting traffic in. So the traffic blocked entering into the ASA never giving it an option to be encrypted. D is therefore the answer.
upvoted 7 times
...
...
This section is not available anymore. Please use the main Exam Page.350-701 Exam Questions
Log in to ExamTopics
Sign in:
Community vote distribution
A (35%)
C (25%)
B (20%)
Other
Most Voted
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
kerniger
Highly Voted 3 years, 8 months agozap_pap
Highly Voted 3 years, 9 months agojmosilva
3 years, 9 months agogondohwe
1 year, 11 months agogondohwe
1 year, 11 months agoRockbo47
Most Recent 8 months, 3 weeks agoMarshpillowz
1 year agoAlizade
1 year, 6 months agointirt
2 years, 4 months agoureis
2 years, 6 months agogetafix
2 years, 11 months agosomaaoo
3 years agokillbots
3 years agozheka
3 years, 5 months agozeroC00L
3 years, 7 months agoSarbi
3 years, 8 months agoNarcolepto
3 years, 10 months agoDead_Adriano
3 years, 10 months agoRaajaa
3 years, 10 months agoBarish
3 years, 11 months agoMinipaf
3 years, 12 months agocciewannab
3 years, 7 months ago