VPN Tunnel between Cisco ISR and RV134W Routers

[Dmitry Golovenkin]

I am having an issue getting a tunnel properly working between the two routers. The router at the main office is an ISR 1921 and the remote location has RV134W. I have an IPSec Site-to-site VPN configured between the two, which is all up but not fully as I cannot ping any of the endpoints from either end. If I am at a remote location, I can ping the main router find and from the main location I can ping the remote router via their local IPs, but nothing else.

Any ideas?

[tonyk0001]

If you can ping the remote Network's gateway from both sides then nothing should stop you from pinging the endpoints unless you are pinging the wrong IPs or if the endpoints' firewall is not allowing icmp.

[Dmitry Golovenkin]

One would think so but I am on 192.168.3.107 and I can ping 192.168.1.254 (1921/K9) but cannot ping 192.168.1.1 or any other IP on that subnet with firewalls off. The same happens if I am on 192.168.1.1 and I can ping 192.168.3.254 (RV134) but cannot ping 192.168.3.107 or any other IP. Firewalls are off on end points.

[tonyk0001]

Can you ping 192.168.3.107 from 192.168.3.254 or ping 192.168.1.1 from 192.168.1.254 ?

[Sheraz.Salim]

just to add what tony said. might you have a windows firewall on the PCs

[Sheraz.Salim]

ok how the Main router is connected to PC a direct link or in between there is a switch etc

[Dmitry Golovenkin]

There are cisco switches in between, they are layer 2 switches without any routes setup on them. 

This was actually working all okay until one day the connection that stopped working. I replaced the DrayTek with RV134W router and got the tunnel up but still not up fully as we obviously cannot access anything from remote location or vise-versa.

[Sheraz.Salim]

Extended IP access list NAT
    10 deny ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255 (19095 matches)
    20 deny ip 192.168.1.0 0.0.0.255 10.10.3.0 0.0.0.255 (23 matches)
    30 deny ip 10.10.1.0 0.0.0.255 10.10.3.0 0.0.0.255 (10 matches)
    40 deny ip 10.10.1.0 0.0.0.255 192.168.3.0 0.0.0.255
    90 permit ip any any (228233 matches)

Extended IP access list vpn-tunnel
    10 permit ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255 (17007 matches)

 this command  Extended IP access list NAT where you have applied this to.

take these ip address off

10 deny ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255 (19095 matches)
20 deny ip 192.168.1.0 0.0.0.255 10.10.3.0 0.0.0.255 (23 matches)

just of testing take it off. if possible to do it.

[Dmitry Golovenkin]

That's applied to a route-map for NAT purposes for split tunnel to work.

ip nat inside source route-map internet interface Dialer1 overload
route-map internet permit 10
 match ip address NAT
 match interface Dialer1

[Dmitry Golovenkin]

That's applied to a route-map for NAT purposes for split tunnel to work.

ip nat inside source route-map internet interface Dialer1 overload
route-map internet permit 10
 match ip address NAT
 match interface Dialer1

If I take these out, the VPN won't work as the traffic that's destined for VPN tunnel will instead be NAT'ing out. 

[Sheraz.Salim]

i mean to say is take this rule out only

 no deny ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.25

 than test the vpn. as you have already define the interested traffic it will be secure in the tunnel and yours tunnel is already up but you cant access the other end so i am thinking it could this rules stop us. might i may be wrong. but if taking this acl rule out and test if not success but it back in.

[tonyk0001]

I agree with @Sheraz.Salim on this one. You can can remove it and re-add it if it doesnt work but please also verify the access-list you matched when configuring the VPN if it is vpn-tunnel or NAT.

[Dmitry Golovenkin]

I've done that but now I cannot ping anything from either end...

ping 192.168.3.254 sou gi0/1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.254, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.254
.....
Success rate is 0 percent (0/5)

The router is now trying to NAT the traffic instead rather than send it via the VPN tunnel. Hmmm... 

[Sheraz.Salim]

Hi Dimtry.

Had a good look into your configuration. Here is my input into this issue.

Main router address 84.45.x.x  which mean your

Main Router

----------

Interface XXX

    crypto map vpn

    match address vpn-tunnel

    peer 87.127.x.x

!

with default route 0.0.0.0 0.0.0.0

now at Branch Router you have only show us the routing table entry and ACL. ACL look good on both side Branch and on Main router. however, I noted default route on branch router. I have also see other routes in it. which i dont understand why you having them. For example why you them i have attach the photo.

the number in photo number 1 rule make sense it has a default  route. however on the main router say its peer is 87.127.x.x (see point/number 2).

my question is what peer address you configured under DSL_ATM_WAN. my understanding is when you tigger a packet on Main router towards Branch router the flow of packet flow this way.

Main router

---------

ping 192.168.3.254 source 192.168.1.X

1. the phase 1 trigger the key exchanges and neigoatioc happens

2. ipsec take place where peer ip address is 87.127.x.x (as you define this in your crypto map). with interesting traffic ACL already define in your confg.

3. now as we dont no what crytp map peer address you define on your brach router. but looking at the branch router you already define a route. you mentioned 87.127.x.x (Gateway) destination (78.33.x.x)

so this could explain why you not hitting the other address in your ACL.

your router branch should have a crypto map peer 84.45.x.x

or if you share the config file CLI of branch router and the Main router.

[Dmitry Golovenkin]

The first route is automatically acquired via the PPPoE session from the ISP and the second route is for the VPN, which automatically gets added in it seems. There is no way for me to remove that route.. 

I can share the configs but the branch router is an RV134W, which has some crappy CLI, completely different to 1921 so not sure how helpful that will be?