Member Avatar for heals1ic

I have a gateway<->gateway IPSEC VPN running between 2 offices and the first gateway (BiPAC 7404VGO) will also host PPTP VPN connections as well.

I need to be able to route PPTP traffic with a destination to the second gateway through the gateway VPN to services in that second network.

At this stage no routing occurs when trying to access the second office subnet from the PPTP VPN.

All clients are using Windows XP or above and there is an SBS2003 server on the first subnet attached to the first gateway. At this point I have a choice of using SBS2003 PPTP termination or router PPTP termination for incoming client connections. At the moment I have the router as the PPTP endpoint.

I suspect that where it is falling down is the routing on the client itself. I think I need to let each client know when they connect that they need to send traffic for the second subnet through the PPTP VPN so it can be routed to that subnet. I don't want to use the PPTP connection as the default gateway as this would have large performance issues.

Is there a way to dynamically allocate a static route on the client when they establish a PPTP connection to the router (or SBS server) so traffic can be routed correctly?

  • 1 Contributor
  • 1 Reply
  • 370 Views
  • 6 Hours Discussion Span
  • Latest Post Latest Post by heals1ic

Dani AI

Generated

— good diagnosis: the manual route shows the core issue (clients can reach the far subnet when you force a route), so the question is how to make that happen automatically and reliably.

The cleanest, most robust fix is server-side: make the PPTP client address range visible to the site‑to‑site IPsec tunnel. That means either (a) assign PPTP clients addresses from a subnet that the IPsec phase‑2 selectors already include (or bridge them onto the LAN), or (b) add the PPTP address pool to the IPsec selectors on both ends so traffic from “PPTP pool ↔ remote office subnet” is encapsulated. If you cannot change selectors, add a static route on the remote office gateway pointing the PPTP pool (source) to your gateway as next hop so the remote end will send replies back through the tunnel. Also verify the PPTP endpoint is not NATing client addresses — NAT breaks selector matching unless you account for it.

If you must do it client‑side, avoid manual edits by automating the route on connect/disconnect. For Windows domain clients use one of these approaches: build a custom VPN package with the Connection Manager Administration Kit (CMAK) that runs a connect/disconnect script, deploy a computer startup script or scheduled task via Group Policy that adds the needed route (so it runs with SYSTEM privileges), or use a lightweight connect script tied to the VPN profile to compute the current gateway and add/remove the route when the PPP interface comes up.

Quick troubleshooting checklist: after connecting run ipconfig/route print and tracert to see which hop is taken; confirm the client IP is in the expected PPTP pool; check the remote gateway’s routes and IPsec selectors; and confirm the PPTP server isn’t NATing client traffic. Server‑side selector/route changes are preferable — they remove the need to touch every client and avoid creating a default‑gateway tunnel.

Member Avatar for heals1ic

Update -

Further to this I have manually added a routing entry into the clients routing table and can now reach the second subnet.

route add 192.168.2.0 mask 255.255.255.0 192.168.0.35 metric 2

I need this routing table entry to update in each client when they connect with PPTP. Not always will the gateway be as this is issued by DHCP from the SBS 2003 server so this would be hard to batch.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.