Two ASA 5505 will establish phase 1 and 2 IPSEC site to site VPN but won't pass traffic.

[kiandrass]

We have a client that has two ASA 5505's running at separate sites using a site-to-site VPN. This has been running just fine until we had to change the public IP address of the remote site. Since then, we just can't get the link to work. Phase 1 and 2 will establish just fine, but traffic just will not flow. If you look at the session details on the remote site, it shows TX and RX traffic. If you look at the session details on the main site, it shows that There's TX traffic but 0 RX traffic. We've looked at everything and just can't figure out why it's doing this. To be on the safe side, I updated the IOS on both sites to see if that could be it with no luck.

Attached is the config for the Main site which seems to be the one not getting any RX traffic on the site-to-site vpn. For the purpose of anonymity I've put 666 in the last octet of each public IP. And redacted other details.

Any help here would be hugely appreciated.

[Jon Marshall]

Firstly you have posted this question 5 times, any chance you could delete the others as it causes confusion if people start posting into different threads.

Secondly you are referencing an object-group LAN everywhere but it doesn't seem to be defined in the configuration you posted ?

Is there an chance when you changed the IP that somehow the NAT exemption got messed up on the other site so it is transmitting with the wrong source IPs and so this ASA is dropping the packets ?

Jon

[kiandrass]

Hello Jon,

Thank you very much for you reply. It look like my browser had a little freak out with the site. I've deleted the other posts.

There's aren't any NAT rules on the remote site ASA. I've attached the config for that site in the OP.

I've also updated the previously provided config for the main site. I think I confused the issue when trying to mask some of the names.

Thanks again.

[Jon Marshall]

Thanks for tidying up the posts :)

It's late where I am so I am just logging off but I'll look at this tomorrow or in the meantime someone else may be able to help out.

One thing is on the remote site ASA the peer IP is close enough but on the main site ASA the peer IP for the remote site is nothing like what you have configured.

I am assuming though that as the tunnel is up then it is just that you are trying not to provide too much real information on this site which is the right thing to do.

If  you haven't already it may also be worth running a packet tracer on the main firewall from the outside to the inside to see exactly what the ASA would do with the packet.

Jon

[heiki saaver]

Hello. Any updates on this matter? I am having the same exact problem with two ASA5550  doing site-to-site ipsec tunnels. Both ASAs are running 9.1(7)4 software (asa917-4-k8.bin). One side has only Tx counters increasing and Rx at zero, and the other side has both Rx and Tx counters increasing. I have also opened a TAC case, but no response yet.

[heiki saaver]

Update- got my problem resolved. I discovered I had asymmetric routing toward my VPN peer. It seems that the tunnel is established fine over an asymmetric route, but IPSEC packets are dropped. Just make sure that the ingress and egress route for the VPN peer is the same.

[David Castro F.]

Hello Kiandrass,

I was able to go through all the configuration from both sides, and well since the LAN to LAN comes up, I would recommend you the following:

- Enable:  "sysopt connection permit-vpn" on both ends(Main and Remote), what it does is to bypass any ACLs(Access-groups) preventing the connection.

- Also set up "management-access inside" it will allow you to run ICMP/ SSH / TELNET/ HTTPS through VPN for those interfaces, so to make sure ASA-MAIN inside interface to ASA_REMOTE inside interface work, set up that command and then try, ASA_REMOTE: ping LAN 172.16.10.254 / ASA-MAIN: ping inside 10.4.160.1 . If this works you should check internal routing behind the ASAs,

- Run a packet tracer from both firewalls, such as(Share this with us):

      Remote ASA: Packet-tracer input LAN tcp 10.4.160.15 1234 172.16.10.25 80 detail

      MAIN ASA: Packet-tracer input Inside tcp 172.16.10.25 1234 10.4.160.15 80 detail

- If the traffic is still not going through as it should, please set up a capture to see the ESP payloads and since the remote device has a device in front NATing the WAN address, it should use 4500 NAT-T, so lets make sure with a capture to see all of that:

  REMOTE_ASA: capture CAPNAME interface WAN match ip host 139.130.5.98 host 144.140.233.666

 MAIN_ASA: capture CAPNAME interface outside match ip host 139.130.5.98 host 144.140.233.666

- Most likely when you see in the capture traffic going through and not being received in the capture of the remote device, it could be an issue with the ISP, on this ocasion the new ISP, but lets get all together first,

Please proceed to rate and mark as correct this post if it helped you! keep me posted!

Thanks,

David Castro,