Site to Site VPN trouble

I am having trouble configuring a site to site VPN using Forefront TMG (MBE) and a couple of Draytek Routers. Our system is as follows:

Windows Essential Business Server (EBS2008) network in our head office. EBS2008 comes as 3 servers, one server is for Forefront TMG and I have it configured as a backend firewall. In front of this is a Draytek 3300V which has 3 broadband connections. Each has a public IP address.

Forefront TMG internal NIC =
Forefront TMG external NIC =
Draytek LAN IP

At the site office I have a Draytek 2110 which is dynamically assigned its public IP from the ISP. The internal network behind is 192.168.2.X

I have created a site to site VPN between these 2 draytek routers, it runs fine.

The draytek at the site office has modified its routing table and added 172.16.1.X via the VPN. Additionally, another setting has allowed me to also add 192.168.1.X also via this VPN
This then seems correct to me.

The draytek at the head office has also modified its routing table and added 192.168.2.X via the VPN. I have also added a static route in this device to route 192.168.1.X traffic back to the forefront gateway

So at this point from inside my head office LAN I can ping any device at the site office. From the site back to the head office, I can ping any device on the perimeter LAN 172.16.1.X which includes the forefront external NIC, When I try and ping the forefront Internal NIC I get a request time out. However when I watch the Forefront LOG, I can see the request come in. It does error out but at least I can see an incoming connection trying to be made and therefore I believe all the routing associated with the drayteks is correct and nothing else is needed. If I place a PC into this perimeter network (172.16.1.X) I can ping the internal NIC of forefront, I read somewhere this was made possible to check networking.

From here on I have followed this guide (and this is where I'm having the trouble)

From the web page above I having made the changes on Forefront as per item #4 a) steps i. through

iii. (here below is the TXT from the web page

4.       Choices with site to site VPN configurations (if applicable)
Site to Site VPNs are commonly used to provide connectivity to remote branches. The branch network is connected using a VPN tunnel into the VPN device (typically the front end firewall) – with EBS Security Server installed behind the existing front end firewall, you have 2 choices:
a.       A simple option is to continue to terminate  VPN at the front end firewall and configure EBS Security Server to route traffic between the branch networks and your internal network. The steps involved are:
i.      Create an “Address Range” object for each branch subnet.
ii.      Add a Network rule of type “route” and place it above default NAT rule.
iii.      Add an array access rule allowing traffic between branch network address range and

internal network .

After applying steps i. & ii. above, I can still ping any IP at the remote site from inside the head office network. However after applying step iii. I can no longer ping any device at the remote network from in side the head office. I can however ping any device at the remote office from the forefront machine itself (probably because the forefront PC gateway in the external NIC and not the internal NIC).

From within the head office network, although I can't ping any device any longer, I can pull up the logon page of the remote office draytek router, I can also pull up an IIS7 default page where IIS is installed on one of the servers down at the remote office. I cant connect to any of the servers with MSTSC or connect with UNC naming, they all just time out. All can still be done from the forefront server but no others inside the head office network.

The only other item I can think to include also is that the remote site is'nt actually a remote site. Its not apart of our local domain. The remote site is an SBS domain and its a separate company which I need to make a few connection to.

The above is all pretty long and drawn out, Ive done this to try and be as thorough as possible.

Thanks in advance for any assistance
Who is Participating?
BembiConnect With a Mentor CEOCommented:
You may observe the log a little bit.
The principle of TMG is, that for outgoing traffic, you need a protocol definition as well as an access roule, which allows the traffic.
For incomming traffic, you need a publishin rule, if it is over NAT, or a access rule, if it is routetd.

Also TMG applies the changes not neccessarily, when you hit accept, all alive connections use the old configuration until they are closed. And for some settings, the firewall services need a restart.

So, from the rule perspective, I can not see that the rule limits something. If you was allowed before, an additional rule does not limit it, it enhances the access. But the main difference may be, that in the first case of NAT, each response to an outgoing request is allowed, but with a route relation, you also need to allow the traffic to come back in.

So you may just try to define your rule FROM internal / branche TO internal / branche to allow it in both directions.

Also I would have the imagination, that you get a blocked log entry if you try to ping out. Means the ping response reaches the TMG, but TMG doesn't let it in.
JLW-MEAuthor Commented:
I am just waiting to get a replacement router at the main office installed. We noticed that after installing a second VPN connection to an alternative site that we were unable to ping between the 2 remote sites. We temporarily replaced the router at the head office one night and could then ping between the 2 remote sites using a different device, so at this stage I am thinking there is some sort of issue with the current 3300V installed at the head office.
Or just a routing issue..., means the ping makes a loop through another location....
Worried about phishing attacks?

90% of attacks start with a phish. It’s critical that IT admins and MSSPs have the right security in place to protect their end users from these phishing attacks. Check out our latest feature brief for tips and tricks to keep your employees off a hackers line!

JLW-MEAuthor Commented:
Hi Bembi,

Thanks for both of your comments, they are very much appreciated.

Just to simplify again, I would be greatful to hear your thoughts.

Using the microsoft guide in the link in my first comment, I cant get anything past the TMG after establishing a remote site to site VPN and terminating this at a front end draytek router.

I start to wonder if perhaps the problem isnt with TMG and therefore do the following.

create a second VPN to a different site

create route at both sites so anything to be send from one site to another site is sent via the head office.

With the existing draytek 3300V at the heah office I cant ping from one site to another

I replace the 3300V at head office with cheap temporary draytek, recreate the VPN's to each site and presto I can now ping from one site to another.

What I didnt do is while using the cheap router at head office, was to check if following the microsoft guide again would get my data past TMG from either of the remote sites. This of course is the true goal here

The whole thing is very simple and no alternative loop exists.

I will go back to the cheap router tonight, recreate the VPN's and do the whole 'microsoft guide for Site to Site VPN's where TMG is configured at a backend firewall. If it works then I think we can be pretty confident that the 3300V is the problem,...... or atleast how I have created the routes within this device is where the problem exists.

Thanks again !
This looks at least plausible.
As I know draytek, they use the same software base on more or less all routers. So you may compare the NAT settings and firewall defaults set on both routers as well as the VPN settings.
JLW-MEAuthor Commented:
Bembi,...... IT WORKS

My apologies to Forefront TMG for all the obscenities Ive shouted at it over the past month.

Now to go and kick the 3300V to death or alternatively study the manual and work out where I went wrong.

So to sum up.

Ive replaced the 3300V with a 3200 and recreated the VPN's.

I can now ping, ding & wing anything from/to anywhere based on the MS guide listed above (which was super simple)
;-) fine :-)
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.