...
> > The problem is not on the client or the server. There is no return
> > route for the 10.8.0.0 network from your target machine back to your
> > client. You can either add a static route to your router on the LAN
> > side pointing 10.8.0.0 255.255.255.0 back to your vpn server machine
...
> First of, thank you for your answer. ;)
>
> Well, I've added a static route on the router.
> Unfortunately, I still can't access the server files.
> The point is, I'm setting up this VPN for a small business;
> I'm not familiar
> with the gear yet, so I hope I did well when I added the
> route on the router.
>
> Here's what I added: (the router is a Netgear FVS124G)
> Destination IP @: 10.8.0.0
> Subnet mask: 255.255.255.0
> Interface : LAN
> Gateway IP @ : server LAN IP @
>
> Oh and I forgot to mention something this morning: I have the
> following message
> in the server log:
>
> client/xxx.xxx.xxx.xxx:2593 MULTI: bad source address from client
> [yyy.yyy.yyy.yyy], packet dropped
>
> Where xxx.xxx.xxx.xxx is the client public IP @
> and yyy.yyy.yyy.yyy is the client LAN IP @.
>
> A routing VPN fits better with the business needs, that's why
> I chose it.
...
You're welcome. Truthfully I should not make so assertive statement as
'this is what your problem is' when I don't have enough familiarity to
give such a strong statement, however this problem is so common that I
feel fairly confident that is what it is.
Oh, and is ip forwarding turned on your vpn server. Whoops that's a
common one too.
It's mildly tricky to diagnose. I can't speak for the particular router
you are using. It may help to have access to the server side machines
while testing it out. Tracert can be helpful in seeing where the
packets go, and croak, to figure out what needs fixin'.
In this scenario, the path from the remote client to the smb server is
different than the route back from the smb server to the remote client.
Pretending this is your setup:
Local lan: 192.168.200.0/24
Router: 192.168.200.1
Vpn server: 192.168.200.50, 10.8.0.1
Smb server: 192.168.200.60
Remote client: 10.8.0.30
The route from the remote client to the smb server would be:
Out of client, into vpn server
Out of vpn server, into smb server
But the route back to the client would be:
Out of smb server into default gateway (presumably the router)
Out of default gateway into vpn server
Out of vpn server into remote client.
i.e. the return route takes an extra hop at the router (default
gateway). This because, although the vpn server knows about the
10.8.0.0/24 subnet, the rest of the machines on the lan do not, and they
send those to the default gateway. The default gateway doesn't know
about 10.8.0.0/24, unless you set the static route for that subnet back
to the vpn server, who will then route them appropriately out the vpn
interface.
(OK, you probably understood this already)
You could try some things:
* Add a static route directly on the smb server:
route add 18.8.0.0 mask 255.255.255.0 192.168.200.50
(or whatever works for your OS)
this will only work for that one machine though
* add that same route to your default gateway machine (router). You
believe you did this already, so we should test.
If you can access the smb server, tracert from that machine to, say,
10.8.0.30. It doesn't really matter if the client is connected, the
important thing is to see that the packet at least gets to the vpn
server at 192.168.200.50 before dying. If it doesn't get there,
question your static route on the router. If it does, then the vpn
router should forward the packet onto the client (when connected), if
you do have ip forwarding enabled (please double-check I should have
mentioned before).
-Dave
|