x550e WatchGuard VPN BOVPN Initial Setup

In your WatchGuard Policy Manager:
1. Create a new Gateway
2. Put in your PreShared Key and add your endpoints. Your Local gateway is your external IP and the remote gateway is the other external IP.
3. Everything else take the defaults
4. Back in the Policy Manager, Create a new Tunnel
5. Choose the gateway you just created
6. Put in your local address in slash notation with the last octet being 0
    Example 192.168.1.0/24 for the local and 192.168.2.0/24 for the remote
7. The check mark at the bottom will auto create the policies you need.
8. Save the config to your Firebox

On your NetGear:
9. Setup an IPSec tunnel with the same preshared key as above.
10. Test by pinging the other router and then try passing other traffic

You may end up needing to enable broadcast routing over the tunnel and/or multi-cast over the tunnel. That will depend on a number of factors about your setup and usage.

Few questions:
1. Which version of WG software you are running and which model of WG device you got.
2. You wish to allow remote users access to resources through VPN or you wish to allow a remote site connectivity to resources behind your firewall.
3. Depending on 2; if remote users then you would configure PPTP [called RUVPN in WG; windows based client] or IPSec [called MUVPN in WG; specific IPSec client to be installed on every remote host]; or site-to-site then branch office VPN tunnel [BOVPN].
4. If the netgear router is sitting behind WG and is on the trust network; you would not be able to test remote user VPN connecitity; you should have netgear on some other internet connection to test VPN [be it BOVP or RUVP or MUVPN].

Please provide details so we can assist further.

Thank you.

1) Fireware 10.2.10  - x550e (rack of servers at a datacentre).
2) We intend to allow a client to connect to one of our servers, on certain ports only (MSSQL) only, via VPN.
3) We initially setup a MUVPN for them and they replied asking for a site-to-site IPSEC VPN.
4) The Netgear is in our office, a seperate location/network entirely from the datacentre.
Note: As far as I'm aware, they will not be using a WG product their end.

As detailed in the first post by washburnma; please follow the instructions; additionally look at link below:
http://watchguard.custhelp.com/app/answers/detail/a_id/16/kw/BOVPN

Please update if you need more details.

Thank you.

Thanks for the help so far guys.
I've setup a Gateway Endpoint as instructed. As for the "gateway ID", is that too set to the external IP of our office?
For the local and remote network IPs in the tunnel setup, I've got 192.168.1.0/24 for local, our office network, but for the remote, does that need to be the network IP for the VLAN that the server lies on?
The rules were created automatically as described and I've not touched them.
Netgear isn't connecting for whatever reason, and the really helpful logs just show this;
initiating Main Mode
STATE_MAIN_I1: retransmission; will wait 20s for response
max number of retransmissions (4861780) reached .  No response (or no acceptable response) to our first IKE message


netgear-grab.jpg

Just noticed that the Netgear defaults to Group 2 and the WG is on Group 1. So I've changed the Netgear to 1, and now the log shows something different.....so close now I'm sure....  :-)
Sat, 2000-01-01 00:01:01 - [Datacentre]added connection description "Datacentre"
Sat, 2000-01-01 00:01:01 - adding interface ipsec0/nas0 officeIP:500
Tue, 2010-11-09 12:40:07 - [Datacentre] initiating Main Mode
Tue, 2010-11-09 12:40:07 - [Datacentre] ISAKMP SA established
Tue, 2010-11-09 12:40:07 - [Datacentre] Dead Peer Detection (RFC 3706): enabled
Tue, 2010-11-09 12:40:17 - [Datacentre] STATE_QUICK_I1: retransmission; will wait 20s for response
Tue, 2010-11-09 12:40:37 - [Datacentre] STATE_QUICK_I1: retransmission; will wait 40s for response
Tue, 2010-11-09 12:40:47 - [Datacentre] STATE_QUICK_I1: retransmission; will wait 20s for response
Tue, 2010-11-09 12:41:07 - [Datacentre] STATE_QUICK_I1: retransmission; will wait 40s for response
Tue, 2010-11-09 12:41:17 - [Datacentre] max number of retransmissions (4861988) reached .  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
 

If any screenshots of any particual settings would be of use, please shout.

The WatchGuard should have the remote LAN IP of the VLAN you want to have the VPN tunnel pass traffic with. So I believe yes, the VLAN your server is on.

From looking at the screenshot of the NetGear, I believe the default algorithims are different on the WatchGuard. Check under the Tunnel and Gateway settings in the WatchGuard and compare to the NetGear.

I did not see in the NetGear screen shot where the remote external IP address is set. There should be something under "Remote Identity Type and Data" unless that is on a seperate screen.

Is that not "Remote VPN Endpoint" at the top of the settings?  It's currently set to use a FQDN, (blacked out).

I see now. If you are using the domain name to identify the remote site, does an nslookup of the domain name come back with the same IP as the remote IP in the WatchGuard?

Change the Remote VPN endpoint to IP Address on Netgear; and specify WG public IP there and then update [assumption: your WG has public IP on external interface].

Thank you.

<:>I have changed the VPN Enpoint to Fixed IP address on the Netgear instead of fully qualified domain name. Like before it seems to connect....and then times out?

