I am setting up a S2S VPN tunnel from a Cisco ASA - 5520 to a business partner using a Juniper device. The addresses he has provided me include a single host address for interesting traffic and the peer address - they are the same address. The phase1 and 2 are successful - tunnel comes up and traffic passes from his site to mine through the ASA to the internal server but the return traffic from the server never leaves my ASA through the tunnel.
Specifically, monitoring shows Bytes rx but no tx. Packet capture shows that packets from him pass through the ASA and come back from the host.
Any suggestions - I am wondering if the fact that the outside and interesting traffic are the same causes a routing issue for return traffic in the ASA.
Should not be a problem to my understanding. I have tried L2L VPN setups where the other ends Peer IP = Encryption Domain. This has been used for example in encrypting the remote ASA Syslog traffic.
Have you configured NAT0 for the traffic from your server to the Remote Peer IP address?
I am not sure did you mean the traffic is coming all the way to the server OR if you are just just seeing the Rx traffic. (It might stop at the ASA even though the ASA received it trough the tunnel)
So I would suggest checking your sides servers NAT0 configuration for the L2L VPN connection
You can also verify this with "packet-tracer" command
packet-tracer input tcp 12345
Replace the above sections with the interface "nameif" behind which your server is located and insert the correct IP address and port information. This will tell you if the traffic would hit the correct NAT rules.
For clarification, I see the traffic from the remote location end device pass through the tunnel into my asa then pass unencrypted through the next hop device behind the asa to the internal server inside my network and then return through that same internal device as return traffic to the asa (ip accounting on the next hop device behind the asa). With packet capture turned on, (ASDM), I see the traffic going both ways when I monitor from the inside interface. But Bytes tx never increments so it appears to never be sent out.
I could be wrong but it looks to me like the outbound/return traffic is not attempting to go out via the tunnel but is instead attempting to leave via the outside/Internet interface. Am I mis-interpriting this?
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in x.y.z 0.0.0.0 SPVPN-GA-Internet-1
Phase: 2
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 3
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:
Phase: 4
Type: ACCESS-LIST
Subtype: vpn-user
Result: DROP
Config:
Additional Information:
Result:
input-interface: SPVPN-SP-GA-Inside
input-status: up
input-line-status: up
output-interface: SPVPN-GA-Internet-1
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
Seems to me more like you have "vpn-filter" configured under the "group-policy" used in this connections "tunnel-group"
So check the "tunnel-group" configuration for this connection. Check which "group-policy" it refers to. Then check the "group-policy" configuration and find the "vpn-filter" configuration there and it will show an "access-list" name. Check that "access-list" configuration if it is causing the problems by not allowing the traffic.
To view the configurations easily use the commands
show run tunnel-group
show run group-policy
show run access-list
show access-list
Though you say you can see the traffic past the ASA? Might even be that the "packet-tracer" just didnt match the actual "access-list" used. Not sure.
I changed the policy associated with the connection to any any without any improvement. I then bounced the tunnel itself and traffic surprise, it started working. Changed the policy back to what it was originally and it is still working so there ya go.
I have had situation with 8.2(1) software atleast where the ASA might suddenly stop encrypting traffic. This partially matches the description you gave.
I have previously confirmed that it can be corrected with reload of the ASA or if the ASA is in a Failover pair then even changing the Active device can stop the problems.
Then again I have not been able to correct this problem simply by taking the VPN connection down and letting it renegotiate. Must be some other bug perhaps.
