Score:0

How to Set up Site-To-Site VPN using a VPN client as a gateway

mx flag

I have a remote L2TP VPN which my synology diskstation connects to.

I would like to use my synology diskstation then as a gateway to get to hosts on this VPN.

The VPN assigns addresses in the 10.0.0.1 space.

So I tried the following static route on my local router (192.168.1.1).

The address of my diskstation, which I assume will serve as the gateway to the VPN is, on my local network: 192.168.1.15

So I tried the following static route:

Destination: 10.0.1.0 Subnet Mask: 255.255.255.0 Gateway: 192.168.1.15

Now when I try to ping an address on the VPN, I get the following:

ping 10.0.1.178
Request timeout for icmp_seq 0
92 bytes from linksys.someinternet.com (192.168.1.1): Redirect Host(New addr: 192.168.1.15)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 9474   0 0000  3f  01 19cd 192.168.1.14  10.0.1.178

However, I don't understand the information provided here. I can't seem to actually SSH to 10.0.1.178 so I suspect the information here is informative of a misconfiguration, but I don't see what.

Similarly, if I try a trace route, I get the following:

traceroute to 10.0.1.178 (10.0.1.178), 64 hops max, 52 byte packets
 1  linksys18923 (192.168.1.1)  1.252 ms  0.611 ms  0.545 ms
 2  192.168.1.15 (192.168.1.15)  0.941 ms  0.857 ms  0.876 ms
 3  linksys18923 (192.168.1.1)  1.156 ms  1.190 ms  1.268 ms
 4  192.168.1.15 (192.168.1.15)  1.176 ms  1.210 ms  1.155 ms

So it appears that the packet goes back and forth from my gateway and the router. It looks like there is some incorrect closed loop present but I don't see where my misconfiguration is.

Is my static route correct?

Score:0
vn flag

First, you need to know how a router works. A router must be at least in two subnets to do the job. You say you want the machine on 192.168.1.15 as the router. Then it must be in the VPN net 10.0.0.0/24 as well (say 10.0.0.a) to be able to be the medium. Any other machine on subnet 192.168.1.0/24 should now set 192.168.1.15 as its router when visiting subnet 10.0.0.0/24; and any other machine on VPN net 10.0.0.0/24 should now set the 10.0.0.a as the router for 192.168.1.0/24.

That is not enough though, you should also enable the routing function of the router like ipv4_forward=1. Thus it will route the traffic for another machine rather than throw it away.

Score:0
mx flag

From what I gather, packets were being sent to my VPN client (my synology diskstation) and then having no understanding of where to go from there, were bouncing back.

That's my explanation for this behavior here:

traceroute to 10.0.1.178 (10.0.1.178), 64 hops max, 52 byte packets
 1  linksys18923 (192.168.1.1)  1.252 ms  0.611 ms  0.545 ms
 2  192.168.1.15 (192.168.1.15)  0.941 ms  0.857 ms  0.876 ms
 3  linksys18923 (192.168.1.1)  1.156 ms  1.190 ms  1.268 ms
 4  192.168.1.15 (192.168.1.15)  1.176 ms  1.210 ms  1.155 ms

So what I did was add a static route on my synology diskstation itself, to redirect 10.0.1.0 traffic to the VPN gateway address provided by the VPN server.

In short, it looks like I needed two static routes:

  1. A static route on my router to direct 10.0.1.0 traffic to my diskstation
  2. A static route on my diskstation (VPN client) to direct 10.0.1.0 traffic to my VPNs gateway address (10.0.1.145)

The traceroute to a device behind the VPN looks like this now:

traceroute 10.0.1.178
traceroute to 10.0.1.178 (10.0.1.178), 64 hops max, 52 byte packets
 1  linksys18923 (192.168.1.1)  0.887 ms  0.520 ms  0.450 ms
 2  192.168.1.15 (192.168.1.15)  0.790 ms  0.790 ms  0.729 ms
 3  10.0.1.145 (10.0.1.145)  30.790 ms  27.511 ms  26.783 ms
 4  10.0.1.178 (10.0.1.178)  643.955 ms  37.126 ms  29.481 ms

Which in words is: router -> diskstation (vpn client) -> VPN gateway -> device behind the VPN

Since I don't see any traffic making it onto public IP addresses I am considering this fixed.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.