Hi,
I've recently started working with a company who have a D-Link DFL-260E in the office and it connects to an off-site rackspace server running Windows Server 2012 R2. Another employee who left before I joined the company had configured an always-on site-to-site vpn to connect the two; most of the time it works fine but occasionally (once or twice a month) the link fails. I've been left workaround instructions on how to reinstate the link each time it fails [log on to the Windows server via its public IP, delete the route, restart the Routing and Remote Access service, re-add the route].
The D-Link router has VPN Objects configured in its Address Book as follows:
VPNServer - <public IP address of remote server>
VPNNetwork - 172.16.5.0/24
A route has been set up on the D-Link as follows:
Tunnel Protocol - PPTP
Remote Endpoint - VPNServer
Remote Network - VPNNetwork
Authentication - <service account on Windows Server>
The D-Link also has a LAN interface defined and acts as a DHCP server for the office PCs on subnet: 172.16.3.0/24
On the Windows server, Routing and Remote Access is set up to enable the computer as a IPv4 router (LAN and demand-dial routing) and as an IPv4 Remote access server; authentication and accounting is provided by Windows; and on the IPv4 tab Forwarding is enabled with a static pool from 172.16.5.1 to 172.16.5.2
I've had a look in the %windir\tracing logs, but there was very little info there. I also checked the Windows event logs and found the following logged multiple times under the 'RemoteAccess' source:
EventID 20253 - Error: The user <s2s-service-account> connected to port VPN3-126 has been disconnected because no network protocols were successfully negotiated.
EventID 20167 - Warning: No IP address is available to hand out to the dial-in client.
EventID 20271 - Warning: The user <various> connected from <changing IPs> but failed an authentication attempt...
The first two seem very relevant?!
(And I assume the latter is people trying to brute-force a connection by guessing credentials and I suppose there's not a lot I can do about that.)
Is there anywhere else I can look for further info in diagnosing this problem?
Can anyone recommend a fix?
Thanks for any help / advice you can offer.
I've recently started working with a company who have a D-Link DFL-260E in the office and it connects to an off-site rackspace server running Windows Server 2012 R2. Another employee who left before I joined the company had configured an always-on site-to-site vpn to connect the two; most of the time it works fine but occasionally (once or twice a month) the link fails. I've been left workaround instructions on how to reinstate the link each time it fails [log on to the Windows server via its public IP, delete the route, restart the Routing and Remote Access service, re-add the route].
The D-Link router has VPN Objects configured in its Address Book as follows:
VPNServer - <public IP address of remote server>
VPNNetwork - 172.16.5.0/24
A route has been set up on the D-Link as follows:
Tunnel Protocol - PPTP
Remote Endpoint - VPNServer
Remote Network - VPNNetwork
Authentication - <service account on Windows Server>
The D-Link also has a LAN interface defined and acts as a DHCP server for the office PCs on subnet: 172.16.3.0/24
On the Windows server, Routing and Remote Access is set up to enable the computer as a IPv4 router (LAN and demand-dial routing) and as an IPv4 Remote access server; authentication and accounting is provided by Windows; and on the IPv4 tab Forwarding is enabled with a static pool from 172.16.5.1 to 172.16.5.2
I've had a look in the %windir\tracing logs, but there was very little info there. I also checked the Windows event logs and found the following logged multiple times under the 'RemoteAccess' source:
EventID 20253 - Error: The user <s2s-service-account> connected to port VPN3-126 has been disconnected because no network protocols were successfully negotiated.
EventID 20167 - Warning: No IP address is available to hand out to the dial-in client.
EventID 20271 - Warning: The user <various> connected from <changing IPs> but failed an authentication attempt...
The first two seem very relevant?!
(And I assume the latter is people trying to brute-force a connection by guessing credentials and I suppose there's not a lot I can do about that.)
Is there anywhere else I can look for further info in diagnosing this problem?
Can anyone recommend a fix?
Thanks for any help / advice you can offer.