2k VPN issues same ip to client and server, how to stop?

[LSUECE21]

I have a server running win2k sbs with two NICs. One dedicated to LAN and the other set up to be reached by public ip. DHCP is handled by a linksys router. Generally when i connect to the vpn the first connection yields a client ip same as the server ip for the vpn and doesn't allow me access to anything on the network, but does allow connection. If i create a 2nd connection then i can close the first and have access. I need to find a way to keep the server from issuing its own ip to a client.

Thanks for any help

Dustin

 

[bcastner]

Set the base address of the Linksys router to 192.168.2.1 instead of its default 192.168.1.1; or use the 10.0.x.x base address, which is usually easier for remote connections.

I would encourage you to set a static IP for your server outside the DHCP range of the Linksys router. For example, if you use 10.0.x.x Class B addressing:

router LAN IP: 10.0.0.1
server LAN IP: 10.0.0.2
Begin 50 DHCP addresses at 10.0.0.100 -- 10.0.0.149

Particularly with VPN from home sites, avoiding 192.168.x.x Class C addresses is strongly advised, as nearly all will use this as a default.

 

[LSUECE21]

the router is set to 192.0.0.2, and actually the problem isn't with it conflicting with one of the NIC's ip addresses. NIC 1 has ip 192.0.0.100 NIC 2 has 192.0.0.139, and then it assign another ip for the vpn server address usually somewhere in the 192.0.0.12x, but for the first client that signs in it sets theirs to the same as the server vpn ip. hopefully that makes sense.

 

[bcastner]

There is a DHCP scope issue.

Again, set your server to static IPs, outside of the DHCP scope.

Reserve for VPN remote clients an additional set of static IPs, and assign them so that they are not conflicting.

192.168.0x and 192.168.1.x are poor choices for your local LAN given the proliferation of home routers at business and home sites using this network addressing by default.

Move you LAN base address to the often less used (by the little routers) B-Class 10.10.x.x network segment, or attempt to move as I described above your server and other important HOST devices to static IPs outside the normal DHCP ranges.

 

[John Lewis]

The MS VPN server does not live well with DHCP. A better option is to assign the VPN server a block of addresses and exclude those from the DHCP server. A good rule of thumb is to take the number of clients X 3 when deciding how many addresses you need in the pool. If you have more than 6 or so users, then the number of clients + 10 usually works. You need more addresses than clients as it takes a while for the VPN server to recycle the addresses even when using a pool.

On the issue of 192.168.0, .1 and .2 . . . I'll agree that you will be better served long term if you change your addressing now. I don't think that is causing the current problem, but sooner or later it will cause routing issues for your VPN clients.

I would not switch to a 10.x.x.x addressing shceme, as the MS VPN client assumes RFC compliant addresses and adds a route on the client side based upon this assumption. If you switch to a 10.x.x.x network address, it will be assumed to be a class A network and the client will add the route based upon that assumption. Again, this can cause some routing issues, so it is better to stick with RFC compliant addresses and at the same time select an address that is appropriate to the size of the network.

 

[bcastner]

As much as I admire mhkwood's comments, and I do:

. "On the issue of 192.168.0, .1 and .2 . . . I'll agree that you will be better served long term if you change your addressing now. I don't think that is causing the current problem, but sooner or later it will cause routing issues for your VPN clients."

Well, it does cause problems, now.

I do not want this quibble to lose mhkwood's essential point: ideally you could reserve DHCP addresses. But, I suspect your router does not permit this feature. Change the LAN base network segment address.

. "I would not switch to a 10.x.x.x addressing shceme, as the MS VPN client assumes RFC compliant addresses and adds a route on the client side based upon this assumption. If you switch to a 10.x.x.x network address, it will be assumed to be a class A network and the client will add the route based upon that assumption."

As a practical matter, the MS VPN client does no such thing. And it is silly to even imply that Class A addresses are not RFC compliant. As a practical matter, what DHCP pushes as the Gateway address matters more than LANA designations of Class Addresses.

But again, the core issue is that you want your local network segment to use IPs through DHCP that are unlikely to conflict with VPN or other assignments.

Bill


Not picking on you mhkwood.