DrayTek UK Users' Community Forum
Help, Advice and Solutions from DrayTek Users
Vigor2925 - Allow Users on LAN5 to acess LAN1
- hornbyp
- User
-
- ptzulu
- Topic Author
- Offline
- New Member
-
16 Mar 2020 21:30 #8
by ptzulu
So, all Teleworkers (VPN Users) are on LAN 4, with 10.0.0.x , 255.255.255.0 range. Some manage to connect to router, some not, wich is a bummer..
The problem is ISP in my country (portugal) block the ISP provided router from changing the default DHCP range, wich sucks. In my house i have a second router to manage everything, and tested with another range, everything good. But when changing to 192.168.1.x range, all goes to hell
Can i say, in drytek, something like: all connections to 10.0.0.7 -> 192.168.1.7? I don't know if there is something like IP forwarding ahah but, what the hell...
Replied by ptzulu on topic Re: Vigor2925 - Allow Users on LAN5 to acess LAN1
hornbyp wrote:
ptzulu wrote:
The problem I'm having is, the company uses 192.168.1.x IP range (the most standard thing possible) and so the most people. So, when connecting through the VPN, the problem is the because they are on the same range of IPs, then can't connect to the Company IPs, let's say, NAS server, witch is 192.168.1.7.
If the exact sameIP address is in use on the user's LAN and the Company LAN, you would struggle to get it to work - but, hopefully this won't be the case. Ideally, you would want the home users to reconfigure their ISP-supplied routers to use a different DHCP range altogether, though I appreciate this may be difficult to organise.
If there isn'tan identical IP address involved, you may still be able to get this to work. Assuming the use of Draytek's Smart VPN Client,
have a look at "Step2. >> Setup >> "More" >> "Add more Routing ".
If you add (for example) "192.168.1.7 - 255.255.255.255 " to there, does it help?
(What you need to do, is tell the Client that it needs to 'route' to get to the target machine; that searching the local subnet with ARP, is not going to find it. )
If you're not using Smart VPN Client, you'd have to manually add a Route on the client, using something like "Route add 192.168.1.7 mask 255.255.255.255 192.168.1.x" (where x would change every time the VPN connects, which is awkward to say the least).
(Adding a new LAN to the 2925, with a totally new IP range, that is then specified in the 'Teleworker setup' for the VPN client might help in avoiding routing confusion.(It just defaults to "LAN1")
So, all Teleworkers (VPN Users) are on LAN 4, with 10.0.0.x , 255.255.255.0 range. Some manage to connect to router, some not, wich is a bummer..
The problem is ISP in my country (portugal) block the ISP provided router from changing the default DHCP range, wich sucks. In my house i have a second router to manage everything, and tested with another range, everything good. But when changing to 192.168.1.x range, all goes to hell
Can i say, in drytek, something like: all connections to 10.0.0.7 -> 192.168.1.7? I don't know if there is something like IP forwarding ahah but, what the hell...
Please Log in or Create an account to join the conversation.
- hornbyp
- User
-
17 Mar 2020 00:40 #9
by hornbyp
Perhaps some of them have been issued 192.168.1.7 by their own routers? Even if they can't change the DHCP range for the LAN, can they at least 'reserve' an IP address that doesn't clash ... such as 192.168.1.100, or whatever - anything you're not using at the other end.
Incidentally, that LAN4 range isn't 'standard
No, because the problem is at the client-end - the data never makes it to the Draytek.
What's happening is:-
The user connects to their LAN, and is given an IP address - let's say it is 192.168.1.3. Their PC accepts and configures this, along with a route 192.168.1.0 => 192.168.1.3 (for example). You can see this with the "Route print" command (it will say "Gateway is 'On-link'").
If they try and access 192.168.1.7, the client knows
This situation doesn't change when the VPN is connected - even though "Route Print" will show that they have acquired a 10.0.0.x address in addition to their original 192.168.1.3 (say).
The client needs to be told, that 192.168.1.7 is not local, but is at the other end of the VPN. The info. I gave above, about adding it to SmartVPN
Otherwise, you would have to manually add the 'route', once the VPN is established.
Say the VPN client receives 10.0.0.7 as its address :-
Obviously this is inconvenient! If you change their 'Teleworker' dial-in account, so that they receive a static
the "-p" option :-
(You can use the 'tracert -d 192.168.1.7' command to see where the traffic is actually going. (-d says don't waste time doing DNS lookup, that will probably fail)).
Replied by hornbyp on topic Re: Vigor2925 - Allow Users on LAN5 to acess LAN1
ptzulu wrote:
So, all Teleworkers (VPN Users) are on LAN 4, with 10.0.0.x , 255.255.255.0 range. Some manage to connect to router, some not, which is a bummer...
Perhaps some of them have been issued 192.168.1.7 by their own routers? Even if they can't change the DHCP range for the LAN, can they at least 'reserve' an IP address that doesn't clash ... such as 192.168.1.100, or whatever - anything you're not using at the other end.
Incidentally, that LAN4 range isn't 'standard
and he wrote:
Can i say, in draytek, something like: all connections to 10.0.0.7 -> 192.168.1.7? I don't know if there is something like IP forwarding ahah but, what the hell...
No, because the problem is at the client-end - the data never makes it to the Draytek.
What's happening is:-
The user connects to their LAN, and is given an IP address - let's say it is 192.168.1.3. Their PC accepts and configures this, along with a route 192.168.1.0 => 192.168.1.3 (for example). You can see this with the "Route print" command (it will say "Gateway is 'On-link'").
If they try and access 192.168.1.7, the client knows
This situation doesn't change when the VPN is connected - even though "Route Print" will show that they have acquired a 10.0.0.x address in addition to their original 192.168.1.3 (say).
The client needs to be told, that 192.168.1.7 is not local, but is at the other end of the VPN. The info. I gave above, about adding it to SmartVPN
Otherwise, you would have to manually add the 'route', once the VPN is established.
Say the VPN client receives 10.0.0.7 as its address :-
Code:
C:\>route add 192.168.1.7 mask 255.255.255.255 10.0.0.7
OK!
Obviously this is inconvenient! If you change their 'Teleworker' dial-in account, so that they receive a static
the "-p" option :-
Code:
C:\>route add -p 192.168.1.7 mask 255.255.255.255 10.0.0.7
OK!
(You can use the 'tracert -d 192.168.1.7' command to see where the traffic is actually going. (-d says don't waste time doing DNS lookup, that will probably fail)).
Please Log in or Create an account to join the conversation.
- ptzulu
- Topic Author
- Offline
- New Member
-
- hornbyp
- User
-
22 Mar 2020 01:36 #11
by hornbyp
I'm sure it's technically
I'm sure the easiest approach, would be to try and add that routing information to SmartVPN ... have you tried it? ... did it fail?
As another thought ... you could possibly
You've not said what sort of server it is, but in Windows, you can do it fairly easily (without needing an actual hardware adaptor) :-
Make sure that the application running on the server is bound
(You may also need to prevent
Replied by hornbyp on topic Re: Vigor2925 - Allow Users on LAN5 to acess LAN1
ptzulu wrote:
What i wanted to do, if its possible, is:
...
...
That would mean, if it's even possible, that every teleworker could use the standard local ip range of their own routers, and, when tried to connect to the NAS via VPN, via 10.0.0.7, the draytek would then redirect to 192.168.1.7 IP.
Trying the same analogy for port forwarding, when, public port is 55, and local port is 1234...
I'm sure it's technically
I'm sure the easiest approach, would be to try and add that routing information to SmartVPN ... have you tried it? ... did it fail?
As another thought ... you could possibly
You've not said what sort of server it is, but in Windows, you can do it fairly easily (without needing an actual hardware adaptor) :-
Make sure that the application running on the server is bound
(You may also need to prevent
Please Log in or Create an account to join the conversation.
- hornbyp
- User
-