Wed, 2010-11-10 08:59:00 - [Datacentre]added connection description "Datacentre"
Wed, 2010-11-10 08:59:00 - adding interface ipsec0/nas0 office public IP:500
Wed, 2010-11-10 08:59:15 - [Datacentre] initiating Main Mode
Wed, 2010-11-10 08:59:16 - [Datacentre] ISAKMP SA established
Wed, 2010-11-10 08:59:16 - [Datacentre] Dead Peer Detection (RFC 3706): enabled
Wed, 2010-11-10 08:59:26 - [Datacentre] STATE_QUICK_I1: retransmission; will wait 20s for response
Wed, 2010-11-10 08:59:46 - [Datacentre] STATE_QUICK_I1: retransmission; will wait 40s for response
Wed, 2010-11-10 09:00:26 - [Datacentre] max number of retransmissions (4861988) reached .  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
 

Can you check that dead peer detection [DPD] is present and enabled on both ends; otherwise disable DPD and check. Also, post sanitized screenshots of both Netgear and WG VPN configuration.

Thank you.

There is no visible setting for that in the Netgear, but when I disable it on the WG, this occurs;
 

Wed, 2010-11-10 11:15:58 - [Datacentre] initiating Main Mode
Wed, 2010-11-10 11:15:58 - [Datacentre] ISAKMP SA established
Wed, 2010-11-10 11:15:58 - [Datacentre] Dead Peer Detection (RFC 3706): not enabled because peer did not advertise it
Wed, 2010-11-10 11:16:08 - [Datacentre] STATE_QUICK_I1: retransmission; will wait 20s for response
Wed, 2010-11-10 11:16:28 - [Datacentre] STATE_QUICK_I1: retransmission; will wait 40s for response
Wed, 2010-11-10 11:17:08 - [Datacentre] max number of retransmissions (4861988) reached .  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
 
Please find attachments are requested.

edit-gateway-Capture.JPG
edit-gateway-endpoints-Capture.JPG
edit-gateway-phase1-Capture.JPG
edit-tunnel-Capture.JPG
edit-tunnel-phase2-Capture.JPG
edit-tunnel-route-Capture.JPG
Netgear-Capture.JPG

On Netgear:
Change remote to subnet IP and specify 192.168.3.0/24 [if this is not what you wish then change on WG to single IP for local subnet under tunnel addresses].

If the tunnel still does not come up; then in WG under tunnel settings, Phase 2 Settings; IPSec proposals; change from ESP-AES-SHA1 to SHA1-3DES.

Please implement and update.

Thank you.

I think these screenshots tell the story  :-)  THANKS A LOT!
I am 99.9% there now....just need to get my head around the way that the policies now work. If I were to want to RDP to an existing server, say 192.168.3.100 from the office 192.168.1.0/24, what would be the syntax of the policy please?
I've still only got the WG generated ones (in the picture) thus far.

hooray-.jpg
WG-hooray-.jpg
bovpn-policy.jpg

The tunnel is up; only strange thing is, WG side reports sent as zero bytes; policy on WG all look good [generic policies are ANY policies allowing traffic on all ports/protocols].
Am assuming that the machines behind WG are using WG internal IP as default gateway and you do not have any other device on the network with 192.168.1.0/24 subnet so that packets are getting routed over that device instead of VPN tunnel.

If you were to do:
traceroute 192.168.1.1
on any machine behind WG; it should send packet to WG internal IP for further routing.

Please check and update.

Thank you.

The servers all have internal addresses. For example the machine I ran this tracert on is 192.168.3.105 with g/w 192.168.3.1.
There is a VLAN though, 192.168.1.1/24, so as I understand, all traffic back is being routed to that and not the office? Would that mean I need to change the network IP in the office to a network NOT being used on the WG?
 

tracert-wg.JPG

As in the screenshot; the gateway for traffic is 192.168.1.1 [something on LAN]; rather than WG internal IP; if possible set Netgear to say 192.168.5.0/24 [something which is not used on your internal network behind WG at all]; then the traffic should get routed over VPN.

Thank you.

Thanks!
Just before I do this, the local IP range I have in the tunnel (192.168.3.0/24) also exists at the datacentre. I chose this range because this is the network I wish to have access to. Is this incorrect, should it again be another network range that is not used?
Cheers.

And any access to anything is entirely configure through the policies as per usual..........?

As you wish to allow access to subnet 192.168.3.0/24 behind WG from another location through IPSec site-to-site VPN tunnel; yes, you would have local IP range as 192.168.3.0/24 on WG [if there are more subnets, then you should add multiple tunnels on the same gateway].

Yes, by default ANY service allows traffic on ALL ports/protocols.

Thank you.

Arrrrrgh, must be so close to sorting this. Now a tracert goes to the local gateway 192.168.3.1 but not further it seems.
There are sent bytes on the WG. A tracert from the office to 192.168.3.1 does not change the received bytes however  :-(
I did mentioned earlier I think, but there is a global VPN setting for
[   ]  Enable IPSec Pass-through
which is currently unticked.

FSM.jpg
new-tracert.JPG

Can you check if you were to tracert from Netgear side; the packets are following correct path back; if no, please make amendments.

Also, if needed on Netgear you have policies to allow traffic in/out of the tunnel.

Thank you.

Here is the tracert from the office side. There is no direct option for allowing traffic through VPN. And by default, these Netgears allow ALL outgoing traffic unless specified otherwise.

office-tracert.jpg

Many thanks for all your help. Got there in the end.

Happy to be of assistance.