Solved

Our Site to Site VPN Only works in 1 direction.

Posted on 2013-12-10
3
545 Views
Last Modified: 2014-06-16
Draytek
The VPN establishes fine, but does not work properly.

From the Main Site I can access the Network of the Branch Site fine.

The Branch Site cannot access the Network of the Main Site.

The Tracert when run on pc on the branch site, makes it to the router then times out.

The Tracert when run from the Router itself works fine.

Traceroute to 192.168.100.20, 30 hops max through WAN2 protocol ICMP
  1  192.168.100.100       50 ms
  2  xxx.40.127.xxx        50 ms

However from a PC in the branch site I cannot ping 192.168.100.20.

Very strange, any ideas?


Main Site Settings ( Draytec Vigor 2860)
------------------------------------------------------
Has a Static IP from BT Infinity.

Call Direction  Dial-in

3. Dial-In Settings
Allowed Dial-In Type PPTP
Username 1
Password *************

5. TCP/IP Network Settings
MY WAN IP 0.0.0.0
Remote Gateway IP 0.0.0.0
Remote Mask 255.255.255.0
Local Network IP 192.168.100.0
Local Network Mask 255.255.255.0

RIP Direction TX/RX Both ( tried with it off too)
From first subnet to remote network off.

Branch Site Settings (Draytec 2850)
-------------------------------------------------------

Call Direction Dial-Out
Always on Ticked
VPN Dial out Though WAN 2 only ( PPOE BT Modem BT Infinity)
Netbios Naming packet Pass
Muliticast Via VPN Pass( tested with Block too)

2, Dial Out Settings
PPTP
Server IP Host Name for VPN
xxx.40.127.*** ( Main office static IP)
Username 1
Password ( Matches Main Office)

My WAN IP 0.0.0.0
Remote Gateway IP 0.0.0.0
Remote Network IP 192.168.100.0
Remote Mask 255.255.255.0
Local IP 192.168.1.0
Local Mask 255.255.255.0

RIP Direction TX/RX Both
Route

Branch site ( this looks ok!)

Routing Table
Key: C - connected, S - static, R - RIP, * - default, ~ - private
*            0.0.0.0/ 0.0.0.0          via xxxx.32.142.xxx    WAN2
C~   192.168.100.100/ 255.255.255.255  directly connected   VPN-2
S~     192.168.100.0/ 255.255.255.0    via 192.168.100.100  VPN-2
S      xxx.169.29.xxx/ 255.255.255.255  via xxx.169.29.xxx     WAN2
C        192.168.0.0/ 255.255.255.0    directly connected    LAN1
C~       192.168.1.0/ 255.255.255.0    directly connected    LAN1
C~       192.168.2.0/ 255.255.255.0    directly connected    LAN2
*     xxx.32.142.xxx/ 255.255.255.255  via xxx.32.142.xxx    WAN2
0
Comment
Question by:loughtec
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
3 Comments
 
LVL 78

Accepted Solution

by:
arnold earned 500 total points
ID: 39710264
The reflection of the public IP suggests that there is an issue on the VPN setup.
Your VPN setup because of the use of the 192.168.100.100/32 points to a remote type of VPN rather than a site to site.PPTP is a one way VPN.
0
 
LVL 26

Expert Comment

by:Fred Marshall
ID: 39710474
If the VPN device is not also the internet gateway on each side then consider this:

A packet from subnet A destined for subnet B has to be directed to the site A VPN device.
This is usually done with a route in the site A internet gateway.

The same thing applies for packets from subnet B:
A packet from subnet B destined for subnet A has to be directed to the site A VPN device.
This is usually done with a route in the site B internet gateway.

So, if this is true at only one end then this can happen:

A packet from subnet B destined for subnet A:
- first goes to the subnet B internet gateway
- it is routed to the subnet B VPN device
- it arrives at the subnet A VPN device
- it goes *directly* to the destination IP address without hitting the subnet A gateway.
- return packets (there are *always* return packets) will go to the subnet A gateway.
- the subnet A gateway should route them to the subnet A VPN device.
- from there, they should get to subnet B OK.

One thing that can mess this up is if the internet gateway device is using something like stateful packet filtering on the LAN interface(s).  Since it's not aware of the incoming packets, it will not forward the return packets.  Often this has to be turned off.

So, depending on how things are set up and which manufacturer's products are involved, this may be the sort of thing that you're seeing.
0

Featured Post

NFR key for Veeam Backup for Microsoft Office 365

Veeam is happy to provide a free NFR license (for 1 year, up to 10 users). This license allows for the non‑production use of Veeam Backup for Microsoft Office 365 in your home lab without any feature limitations.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

In the world of WAN, QoS is a pretty important topic for most, if not all, networks. Some WAN technologies have QoS mechanisms built in, but others, such as some L2 WAN's, don't have QoS control in the provider cloud.
Let’s list some of the technologies that enable smooth teleworking. 
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…

737 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question