Currently Being ModeratedNov 10, 2012 11:46 PM (in response to khkewsupport)
Our DHCP server is running with a subnet of 10.0.1.0 -> 10.0.3.255 and a subnet mask of 255.255.252.0
The bigger question is what's the network setting for the server that's running VPN.
Just because your main DHCP server is running on a /22 network (255.255.252.0) that doesn't mean your VPN server is doing the same. Check the settings on the VPN server to make sure they match.
The other thing to check is whether the clients are being told to send the right traffic over the VPN connection. You have the ability to define which IP subnets should be tunneled, and if that doesn't include the full /22 then you may experience this kind of problem.
The easiest way to check is to connect a client to the VPN system and use Terminal.app to check the output of ifconfig -a (list all active interfaces) and netstat -nr (list all network routes) which, combined, will tell you the connection state.
Currently Being ModeratedNov 11, 2012 5:15 AM (in response to khkewsupport)
This does appear to be an IP subnet routing question. And you may (or do?) understand some of the following.
The usual approach involves rationalizing the network and particularly subnets and DHCP server assignments across the organization, and to use IP routers and (potentially) static routes between the "hunks" of the networks; the subnets.
If you don't have a whole lot of network traffic, then stuffing everything into the same /22 is simple and will work fine.
However, a /22 can be a whole lot of hosts for one segment, and can easily saturate any existing GbE-class backbone(s) as those hosts get chatty. You've also got the usual Bonjour and other multicast traffic rattling around within that whole subnet (Bonjour doesn't pass beyond an IP router by default), and propagating multocast announcements and related traffic through the whole network might not be entirely appropriate, or might be confusing to users. Using smaller subnet hunks and routers, the network traffic can be more effectively partitioned, with less traffic on the backbone(s).
If you decide to partition the network, it's common to partition based either on network topology or on organizational function, and variously on both. You might have a four-wing building with north, south, east and west networks because of the wiring - or New York, London, Singapore and Sydney based on location - or you might have an overlaid Student and Faculty or Operations and Finance networks - and set the routing up accordingly. The former design to partition the network traffic on (or off of) the physical links, while the latter partitions the information. And it's quite feasible to combine the two schemes.
I'd also likely migrate the VPN servers off of the OS X systems and over to the network perimeter (usually at or via a gateway), as implementing a VPN server at the network edge is usual easier to manage in my experience, and particularly when NAT passthrough is involved. (And OS X makes for a comparatively expensive and under-performing IP router, too.)