Hub-and-Spoke IPsec VPN Issue
We're trying to replace a Cisco ASA at our main office with a Firebox, but I'm having trouble figuring out how to route IPsec VPN traffic from one remote subnet to another remote subnet through it (i.e. a hub-and-spoke topology, or what WatchGuard seems to refer to as "tunnel switching"). At this page:
it looks pretty self-explanatory: You just add the remote subnet or subnets to the Tunnel Route Settings for the tunnel. So, for example, our main office is 192.168.0.0/24, our two branch offices are A) 10.1.0.0/16 and 
10.2.0.0/16, and therefore the tunnel route settings for A would include 192.168.0.0/24 <===> 10.1.0.0/16 and 10.2.0.0/16 <===> 10.1.0.0/16, while the tunnel route settings for B would include 192.168.0.0/24 <===> 10.2.0.0/16 and 10.1.0.0/16 <===> 10.2.0.0/16. However, this isn't working for us: The tunnel between the main office and each branch office comes up just fine, but the two branch offices are unable to communicate with each other.
Each branch office endpoint is a Cisco ISR router, configured to forward traffic destined for both the main office and other branch offices over the tunnel to the main office, and this worked for years with our Cisco ASA, I just can't get it to work with the Firebox. Anyone have any ideas? Thank you for very much for your help!
Best Answer
-
Options
Ok, for the record this is now resolved. I didn't realize that the network names on both ends for the network being tunneled had to match in order it for it to work on the Firebox. On the branch side in the Cisco router I had it set to tunnel anything from 10.0.0.0/8 back to the office; this one address convienently covers all of our branch offices (it's also set to tunnel 192.168.0.0/16 back to the office, because that's our office subnet). On the Firebox, however, for testing in the destination tunnel configuration I had the branch office subnet explicitly set to its network address (10.1.0.0/16, for example). To get it to work I just had to change it to 10.0.0.0/8, so that the two ends matched.
Sorry about, thanks for your help!
0
Answers
Time to do some logging to see if the ASA's are sending packets from 1 remote site to the other remote site via the BOVPN.
One option is to turn Logging on the existing policy which allows incoming VPN traffic to your main office WG firewall.
Another is to create a specific policy and turn on logging on it.
Then in traffic monitor, look for allowed packets to remote 2 from remote 1 or vice versa.
Also, look for denied packets for remote 1 or 2 from the other.
I'm so sorry I never responded to this; I got really busy with other things, and then we discovered another issue (which I'm about to make another post here in the forum about) which I'd really like to get resolved before working on this (remote subnet to remote subnet communication isn't actually all that important for us, for the most part). Once I've resolved the other issue I'll come back to this one and try what you've said here, thank you again for your reply.