# ARPing to ppp (pptpd interface)

## Luddetiger

I'm trying to get my internal network to know about a network behind a vpn. 

So, my router (linux) is connected to a pptpd vpn server where other clients connect to. 

The interface on the router is ppp0. 

On the the server clients with ip 10.10.6.200 - 244 is connected.

On my lan, where router is, the ips 10.10.6.1 - 199 is used.

So what I want is, if a computer tries to connect to say 10.10.6.201 the router should say that come through me and then it is directed correct to the ppp0 interface. 

I have tried shorewall for using their arp tables without success. And when I try to create custom arp rules with apring it says that ppp0 is not ARPable. 

What I have done with success is that I add route rules on all computers all the way and this works. But I have a NAS where I can't add route rules. And it would be nice to just have the router to add these kinds of rules.

Anyone that has some idea?

----------

## erik258

Luddetiger, 

   You have one big subnet for what appears to me as two logically seperate networks - first, the 200-244 network segment, and seconds, the 10.10.6.1-199 segment.    This makes routing difficult because simplistic UNIX routing simply specifies a default route, and subnet routes, but you need more than one route to the same subnet.  

  You could potentially use Advanced routing to do a thing like this.  Alternately, you could do what I do and set up a seperate subnet for your VPN that the defualt gateway can route to.  That way, computers not on the VPN will simply do what they normally do and send the packets to the default gateway, which can easily be configured (without shorewall/iptables, but only route) to send VPN subnet backets through ppp0.

----------

## Luddetiger

How do I recfconfigure the router to send traffic to a ppp0 device then? I have tried using a different subnet for the vpn clients. The problem with this is that I want the users using the vpn to work with the normal ip adresse for the lan. 

Whe I used different subnets I putted up routing rules on the vpnserver saying that route all 10.10.6.0/24 to ppp0 (the connection to the lan).  The vpn clients used 10.10.7.0 IP's. 

When I had this setup I hade an iptales rule on the firewall with this:

iptables -t nat -A POSTROUTING  -s 10.10.7.1 -d 10.10.6.0/24 -j SNAT --to 10.10.6.1

and then routing rule

route add -net 10.10.7.0/24 dev ppp0. This worked if I allso added a routing rule on all windwos servers (route add 10.10.7.0 mask 255.255.255.0 10.10.6.1).

But what you are saying is that I can have some rule on the router that will replace the routing rule on all servers? For me that did not work. I could se with tcpdump that the traffic arrived to correct server but without the routing rule on that computer it could not reply. What did I miss?

The reason Why I wanted all these to be on the same subnet is for the client. If I use different subnet they need to add to there client routing rules. At least I though if I used the same I could skip this since the vpn clients set a routing rule them selfs.

Do you have any idea?

----------

## erik258

I will have to get back to you on that, as even now I may well be late for work ; )  But I am going to try and remember to help.  If you don't hear from me today, send me a PM and another email in the inbox will be a good reminder.  

Until later!

----------

## Luddetiger

Okey. I have now changed the setup to more as you sad.

Using 10.10.7.0 for vpn clients and 10.10.6.0 for internal lan.

I added a routing rule for the lanserver to forward 10.10.7.0 to ppp0. Added an postourting rule to say that incoming connections from 10.10.7.1 should be forwarded to 10.10.6.1.

oute add -net 10.10.7.0/24 dev ppp0

iptables -t nat -A POSTROUTING -s 10.10.7.1 -d 10.10.6.0/24 -j SNAT --to 10.10.6.1 

On the vpnserver I added a routing rule saying that all traffic from 10.10.6.0 should go to ppp0 and 10.10.7.0 should go to ppp0.

route add -net 10.10.6.0/24 dev ppp0

route add -net 10.10.7.0/24 dev ppp0

Now everything works with communication back and forth. From clients to internal servers (whithout rules on each server) and from servers/computers on the lan to vpnclients.

Neet. I think my problem before was that I did not have control over the router. It was a dlink router and this gave me confusing problems. Now I have deployed my linuxserver/router/firewall I have more control and everything works. 

The only thing I have left is now how to configurate clients. Since they won't know that they should forward their 10.10.6.0 traffic through the VPN. Do you know how to workaround with this? I have clients with all different kinds of os (windows, mac, linux). And perferlilliy I do not want them to send all traffic through vpn. Just 10.10.6 and 10.10.7? Is it only thing left to add routing rules for all machines?

----edit----

