cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1310
Views
0
Helpful
12
Replies

Cisco to WatchGuard VPN Tunnel Cant Ping machines only the routers

WizJ
Level 1
Level 1

Reading this post has led me to believe i have a ip route issue. https://community.cisco.com/t5/vpn/cannot-ping-machines-on-remote-subnet-while-site-to-site-vpn/td-p/1469344

Cisco 1921 -> 192.168.1.1  Machine on 192.168.1.2

WG T20 -> 10.0.1.1 Machine on 10.0.1.25

WG can ping the machine and vica versa. Same with Cisco. Neither can ping the other network. I had ip route setup early on that was 0.0.0.0 0.0.0.0 XX.XXX.253.97 (Which is the gateway of the ISP Modem) and i have no idea why i did that. When that was used i was able to at least get a ping response from the other routers ip. I could ping 10.0.1.1 from machine @ 192.168.1.2 as well as the other way around. I was not able to ping the opposing Machine though. What i need is basically all traffic from 192.168 network to go to the 10.0 network. This specific setup is for testing. I simply need to be able to send data from the 192 network to the machine @ 10.0.1.25. I have attached the Cicso config.

Any help would be appreciated. I am a networking noob.

1 Accepted Solution

Accepted Solutions

@WizJ not talking about blocking traffic, but you need to explictly permit traffic over the VPN - it's important as the configuration on the other end needs to mirror the ACL configuration.

# Crypto map ACL to encrypt traffic from 192.168.1.0/24 to 10.0.1.0/24 network.
access-list 101 permit ip 192.168.1.0 0.0.0.255 10.0.1.0 0.0.0.255

# NAT ACL - NAT traffic to the internet and to ensure traffic from 192.168.1.0/24 to 10.0.1.0/24 over the VPN is not translated
access-list 102 deny ip 192.168.1.0 0.0.0.255 10.0.1.0 0.0.0.255
access-list 102 permit ip 192.168.1.0 0.0.0.255 any
!
ip nat inside source list 102 interface GigabitEthernet0/0 overload

View solution in original post

12 Replies 12

balaji.bandi
Hall of Fame
Hall of Fame

Add the route back as you removed in the config to ISP as below  and test it

 

ip route 0.0.0.0 0.0.0.0 XX.XXX.253.97
no ip default-network 192.168.1.0
!
no access-list 101 permit ip any any
access-list 101 permit ip 192.168.1.0 0.0.0.255 10.0.1.0 0.0.0.255
!
access-list 1 deny ip 192.168.1.0 0.0.0.255 10.0.1.0 0.0.0.255
access-list 1 permit ip 192.168.1.0 0.0.0.255 any
!

still having to issue posting the latest config and the below output : (make sure the other side configs should also matches yours to establish VPN)

show run

show crypto session

 

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

WizJ
Level 1
Level 1

I have added the route back to the ISP gateway as suggested. I keep getting an error trying to create the access list. The change suggested access-list 1 deny ip 192.168.1.0 0.0.0.255 10.0.1.0 0.0.0.255 keeps telling me "Invalid input detected at ^ marker" pointing to the "ip" section of the command. Is it supposed to be an extended list?

@WizJ that because ACL "1" is a standard ACL (allowing you to specify only the source network), you'd need to create an extended ACL, use ACL number 101.

WizJ
Level 1
Level 1

That is what i was thinking. So should my ACL 101 be

access-list 101 permit ip 192.168.1.0 0.0.0.255 10.0.1.0 0.0.0.255
access-list 101 deny ip 192.168.1.0 0.0.0.255 10.0.1.0 0.0.0.255
access-list 101 permit ip 192.168.1.0 0.0.0.255 any

Or just the two:

access-list 101 deny ip 192.168.1.0 0.0.0.255 10.0.1.0 0.0.0.255
access-list 101 permit ip 192.168.1.0 0.0.0.255 any

 

@WizJ where are you even applying this ACL? If on the crypto map you just specify interesting traffic with a permit statements using an extended ACL.

You'd need to use an extended ACL for NAT, you deny what you don't want translating over the VPN and permit the rest.

 

WizJ
Level 1
Level 1

This ACL is being applied to my crypto map. In this scenario it is a test environment. I do not want to block any traffic really. Is there a way I can just let all traffic go through? All i need to do is send data from the machine on the 192.168 network to the machine on the 10.0.1 network. Is this possible?

@WizJ not talking about blocking traffic, but you need to explictly permit traffic over the VPN - it's important as the configuration on the other end needs to mirror the ACL configuration.

# Crypto map ACL to encrypt traffic from 192.168.1.0/24 to 10.0.1.0/24 network.
access-list 101 permit ip 192.168.1.0 0.0.0.255 10.0.1.0 0.0.0.255

# NAT ACL - NAT traffic to the internet and to ensure traffic from 192.168.1.0/24 to 10.0.1.0/24 over the VPN is not translated
access-list 102 deny ip 192.168.1.0 0.0.0.255 10.0.1.0 0.0.0.255
access-list 102 permit ip 192.168.1.0 0.0.0.255 any
!
ip nat inside source list 102 interface GigabitEthernet0/0 overload

So the Crypto map ACL is permitting traffic from one network to the other and that will go through the VPN and be encrypted. While the NAT ACL will deny traffic from one network to the other (which should go through the VPN) and allow all other traffic so it can reach the internet?

@WizJ yes, only traffic matching ACL 101 will be encrypted. ACL 102 (the NAT ACL) will ensure traffic destined over the VPN tunnel will not be translated, but will nat the rest of the traffic.

Ok. I have all of that in place. I am now able to ping the router from a machine on the opposing network but still unable to ping the machines. EG. ping from machine @ 192.168.1.2 to 10.0.1.25 times out but pinging the gateway (10.0.1.1) works fine.

@WizJ Does the machine on the other end (10.0.1.25) have a local firewall turned on that could be blocking ping?

Run the ping to 10.0.1.1, take a packet capture on the other end (10.0.1.25) - confirm whether the ping is received and if it responds.

Is the configuration of the other device correct? Is it configured not to unintentially translate the VPN traffic?

 

 

I pinged the machine @ 10.0.1.25 from the WatchGuard GUI and lost all packets. I have no Routes setup in the WatchGuard. The problem must be there. I will refer to the WatchGuard documentation and try and figure that end out. Thanks again Rob.