I exchanged forum and email with you about this on the old forum server. Our users connect remotely via the Balance 380. We used PPTP, now L2TP, with the Windows built in client. Used it for many years. I am aware of the requirement for an inbound firewall rule to permit LAN client access (the vpn client shows as a LAN device).
I needed more than 254 LAN addresses, so I changed our LAN subnet from 255.255.255.0/24 to 255.255.254.0/23. Thats when the remote user access stopped working. When a remote client connects it is assigned a DHCP address, usually the lowest number available. See the example where the client received 198.42.230.10. The Balance 380 client table shows the same IP for that remote client.
I can’t ping any LAN device from the remote client. I can’t even ping the router’s own LAN address, which is 198.42.231.124. See attached example.
Everything works if I change the LAN subnet back to 255.255.255.0/24, but then of course I don’t have enough LAN addresses. I think that proves there are no issues with the client settings. I’ve tried this on various client devices.
I stopped worrying about this because I had another device on the LAN which could serve as a PPTP server. That is an older device that can’t supply the new requirements for Windows 10 VPN client authentication, so I am back to trying to connect with the Balance.
The last time we tried this, you duplicated the settings on a device in your office and said it worked. See attached, do you see something I’m doing wrong?
Could the problem be with using a Class C IP address with a mask of less than 24 bits? Looking at the first octet of the IP address:
Class A - 0 to 127, subnet can be 8-bit or greater
Class B - 128 to 191, subnet can be 16-bit or greater
Class C - 192 to 223, subnet can be 24-bit or greater
I don’t think 198.42.231.124/23 is a valid IP address.
MadDog, you’ll have to educate me on this. Our LAN was 198.42.231.0/24, with the router at .124. I have some devices in the range of 198.42.231.124 to 250 that are supplied by vendors so would be difficult to change. It doesn’t matter to me if the additional DHCP range is above or below the original range, as long as all the devices can communicate.
I can tell you this arrangement works fine for everything except the Balance remote user access. It works fine for the PepVPN links and all local devices.
1 Like
@Don_Ferrario, may I know the firmware version? Possible to do trace route from the L2TP/IPSec client to 198.42.231.124 and let me know the result?
1 Like
MadDog is right, your IP addressing is invalid. You shouldn’t use a class C address range with a /23 mask as you’ll get unexpected behaviour.
With your 3rd party vendor devices sticky on 192.42.231.0/24 range I would suggest the easiest thing to do would be to add a new VLAN for the remote access users.
Since FW 7 the balance can assign remote users IP addresses from a specified VLAN, so if you were to create a new /24 or even /23 VLAN and use that as addressing purely for remote access users you’ll have all the address space you need moving forwards.
1 Like
Also This IP Subnet Calculator is my goto tool when I’m planning address schemes - you might find it useful.
1 Like
I think you meant 198.42.230.0/23 and not 198.42.231.0/23.
I’m surprised the router configuration accepted it.
On some routers (e.g., cisco IOS) a specification of 198.42.231.0/23 would have automatically been translated to 198.42.230.0/23.
Martin: The IP Subnet calculator you gave me, only has /24 and higher. There is a link from that page to a CIDR calculator. I have no idea what CIDR means, but that page gives me options for larger IP ranges. I set it to 510 addresses, and it gave me exactly the scheme I am already using.
Bob - you may be right, but as you can see the router does accept it. Everything works fine except for remote access. I have no problem with local devices, no problem with PepVPN devices at our other locations. The problem is L2TP or PPTP with individual users.
I am stuck with 198.42.231.xxx, but I am not stock with going up or down from there. The additional ranges are all DHCP devices which are not reserved. If the IP range is the problem, I could use a scheme that include 198.42.232.xxx if that would help.
I am open to adding a VLAN for the remote users. I’d have to get the third party devices to open their firewalls to the VLAN but I can do that. I have some understanding what a VLAN is, but I’'ve never done it. I am using FW7, can you walk me through it? Or is there a Peplink video or instruction on it? I kind of understand the concept, but never did it.
@Don_Ferrario, possible to provide the traceroute result?
TK, here is a tracert from my remote PC. The VPN is connected via L2TP.
Windows IP Configuration
PPP adapter elmira:
Connection-specific DNS Suffix . :
IPv4 Address. . . . . . . . . . . : 198.42.230.1
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . :
Tracing route to 198.42.231.254 over a maximum of 30 hops
1 4 ms 6 ms 4 ms don [192.168.50.254]
2 37 ms 11 ms 10 ms 142.254.214.41
3 28 ms 31 ms 30 ms agg60.bnghnyaw02h.northeast.rr.com [24.58.208.221]
4 12 ms 13 ms 12 ms agg24.ithcnycy02r.northeast.rr.com [24.58.36.120]
5 * * * Request timed out.
6 * * * Request timed out.
7 * *
Did I see somewhere that with firmware 7.0, we can specify the DHCP addresses for L2TP or PPTP? If I could specify the assigned addresses to a range, that would fix this problem. Other routers we use allow this.
@Don_Ferrario, please find your provided traceroute result below.
If 192.168.50.254 is the gateway IP of your local network, then the access to 198.42.230.0/23 was local breakout (not going through L2TP/IPSec tunnel). This may due to the behavior of the Windows’s L2TP/IPSec client since your remote LAN subnet (198.42.230.0/23) is under public IP range.
Resolution
- Revamp your LAN subnet to use private IP instead of public IP range. This is recommended.
OR
- Please verify whether you have enabled Use default gateway on remote network. If this was enabled, you may need to check with Microsoft why traffic does not send into L2TP/IPSec tunnel by the L2TP/IPSec client.
Hope this helps.
