1

I've recently reconfigured our Firewall which handles DHCP for our LAN 192.168.0.0/23 (ie. 192.168.0.0 - 192.168.1.254 with subnet mask 255.255.254.0) due to an expanding list of connected devices. All devices receive their DHCP address fine and can access anything else on the LAN that we've allowed them to, the problem I have is actually with the SSTP VPN connection we had working fine when it was just 192.168.1.0/24.
The VPN server is a Windows Server 2012 R2 ADDC box. It does DNS, but not DHCP. The VPN is configured using RRaS and had been working fine until the network expansion.

So when clients dial-in now they aren't getting a DHCP address on the same 192.168.0.0/23 range... they either get a 169.254.x.x APIPA address, or if I set the IPv4 to Static in RRaS properties, an address in the right range, but with the 255.255.255.255 SNM. Is it this that is stopping access to the LAN? Or is this normal for a VPN connection? Where in RRaS do I have to modify settings to get it working again?

A quick disclaimer - network administration skills aren't my strong point, so I may be misunderstanding something in the configuration.

On a side note, could it be a setting with our Juniper NS-25 firewall which is the DHCP server?... when the SSTP VPN was working fine it was when we were temporarily using a Netgear SMB router (DEVG2020 or something) with just a TCP Port 443 forward to the Server 2012 R2 box through NAT. Now, back on our trusty old Juniper, I've created the appropriate VIPs on the WAN interface, created the appropriate "Any-->VIP" firewall policies and tested TCP Port 443 access and everything looks good - otherwise the external PC's wouldn't be connecting to the SSTP at all. So maybe the Server 2012 R2 box isn't DHCP relaying properly due to the way the Juniper is broadcasting? Or am I overthinking it?

enter image description here

Reece
  • 783
  • 2
  • 13
  • 32

1 Answers1

1

You could try enabling the rras server to hand out a range of IP's instead of using DHCP relay.

To figure out if the relaying is the problem.

Jaime
  • 11
  • 5
  • I had done this using the range 192.168.0.225-192.168.1.0 so that it received the 255.255.254.0 SNM but it didn't help. Out of curiosity, I removed that static range and added 192.168.1.150-192.168.1.199 and tried the connection again... It worked! So why is it that a static range in the 192.168.0.0 group won't allow access to the LAN even though it connects? The Server 2012 R2 box IS using a subnet mask that allows it (ie. 192.168.1.254/255.255.254.0). I'm confused, but glad I have it working again even though I don't really know how. – Reece Aug 11 '16 at 10:50
  • The 255.255.255.255 Mask is normal for vpn clients by the way. Nice you got it working. – Jaime Aug 11 '16 at 14:09
  • Oh **expletive deleted**... I think I might know why it wouldn't DHCP properly - our managed switches haven't yet been configured onto the 255.255.254.0 mask. If I adjust this and remove the static assignment and everything starts working, I'll kick myself for making such a rookie mistake – Reece Aug 12 '16 at 00:12