I’m getting to the bottom of my IPCop VPN problem. Basically it’s a side effect of what I thought was a really neat feature of my sister’s Speedtouch ADSL modem that has bitten me.
The neat feature in question is a kind of IP address passthrough it provides. It allows the modem to maintain the ADSL connection to the ISP, but it jiggers the DHCP server so that you can give one server on your network the IP address of the modem’s ADSL connection.
IPCop supports the required PPPoE/PPTP clients to connect over ADSL in its own right, but because Sis wasn’t sure if she could remember the ADSL password we elected to use this funky feature of the modem rather than trying to set it up “the right way”. Wrong call unfortunately.
The error messages I was getting from IPSec on her IPCop were from pluto being unable to set up the route for the VPN subnet over the IPSec interface. I couldn’t work out where it was getting this totally wierd address it was trying to use as the nexthop. Turns out that the address is actually the default gateway assigned by the ISP… and here is where things get squirrelly. 🙂
Many ISPs (indeed this one) manage PPTP connections like they used to the old PPP connections — using point-to-point. The IP address you were assigned had a “/32” or “host” address mask, and the gateway address was a seemingly arbitrary number that had no relationship to your end of the link at all. But that’s how point-to-point links work — there’s no concept of “subnets” or “network masks”, you just had your IP number at your end and their IP number at the other end. This is the type of connection that my sister’s ISP is giving her.
The problem is that the point-to-point connection is terminating at the modem, and the modem is translating the point-to-point attributes of the address allocation into a response to a DHCP request (and doing it, arguably, rather poorly). The IP address that is coming through to IPCop is not point-to-point, but instead a LAN-based address with a subnet specified. Either the subnet is being provided by the modem in the DHCP response, or it’s being filled in by the DHCP client on IPCop, but regardless it means that the gateway IP address is not in the same subnet as the assigned address. This causes the route command that pluto is issuing to be rejected, because according to IP routing and subnet rules the gateway is not reachable (being not local to the subnet).
Honestly, I’m surprised the Speedtouch’s feature works at all in this situation! Normal traffic is making it through presumably because a link-level route for the gateway address has been added (somehow, maybe by the DHCP client) but this is not enough to satisfy pluto.
The solution will be to confirm what the ISP ADSL password is and set it up correctly with IPCop owning the ADSL connection. That way IPCop will see the point-to-point connection natively and won’t have a jiggered routing table and address config to contend with.
Crossed Wires 