NOTE: I am not running, nor trying to run, a VPN server on Linux!

My situation:

X -> Y -> Z

X: Windows XP running MS VPN client (PPTP) inside Y's LAN
Y: Linux server (Red Hat 7.2) masquerading A (and other boxes)
Z: VPN server outside the LAN (Cisco 3000, not that it matters)

iptables successfully configured for nat: X is able to do everything else normally . . . surf, email, telnet, whatever. I have set iptables WIDE OPEN as a check and the problem still occurs so I don't think it's a firewall issue.

Attempts to VPN from X to Z through Y timeout while displaying "Verifying username and password". Tracing the packets shows that the handshake over port 1723 is fine, and the GRE request (protocol 47) is sent and received fine, *but* the GRE reply is being sent to an apparently random IP address instead of back to X. I added an extra NIC to Y (using a spare static address) and it worked correctly, but putting Y back behind the NAT made the VPN fail.

Now it gets interesting. At first I thought the GRE request was being ignored by Z, or it (or the reply) was being blocked by a firewall somewhere in between. However, my first attempt to connect from behind the NAT _after_ connecting using the spare static IP address resulted in Z sending the GRE reply to that spare address, even though X was correctly configured for NAT and cleanly shut down and brought back up --- in other words, that address couldn't possibly be known. This makes me think that the GRE request is somehow lying to Z about where it is originating (due to either a bug, a misconfiguration on my part, or a lack of support in Y's kernel). This would explain why it looks like the request is usually ignored: it's not, it's simply being sent somewhere that's not in my LAN. It would even explain the one time (out of dozens) that this scenario actually worked perfectly, in that random luck put the right IP address into whatever location Z uses as a destination for the GRE reply.

Is it even _possible_ for Y's 2.4.7-10 kernel to support a VPN client behind the NAT? I have read the webpage linux/masquerade/ip_masq_vpn.html at impsec.org which seems to imply I need a "PPTP Masquerade" patch to make this work, but I'm not sure.

Thanks for your time.

ok
dpm

We had a pretty similar symptom with our own VPNC3000's. We didn't get as far as needing to do any sniffing though. AFAIK the VPNC will not allow a connection via NAT devices, the option to allow through a NAT device was set, and everything started working. I'm saying this as a customer who is having the VPNC managed by a third party though, so i can't say anythign about how to actaully configure it. but we had a single connection path which just wouldn't work. no idea about the GRE packets, but we could authenticate just find, and the tunnel appeared to come up fine and connect, but nothing ever went through it. This is using the Cisco VPN client though, on IPSEC / UDP, not a pptp client.