I now tried the VPN from an external windows machine. And without any extra settings and not using the vpn as default root it routes 10.10.6 and 10.10.7 correct. I can access my computers on the network. It's like magic. I will have to test this some more.

----------

## erik258

 *Quote:*   

>  Is it only thing left to add routing rules for all machines? 

 

In a word, yes.  My configuration is somewhat different from yours, but there isn't too much VPN specific stuff below.  Mostly just routing between the internal network, the VPN, and beyond.  Unfortunately, you figured it out before I could explain it, but be that as it may, I may as well send through the message, for your consideration and posterity's.  

The internal network is on 192.168.1/24.  The default route is through 192.168.1.1.  There, routing tables look something like this:

```
dan@pascal ~ $ /sbin/route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo

0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
```

This is about as simple as routing tables get.  You can see the local broadcast domain at the top and the default route at the bottom.  

The VPN is on 192.168.3/24.  The VPN implementation, openVPN, pushes routes to 192.168.3/24 and 192.168.1/24 to the VPN clients when they connect.    The VPN routes look like this.   

Kernel IP routing table

```

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 tap0

192.168.1.0     192.168.3.1     255.255.255.0   UG    0      0        0 tap0

192.168.40.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1

74.36.112.0     0.0.0.0         255.255.240.0   U     0      0        0 eth0

127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo

0.0.0.0         74.36.112.1     0.0.0.0         UG    0      0        0 eth0
```

Above is shown the route to the VPN subnet, the remote private subnet at my house (.1/24), and the remote private network, 192.168.40/24.  The ISP routes are also shown; these routes are important to the configuration because the VPN client, whether or not directly connected to the isp like shown here, needs to be able to send VPN packets to the VPN server to the internet through it's default route.  

The Router is on both networks.  It serves the VPN (192.168.3.1), and routes traffic between the two 192.168/24 networks.  Since both locally and remotely the routing to and from 192.168/24 is done through 192.168.1.1, ie the router, only that router needs to know the specifics about how to get the packets to and from the VPN.  The Router needs a routing table like this:  

```
davey ~ # route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.100.0   192.168.3.3     255.255.255.0   UG    0      0        0 tap0

192.168.50.0    192.168.3.4     255.255.255.0   UG    0      0        0 tap0

192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 tap0

192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

192.168.40.0    192.168.3.2     255.255.255.0   UG    0      0        0 tap0

24.118.244.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1

127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo

0.0.0.0         24.118.244.1    0.0.0.0         UG    0      0        0 eth1
```

This is the most complex routing table, with 4 different Broadcast domains and 4 routes, including the default and loopback.  First, it contains routing information to its local broadcast domain, 192.168.1/24 at my house.  Second it contains the obligatory loopback route.  Third, it contains a default route.  This computer is also an internet gateway so it too has both a default route to the internet, and a broadcast domain to which that default router is also connected.  The VPN server would not have to be the internet gateway; it could just as easily be port-forwarded from the firewall.  

The rest of the routes pertain directly to the VPN.  192.168.3.0/24 is the final broadcast domain on the router, and sends its traffic through the VPN connections. 

Beyond the VPN

There are also 3 routes to the local subnets of the VPN clients.  By enabling IP forwarding on the VPN clients and routing to that domain on the vpn server / gateway, I have allowed these local subnets all to be merged into one large virtual network between my technologically advanced friends' houses and my own.  The routing configuration on the other two VPN clients is not shown, but you can see the route to the .40/24 subnet shown above in the VPN client example.  The .40/24 subnet clients will need to know how to route back to .1/24, and in this case that route is handled by their default route, which is also a VPN client.  In some cases, you may not be able to affect the routing of the other clients local to the VPN client; in these conditions, you can usually still get through to the immediate broadcast domain, albeit somewhat subversively, by running Network Address Translation on the VPN client and making trans-VPN traffic look like it's just traffic on the remote client's local network.  

other options

In some cases, people bridge the VPN and the local interfaces on the server to extend the local broadcast domain through to the VPN client as well.  This alternative is perhaps similar to your original configuration, in that all hosts stay on the default subnet.  However I have chosen to do it the other way.  I don't know too much about how the options compare, but I do know that the bridge would help alleviate the requirement for routing configurations, and that the routing VPN is evidently considered the better performer and scaler.  

enjoy your wonderful new VPN.  I, too, share in your sense of sheer joy when you see the route to your default boxes go through for that first wonderful time.  It gets even more fun if you can implement it at your friends' houses and communicate with them as if they were in the office next to yours, behind a single gateway, when they could be accoss the world.

----------

