WatchGuard tunnel switching -- trying to connect 2 tunnels

[jmkelly]

I'm trying to bridge two tunnels between two gateways. I've followed the directions in WatchGuard's docs about tunnel-switching but without success.

Tunnel A goes from WatchGuard XTM-21 to WatchGuard XTM505. It works fine. Traffic goes to and from both networks.

Tunnel B goes from WatchGuard XTM505 to a colo. It works fine, too. Traffic goes to and from both networks.

I want WatchGuard XTM505 to bridge the two tunnels so that the network on WatchGuard XTM-21 can send and receive traffic to and from the colo.

It only half works. Traffic goes from Tunnel A through Tunnel B to the colo with no problems. But traffic from the colo does not appear at either WatchGuard A or WatchGuard B.

The colo's tech says he's sure it's going into the network between us, and traffic from the colo to our other subnets arrives OK.

One of the strangest things about it is that the traffic counts on both tunnels show 0 sent packets and >0 received. Even when we're sending packets from WatchGuard A and they're arriving at the colo, neither tunnel shows any sent packets.

Any ideas?

 

[muckermucker]

Any ideas?

Yes, perfectly. The issue is routing. Firstly you need to understand that routing one way is completely independant of the return path it takes. I mention this in my routing article I will link to in a bit. This is why you can see packets arrive going one way but when you ping you don't get a reply. A ping remember is the packets going somewhere and then returning. If the reply packets can't reply then it will fail.

At this point the VPN's are fine and the issue is routing. When you create a VPN the router knows where the two private LANs are that it is attachached to; it's local LAN and VPN LAN. You have a third network (the other VPN) that it doesn't know about so it does what all routers do when they can't find the destination subnet. It sends it out through the default gateway which will be the internet...and we know this will fail. All you need to do is add some static routes at all routers which tells them where every network is located. Have a read of this which explains exactly why you have this problem and how to configure it correctly. If you find it helpful please comment and distribute it. The routing table

 

[jmkelly]

Routing is good on both ends. All networks on the LAN side of the XTM505 can access both the XTM-21's network and the colo. Here's a picture:

branch office (XTM21) <===> XTM505 <===> main network: OK

main network <===> XTM505 <===> colo: OK

XTM21 ===> XTM505 ===> colo: OK? -- the colo's tech sees our pings arriving there.

XTM21 <=== XTM505 <=== colo: Not OK -- we see only DPD packets from colo

Packets flow between the XTM-21 and the XTM505, and between the XTM505 and the colo. From the colo's point of view, the XTM505 is at the same IP address for the branch office network (XTM21) as it is for the main network. The only difference (which ought to be invisible to the colo) is that traffic for the branch office network does not exit the XTM505 via its LAN port but gets sent back out through a tunnel on its WAN port.

Traffic between the colo's tunnel and hosts on the XTM505's LAN port flows properly; traffic between our branch office's tunnel and hosts on the LAN port flows properly; traffic between the colo's tunnel and the branch office's tunnel on the WAN port seems to flow only to the colo.

 

[muckermucker]

What does DPD stand for? I did a quick google but nothing came up.

I have a simple question that will save us going around in circles here. Have you added ANY static routes anywhere between all three networks? If yes, where are they located and what are they?

Also, as I stated in my OP it doesn't matter that routing works from both remote offices to the central site. The remote offices need routes to each other. If these don't exist it won't work. I don't know your IP ranges so I'll use my own for an example:

XTM21 office IP range: 192.168.0.x
XTM505 office IP range: 192.168.1.x
colo IP range: 192.168.3.x

As the VPN exists between XTM21 <> XTM505 BOTH of them will have routes preconfigured which tell the routers to route traffic down the VPN. IE on XTM21 router it will have a route like so:

destination network: 192.168.1.0/24 gateway [VPN interface]

When packets hit the router destined for that network it knows to push them down the VPN. Now...what do you think happens when it receives packets destined for 192.168.3.x? Do you think it pushes them down the VPN? No, it doesn't...well at least it shoudln't anyway. It should send them out the default gateway (which would be the internet) and fail.

By some weird twist of fate though these packets do actually go down the VPN (at least from your observations anyway). This is not the concern though but it is important to know that this SHOULDN'T work. Maybe you added a static route or whatever, I don't know. Anyay, at the colo site the same thing happens:
If it wants to send packets to 192.168.1.x it works because it has a direct VPN to this network and therefore a matching route entry in the routing table. But it doesn't have one for 192.168.0.x so it can't send packets back.

I can only go off what your statements say and assuming you are correct in everything you have said i know 100% that this is the cause. Check the routing tables on the routers.

Let me know how you get on or your thoughts.

 

[jmkelly]

DPD is Dead Peer Detection.

Static routes are in place at all three routers. A session with WatchGuard's techs revealed a couple of interesting things:

(1) There has to be a route all the way to the central WG's LAN (inside) interface. Traffic between the two points of the V has to get all the way to that interface before it gets switched between the tunnels.

(2) The central WatchGuard's internal working routing table is missing some of the routes we've configured into it. I'm not sure if there's any way to fix that short of rebooting it.

 

[muckermucker]

Point 1 you mentioned isn't because it is a watchguard. All routers behave exactly the same way. Since a VPN connects LAN to LAN it will be the LAN interface that will receives the packets. So this is obvious that there must be a route to it. If there is no route to it it can't route it any further and will fail.