DD-WRT PPTP Clients Cannot Reach Each Other: Five Checks

Two laptops dial into the PPTP server on a DD-WRT box, each gets an address, and neither can ping the other. Shared folders never appear and the first instinct is that the 255.255.255.255 mask handed out by the router must be wrong. It is not the fault, and changing it will not create a single new neighbour. Work the five checks below in order and stop as soon as one fails, because each one has a different cure.

Check one: the /32 is not the bug

PPTP carries PPP, and a PPP link joins exactly two endpoints: your client and the server. A netmask describes which addresses share a local segment, and there is no segment here, only the peer at the far end of one wire. An all-ones mask says precisely that, so DD-WRT is handing out the correct value for the link type. The address is a peer address, not an interface address on a LAN.

A 255.255.255.0 mask belongs on a shared medium with hundreds of devices, and putting it on a PPP interface would not make the other side of the tunnel a neighbour either.

Check two: read the PPTP server page values

The settings that matter are all on Services, VPN, PPTP Server. Enable the server, set the server address to the router's LAN address, and keep the client range outside the DHCP pool so a dial-in client and a wired machine cannot be handed the same address. Under CHAP-Secrets add one line per account in the form username * password *, with no spaces inside the name. Apply, then connect with a profile that names the router and one of those accounts.

Where the client stops tells you which layer to inspect. A client that authenticates but receives no address is a pool or secrets problem; a client that receives an address and reaches nothing is a routing or firewall problem.

Check three: look for a route between the two peers

Each tunnel terminating on the router is its own interface, usually ppp0, ppp1 and so on. Traffic from one client to the other has to be routed between those interfaces, and the router has to be willing to forward it. Run ip route on the router and look for a host route for each connected peer, pointing at the matching PPP interface. If a peer is missing a route, the tunnel is not fully up regardless of what the client status screen claims.

Two host routes to two separate ppp interfaces is the shape you want before you go any further.

Check four: inspect the FORWARD chain, not INPUT

Client-to-client traffic is forwarded, not accepted locally, so the INPUT chain is the wrong place to look. Run iptables -L FORWARD -v -n and look for a drop rule that catches the PPP interfaces, plus the packet counters that show whether anything arrives at the chain at all. A default drop policy with no accept rule for tunnel traffic produces exactly the symptom you started with: each client alone is fine, together they are invisible to each other.

If small pings work and large transfers stall, the tunnel is being fragmented rather than blocked. PPTP over PPP normally wants an MTU and MRU around 1450, and leaving them at 1500 gives you a link that passes handshakes and fails on real payloads.

Check five: decide what internet access should do

Clients meant to browse through the office need source translation toward the WAN interface. Clients meant only to reach the LAN need a route and nothing else. Those are different intentions with different rule sets, and the mask question tends to hide this second decision completely. Write down which behaviour you wanted before adding a single rule, because a client that unexpectedly exits through the office line is a surprise that surfaces in a meeting rather than in a log.

One last note, unrelated to the fix: PPTP is obsolete and its authentication has been broken for years. The checklist above still explains what a PPP link does, and the same reasoning applies if you move the clients to a modern tunnel later.