Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've recently set up a VPN for my home (using an Ubuntu host and PPTP, see links at bottom) so I have access to my servers where ever I am, and so far it's worked how I wanted it to. I've got it set up that any remote computer connecting via VPN can get in and access any computer on the network. The problem I'm having is that the computer that is connected via VPN cannot be accessed by any computers on the inside of the network.

So, lets say Computer 1 has an IP of and is physically on the network, and Computer 2 has an IP of [correction, it's not (everything is on the same subnet)] and is connected via VPN.

Computer 2 can ping Computer 1 and access the Windows shares, but for some reason Computer 1 can't ping Computer 2 or access tho Windows shares.

Admittedly, it does work for what I originally wanted it for (computer 2 being able to access the network), but I can see some potential uses if it appeared on the network the same as any other computer, so it could ping every other computer (inc other computers connected via VPN), and every other computer could ping it.

Any suggestions on what I can do to fix this? Is it just simply the way that VPN works, and there's not actually a problem with it?

I used the following guide: . I also needed to use a bit from: where I needed to open "/etc/sysctl.conf" and uncomment the line "#net.ipv4.conf.default.forwarding=1"

Edit I've done a traceroute on both Computer 1 to Computer 2, and vice versa.

Computer 1 to Computer 2: Reaches the PPTP server as first hop, but them times out.

Computer 2 to Computer 1: Reaches PPTP server as first hop. Reaches Computer 1 as second hop.

share|improve this question

that pinging is working is interesting. it probably shouldn't be.

the likely problem is routing. if you're using 192.168.0.x addresses internally, and 192.168.1.x addresses for the VPN, the computers inside dont know how to talk to the VPN computers. for any addresses outside the 192.168.0 subnet, they forward the request to your router (absent better instructions). since the VpN machines arent in that /24 subnet, theyre going to your default route ( and promptly being dropped by your router as it doesnt know what to do with them either.

there are two ways to solve this: set manual routes on all internal computers, or set a single static persistent route in your router.

the easy solution, if your router will allow, is to add a route to its routing table. methods and support will vary based on your router, but the gist is you want all traffic going to (or netmask, same thing) to be destined for where xxx is the internal address of your VPN server.

if you need more detail, or want to post your specific router for better instructions, i/we will try to help more.

edit: one other option would be to change your pptpd config to give out 192.168.0.x addresses (make sure theyre in a range outside what your internal router's dhcp server assigns). then the route shouldnt be needed since everything will be in the same broadcast domain (the default.forwarding=1 line effecitvely turns your server into a giant switch).

share|improve this answer
I just noticed a typo, I'm using 192.168.0.X for everything, not .1.x. I'll have a look at the routing settings on my router. Unfortunately only a home router (D-Link DI624S) so settings are limited, but I think I'll try running WireShark on the network and see where the packets are being sent to. Thanks for the comment. – joshhendo Aug 19 '11 at 4:45
I've just looked into it further. The remote computer has a subnet mask for (which is obviously wrong) and no default gateway set. I'll look into fixing this and see if it fixes the problem. – joshhendo Aug 19 '11 at 4:57
well crap then. You might look here:, specifically at the proxyarp stuff. That actually makes more sense, since you need the server to respond to the ARP requests for the remotely connected clients in order for the packet forwarding to work (doh! forgot about that when I was typing all that stuff above.) – peelman Aug 19 '11 at 13:53

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.