engineerNL
asked on
Cisco ASA VPN tunnel not working after modem reset
Hi all,
We have a problem with a site-to-site VPN tunnel between 2 Cisco ASA 5505's.
Site 1:
Datacenter
Cisco ASA has a public IP address on the outside interface provided by the datacenter ISP.
Site 2:
Customer office
Cisco ASA connects to the internet via PPPoE via a DSL modem in bridge modem.
The ASA has a public IP on the outside interface.
Lately, the DSL line is not really steady. When the DSL line crashes, the customer resets the modem and the line comes up fine again. The modem is not the problem, it is already replaced.
However, while internet/DSL comes up fine, the site-to-site VPN does not. A tunnel is created, but the ASDM states that there are a lot of bytes TX, but to bytes RX. That means somehow the tunnel is set up but no traffic is received. The ASA on the other site reports the same.
When we manually logout the VPN tunnel via the ASDM, automatically a new tunnel is created by the ASA and from there on it works fine.
What could be the problem? We don't want to have to reset the VPN manually everytime the modem is reset.
We have a problem with a site-to-site VPN tunnel between 2 Cisco ASA 5505's.
Site 1:
Datacenter
Cisco ASA has a public IP address on the outside interface provided by the datacenter ISP.
Site 2:
Customer office
Cisco ASA connects to the internet via PPPoE via a DSL modem in bridge modem.
The ASA has a public IP on the outside interface.
Lately, the DSL line is not really steady. When the DSL line crashes, the customer resets the modem and the line comes up fine again. The modem is not the problem, it is already replaced.
However, while internet/DSL comes up fine, the site-to-site VPN does not. A tunnel is created, but the ASDM states that there are a lot of bytes TX, but to bytes RX. That means somehow the tunnel is set up but no traffic is received. The ASA on the other site reports the same.
When we manually logout the VPN tunnel via the ASDM, automatically a new tunnel is created by the ASA and from there on it works fine.
What could be the problem? We don't want to have to reset the VPN manually everytime the modem is reset.
ASKER
Hi Petelong,
Both ASA's are running on version 8.4.1. Upgrade is not possible since the customer has no smartnet contract.
In my opinion it is perfectly possible that both's ASA have bytes TX but ro RX. The both send, but don't receive. That could be possible since something is wrong.
When I run the command "show crypto isakmp" in the command line, I see that one of the ASA's has "In-Negotiation SAs:0" and the other one says 5. Can that have something to do with the problem?
PFS is on, both are set to option 5. We also tried disabling PFS, same problem.
When we reload the ASA's there is no problem, the tunnel comes up fine again. When we reset the modem, this problem occurs.
Both ASA's are running on version 8.4.1. Upgrade is not possible since the customer has no smartnet contract.
In my opinion it is perfectly possible that both's ASA have bytes TX but ro RX. The both send, but don't receive. That could be possible since something is wrong.
When I run the command "show crypto isakmp" in the command line, I see that one of the ASA's has "In-Negotiation SAs:0" and the other one says 5. Can that have something to do with the problem?
PFS is on, both are set to option 5. We also tried disabling PFS, same problem.
When we reload the ASA's there is no problem, the tunnel comes up fine again. When we reset the modem, this problem occurs.
>>in my opinion it is perfectly possible that both's ASA have bytes TX but ro RX
Yes but only if a device in-between the two IPSEC peers was blocking IPSEC (UDP 500 and or protocol 50)
Yes but only if a device in-between the two IPSEC peers was blocking IPSEC (UDP 500 and or protocol 50)
just confirm DPD is enabled on both side .. DPD is enabled by default on ASA for both L2L and RA IPSec:
https://supportforums.cisco.com/document/32546/dead-peer-detection
https://supportforums.cisco.com/document/32546/dead-peer-detection
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Replacing ASA was the solution. I guess hardware failure
This makes no sense - that cant both be incrementing TX but not RX? Are you sure its not the OPPOSITE way round? If so my technical brain says the problem is a the main site?
Has PFS been enables/disabled on both ends (i.e is one end on and one end off)
Can the main site - route to the DSL site (are there any conflicting route entries on that subnet)
Are both the ASA's running the newest code(yes its a cliche, but one end might have a bug (and its the first thing that TAC would ask!).
You say the tunnel does not come up, does it come up at phase1? as you mentioned TX and RX Im assuming so?
Regards,
Pete