So your above output shows both that the actual VPN connections is up and also the output of some "packet-tracer" command that suggests that what you have tested matches some VPN configuration BUT does not go through completely. Did you issue the "packet-tracer" command twice as if the VPN connection is down while doing this the first time issuing the command will only initiate the VPN negotiation while the second one would go through in a normal situation as the VPN connection would then already be negotiatiated.
What catches my eye first in the outputs is that the "show crypto ipsec sa" command shows that its somehow related to Dynamic Map or a map named that way. It also shows only traffic incoming from the remote end. Also when we consider that your "packet-tracer" fails (which I assume is aimed from your LAN to the remote LAN?) it leads me to belive that you have somehow missconfigured your "crypto map" configurations which in turn enabled the remote end to negotiate the VPN up but not letting you negotiate the VPN up.
Personally I would be interested in looking at the output of
show run crypto map
This would tell me how this L2L VPN connections configurations are done and if there is perhaps some configuration there that is preventing the connection working from your side.
Naturally we would need the output of the
show run access-list <acl name of acl used in crypto map>
show run tunnel-group <remote peer ip>
We would also need the NAT configurations related to this L2L VPN connection and the full output of the "packet-tracer" command used.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...