How can I force all internet traffic over a PPTP VPN but still allow local lan access?

Those iptables rules don't allow traffic to the VPN server, so the VPN can't be established. You need the following rules in the OUTPUT chain before the final DROP rule, where 1.2.3.4 is the IP address of the VPN server. These allow TCP connections to port 1723 (the PPTP control channel) and GRE packets (the data channel).

iptables --append OUTPUT --destination 1.2.3.4 --protocol tcp --dport 1723 --jump ACCEPT
iptables --append OUTPUT --destination 1.2.3.4 --protocol gre --jump ACCEPT

There are two approaches to this, routing based and firewall based.

Routing approach

The typical routing table of a machine not connected to a VPN looks something like this:

10.23.11.0/24 dev eth0
default via 10.23.11.1

The first route is to hosts on the LAN, and the second route sends everything else to the default gateway. When connected to a VPN the routing table looks something like this (where 1.2.3.4 is the VPN server's public IP, and 10.8.0.1 is the VPN server's private IP):

10.23.11.0/24 dev eth0
1.2.3.4 via 10.23.11.1
default via 10.8.0.1

The first route is the same, and the third route is what sends everything over the VPN. Note the second rule however: it says that to reach the VPN server's public IP packets should be sent via the default gateway. This is so that the tunnelled packets created by the VPN client actually reach the server; if this route is not in place the packets created by the VPN client would be sent over the VPN again, and would never get to the server.

Now, if the third route is removed, then packets destined for anywhere on the Internet apart from the VPN server would not have a matching route, and so the host would never send them out. Therefore we want the routing table to look like this when the VPN is not connected:

10.23.11.0/24 dev eth0
1.2.3.4 via 10.23.11.1

Hosts on the LAN can still be reached, and the VPN server can still be reached (since we need to be able to start the VPN), but everything else will not be routed out. Getting this setup can be a bit tricky though, especially if you're using DHCP. A static configuration on Debian would involve the following in /etc/network/interfaces however:

auto eth0
iface eth0 inet static
    address 10.23.11.10
    netmask 255.255.255.0
    up ip route add 1.2.3.4 via 10.23.11.1

Note that there is no gateway statement, since this is what installs the default route.

The downside to this approach is that non-VPN traffic to the VPN server is still allowed out unencrypted. If you run other services on the VPN server and need to ensure that they are protected then you'll have to use the firewall approach.

Edit: @JamesRyan suggests that this approach is fragile because a default route could be added automatically or accidentally. Another approach is to add a blackhole route, which sends the traffic somewhere which will not route it any further. This won't work with an automatically added default route however, because it already uses the highest priority metric 0. The default route still needs to be removed, but something like the following can then be added.

default via 127.255.255.255

Firewall approach

The idea here is to block all outgoing traffic on the physical interface apart from the tunnelled traffic created by the VPN client and traffic destined for the LAN. The traffic to allow for the VPN depends on the protocol being used. PPTP uses TCP port 1723 as a control channel, and GRE as the actual tunnel. OpenVPN uses UDP port 1194. The firewall rules would look something like this:

iptables --append OUTPUT --out-interface eth0 --destination 10.23.11.0/24 --jump ACCEPT
iptables --append OUTPUT --out-interface eth0 --destination 1.2.3.4 --protocol tcp --dport 1723 --jump ACCEPT
iptables --append OUTPUT --out-interface eth0 --destination 1.2.3.4 --protocol gre --jump ACCEPT
iptables --append OUTPUT --out-interface eth0 --jump REJECT

The first rule accepts traffic for the LAN. The second and third rules accept VPN traffic to the VPN server. The fourth rule rejects all other traffic exiting the physical interface.

The one other thing you may need to accept is DNS if you use a DNS server not on the LAN, because the VPN client probably needs to do a DNS lookup in order to find the VPN server. The following rule inserted before the REJECT would allow DNS traffic to Google's public DNS service.

iptables --append OUTPUT --out-interface eth0 --destination 8.8.8.8 --protocol udp --dport 53 --jump ACCEPT

Add another default route with a higher metric pointing to a null interface. When the VPN is unavailable the 2nd route will kick in and blackhole the traffic