Watchgautd Site-to-site VPN Problem

From what I can see of the ASA config, 192.168.4.3 is not one of its interfaces, although it could be an internal router.  I don't know much about Watchguards, but if you have to add a route back to 192.168.4.0, then you might try using their outside IP (125.7.91.218) as the gateway.

apart from the previous comment you can allow all port open between the vpn channel

you right, 192.168.4.3 is internal switch. where should i add route back, on watchgard ?

as far as i know all porrs (any) are open between trustes-external and the VPN tunnel, or if there is not the case, where should i add the policy, on whatcguard or ASA ? if yes can you send me an example.

Also, i can ping from a PC at site B to 192.168.100.1 (the internal watchgaurd IP address) but not get through any server/pc behind it. and from a PC at site A i cannot ping anything beyond the tunnel.

Hi There,

Any comment on this, i need an assist on this to fix the routing quickly

Mant thanks

 Does the Watchguard have any sort of monitoring of the VPN tunnel statistics, like number of packets encrpted/decrypted?  If so, then try starting a continuous ping from site B to the Watchguard.  If everything is working like we think it is, the number of encrypt/decrypt packets should increase steadily.  Once that is confirmed, try pinging a known live IP in your network.  If both counters increase, then the problem is probably not on your side.  If however, you only see the decrypt counter increase, then that means the Watchguard isn't sending traffic back through the tunnel for some reason.  You may also want to trace route from both sites and see if there are any abnormal results, like public IPs showing up, indicating the traffic is going out the public interface rather than the tunnel.

  Right now, there are some devices on the other side that you don't have control of and we don't know the details of, like the managed switch at 192.168.4.3.  Since it's managed, is it also a layer 3 switch?  If so, there might be other routing issues that we're unaware of, but first we have to verify that traffic is indeed being encrypted on your side and being forwarded to the ASA.

it looks like both ends of the routes are missing. I would also make sure your tunnel is part of a ANY ANY rule if you are allowing everything through.

Site B wouldn't be able to ping the Watchguard if that were the case.  We need to see some trace route and encrypt/decrypt stats to get a better idea of exactly where packets are getting lost.