OK, i have made the following test setup:
Im trying to get the following:
1. Connection from the HQ PC to the CUST PC
2. Cust PC to HQ PC
But my pings keep timeing out!!!!
Im using the attached configs
Id really appreciate some help guys its starting to annoy me
On host hostname ci-hq-asa you have a route "route inside 172.16.0.0 255.240.0.0 172.22.0.1" but network 172.16.0.0/24 is outside. Can you revise your routing. check that you have the respective routes pointing in the right direction.
Tried it but it doesnt change anything.
Also that rule is needed in the real environment for this to function there. The 172.16.0.0 network exists at the HQ site.
So the test environment has to mimic that.
For some reason it seems no data is send through the tunnel.
It should just sent packets from over one tunnel through the other tunnel and vice versa but its not doing that.
Hello, first thing I noticed is routing problem. When you say :
"route inside 172.16.0.0 255.240.0.0 172.22.0.1 1" it meens that networks :
172.16.0.0, 172.17.0.0, 172.18.0.0,..172.22.0.0, ..172.31.0.0 all goes via 172.22.0.1!!!
So I will look at this first!
Likely solution is that you can be more specific when configuring routing on ci-hq-asa :
Live the old route because you said that you need it :
route inside 172.16.0.0 255.240.0.0 172.22.0.1 1
and add more specific for remote LAN :
route outside 172.16.0.0 255.255.255.0 10.1.0.2 1
I hope it helps,
tried it out but i cant seem to get the routing correct
Anyone who can put the routes right for me?
I think it has something to do with the ACL....since NO traffic is passing through any of the 2 tunnels.
Ok, I will look later again, I'm bussy right now,
but you can do some troubleshooting that could help.
Try to ping continuously remote host and enable logging :
If you initiated console session do this and capture logs :
logging console informational
You should receive usefull information on console session:
If you receive to much log lines and can not filter usefull information, try
to buffer logs :
logging console buffered
and than use : show logging buffered
You should see some interesting information regarding your problem!
If you are using telnet or ssh use these commands:
logging monitor informational
or buffered :
logging bufered informational
One more command that could help is packet tracer command,
try with question mark!
I was thinking about your problem again and find small mistake
in my first reply. I wrote that you should add more specific route
route outside 172.16.0.0 255.255.255.0 10.1.0.2 1,
yes, but I made mistake, because next hop is not right (10.1.0.2),
it should be 10.0.0.2, your next hop, router!
So, correct is that you should add this route :
route outside 172.16.0.0 255.255.255.0 10.0.0.2 1
It should work, everything else looks fine!
I've changed the route but still couldnt ping from 10.2.0.1 to 172.16.0.2.
I can also not ping from 10.0.0.1 to 172.16.0.2 but i CAN ping from 172.16.0.2 to 10.0.0.1....
Also i have been trying to find out what was wrong using tracert on the HQ PC and it keeps sending the pings over the wrong network interface.
It doesnt use the VPN adapter but the normal network adapter which is linked to a different network....
this shit is confusing
Appreciate the help though!
I can not understand all of this because I have not the all information needed.
On HQ PC you mentioned some kind VPN adapter and multiple interfaces ?
Please give me routing table on HQ pc :
do this if it is a windows machine: open command prompt and enter command : route print, than press enter,
copy output and post to me in reply!
One more thing! Because Ci-Cust1-hq ASA is Easy VPN Remote client you should try first to ping from host Cust-PC to 10.2.0.1 address
to force tunnel to go up, than from HQ PC to remote PC - Cust-PC!!!
Tried what you said with the pinging but it didn’t work.
The HQ PC is a VM, one interface is connected to the network here, the other is the VPN adapter.
I think the problem is the top route, as all connections to 172.16.0.2 use that route, but I didn’t put it in there.
Also I thought that when a VPN is connected all traffic is ALWAYS send over the VPN and the local connection is lost.
This HQ PC is connected with Cisco VPN client to the HQ ASA (simple IPSEC tunnel).
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.253.129 192.168.253.156 10
10.2.0.0 255.255.255.248 10.2.0.2 10.2.0.2 10
10.2.0.0 255.255.255.0 10.2.0.1 10.2.0.2 1
10.2.0.2 255.255.255.255 127.0.0.1 127.0.0.1 10
10.255.255.255 255.255.255.255 10.2.0.2 10.2.0.2 10
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
172.22.0.46 255.255.255.255 192.168.253.129 192.168.253.156 1
192.168.253.128 255.255.255.128 192.168.253.156 192.168.253.156 10
192.168.253.129 255.255.255.255 192.168.253.156 192.168.253.156 1
192.168.253.156 255.255.255.255 127.0.0.1 127.0.0.1 10
192.168.253.255 255.255.255.255 192.168.253.156 192.168.253.156 10
126.96.36.199 240.0.0.0 10.2.0.2 10.2.0.2 10
188.8.131.52 240.0.0.0 192.168.253.156 192.168.253.156 10
255.255.255.255 255.255.255.255 10.2.0.2 10.2.0.2 1
255.255.255.255 255.255.255.255 192.168.253.156 10004 1
255.255.255.255 255.255.255.255 192.168.253.156 192.168.253.156 1
Default Gateway: 192.168.253.129
Does this make sense to you?
EDIT: Also the VPN adapter does not seem to have a default gateway! :S
you right, all traffic goes via default route.
You can add persistent route on HQ PC for remote LAN, try this :
First disconect from VPN on HQ pc, then add foloving persistent route :
route -p ADD 172.16.0.0 MASK 255.255.255.0 172.22.0.46 METRIC 1
Now on your routing table from HQ you should see this route in
bottom of the output from route print command !
Than connect to VPN again, and than try to ping again!
I forgot to remind you to first try to ping from remote cust-PC to HQ PC, to force tunnel to come up,
and then from HQ to remote! You should see encripting and decripting packets increase
on output from :
show cryptyo ipsec sa command on booth ASAs!
I managed to fix it by using different IPSEC profiles and Group Policies for the 2 VPN connections.
Now i can ping from side to side without any problems.
I found a new problem now, but gunna work on that for a while.
Thanks for the input and help though! would not have found the issue without you