Strange Issue with Multi Subnet VPN
Hi,
Firewall: M270
Fireware: 12.7.2.B655803
Hope someone can offer some advice as I'm stuck with an odd error with my site to site VPN.
I have it working fine, and am trying to alter the subnet by expanding it from a /23 to a /20 on the tunnels (The network config is already /20). But as soon as I make the change I can't get any traffic into the Firebox form the other side (VMWare Edge). If I flip it back to a /23 it works again fine. When I check the VPN Diagnostic report I can see this:
tunnel route#2(10.60.0.0/23<->10.0.0.0/24) - Established Incoming VPN traffic was detected for this tunnel after the diagnostic report started. Outgoing VPN traffic was detected for this tunnel after the diagnostic report started. The firewall policy "BOVPN-Allow.out-00" is matched for the outgoing traffic. The incoming traffic for tunnel route (10.0.0.0/24<->10.60.0.0/23) is denied by firewall policy (Inconclusive). Recommendation: Check your firewall policy configuration.
Anyone any ideas what tis means? I have tried removing all the tunnels, saving config, then reapplying. I have also removed the BOVPN policy and re-added it - no difference.
Weirdly I can ping from the Firebox side to the VMWare side, but not the other way.
I can't get any reporting from the VMWare side unfortunately, but wanted to rule out anything WatchGuard side first.
Comments
Do you have a BOVPN-Allow.in policy?
Are you changing the VMWare end to /20 when you change the M270 to /20?
You can turn on diagnostic logging for IKE which may show something to help:
In WSM Policy Manager: Setup -> Logging -> Diagnostic Log Level -> VPN -> IKE
In the Web UI: System -> Logging -> Settings
Set the slider to Information or higher
Besides Diagnostic Logging, you have 2 other options when the session is trying to connect, and you should see something to help understand this.
1) Web UI -> System Status -> VPN Statistics, click the Debug button
2) in FSM -> Traffic Monitor -> right click -> Diagnostic Tasks -> VPN tab
Thanks for the reply, Bruce.
Yes, I have a BOVPN-Allow.in policy. I recreated it as well when I unticked, saved, then re-ticked and saved again.
Yes, I alter both sides at the same time and then rekey.
The odd thing is that the tunnel does link up and I can see it in the WSM manager.
I can even ping through the tunnel from my remote MUVPN session when I change it to a /20. The IP range that the MUVPN uses is not in the /23, which is one of the reasons I am changing it. When I put it back to the /23 the MUVPN connection doesn't ping, which is correct.
So I know it's working to an extent - which is my confusion.
What's weird is I see no packets incoming at all from the other side in the WSM logs - including a ping generated from the other side.
It is possible that it could be the other end? It allows in again when I change it all back to /23. Maybe it's the VMWare Edge device that isn't updating correctly?
I just wanted to exhaust any possible issues on the WatchGuard side first.
Could well be the other end which is causing the issue.
If the goal is to allow the MUVPN subnet access to the other end, one option is to add the MUVPN subnet as a 2nd entry in the Tunnel settings instead of switching from a /23 to a /20 subnet.
That's certainly worth a test to see if it takes. Thanks.
To complete this discussion: the issue was with the Edge device at the other end. It need to be rebooted after the changes were made for the VPN configuration to commit properly. Nothing wrong with the Firebox.
FYI for future users:
I just had same/similar issue. Initially I was just adding a second ISP to a VPN and the second endpoint was showing timeout.
VPN diagnostics were showing the same messages:
"VPN traffic was detected for this tunnel"
"firewall policy is matched"
"The incoming traffic for tunnel route is denied by firewall policy. Recommendation: Check your firewall policy configuration."
After a bit (and on a whim) I took both boxes out of Fully managed mode and found one of them had not saved the latest changes. Applied changes again (in basic managed) and all is working.