[plug] GRE Tunnels, Kernel 2.4 and PPTP.

[James Bromberger]

Evening all,

I am trying to set up a VPN session between a Win box using the MS VPN virtual 
adapter, and a PPTP daemon running on a host behind a firewall.  I am 
configuring the NAT rules with iptables under 2.4, and can't seem to get the 
GRE part of the connection to work (or thats what I think is failing).


First the rules are thus:
	* All internal connections are NATed out with (std NAT rule):
  iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

	* Next, incoming 1723 PPTP auth is redirected to the internal machine:
  iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 1723 -j DNAT --to 10.0.0.2

	* Finally, incoming GRE for PPTP is redirected with (I have tried 
with and without this rule, see below):
  iptables -t nat -A PREROUTING -i eth0 -p 47 -j DNAT --to 10.0.0.2


Thus I see rules with:

# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DNAT       tcp  --  anywhere             anywhere           tcp dpt:1723 to:10.0.0.2
DNAT       gre  --  anywhere             anywhere           to:10.0.0.2

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  anywhere             anywhere



I can connect to the PPTP server from the outside world, and authenticate 
against it, but then the VPN fails. My firewall box shows the following 
(amongst other things) in /proc/net/ip_conntrack (IP addresses changed to 
'xxx' and 'yyy' to protect the guilty):
  unknown  47 568 src=10.0.0.2 dst=61.xxx.xxx.xxx [UNREPLIED] src=61.xxx.xxx.xxx dst=203.yyy.yyy.yyy use=1



Now, my syslog on the PPTP server (behind the firewall) shows:

pptpd[783]: CTRL (PPPD Launcher): local address = 10.0.0.2
pptpd[783]: CTRL (PPPD Launcher): remote address = 10.0.0.241
pptpd[782]: CTRL: Sent packet to client
pppd[783]: pppd 2.4.1 started by root, uid 0
pppd[783]: Using interface ppp0
pppd[783]: Connect: ppp0 <--> /dev/pts/0
pppd[783]: LCP: timeout sending Config-Requests
pppd[783]: Connection terminated.
pppd[783]: Exit.
pptpd[782]: GRE: read(fd=5,buffer=804d9c0,len=8196) from PTY failed: status = -1 error = Input/output error
pptpd[782]: CTRL: PTY read or GRE write failed (pty,gre)=(5,6)
pptpd[782]: CTRL: Client 61.yyy.yyy.yyy control connection finished
pptpd[782]: CTRL: Exiting now
pptpd[357]: MGR: Reaped child 782


Does anyone know whats going wrong here? I am suspecting that GRE is having 
trouble going back and forth through the NAT; does anyone have this kind of 
setup running under 2.4 with iptables? Most of the documentation that is 
floating around seems to refer to 2.2 or 2.0 and ipchains...

I had a hunch that perhaps the GRE is started by the PPTP server, and thus 
all GRE will be tracked and handled by the default MASQ, and incoming GRE will 
not need a DNAT mangle (ie, redirection to the internal server) since the 
MASQ will handle this for us; I tired repeating the exercise without the 
third rule above, but it still fails:

pppd[925]: Using interface ppp0
pppd[925]: Connect: ppp0 <--> /dev/pts/3
pptpd[924]: CTRL: Received PPTP Control Message (type: 12)
pptpd[924]: CTRL: Made a CALL DISCONNECT RPLY packet

The pptpd disconnect is 30 seconds after pppd tried to set up the tunnel; ie, 
a timeout occurs.

Anyone have any ideas. The MASQ VPN FAQ/HOWTO leaves me stuck with this 
problem.

Many thanks,

  James

-- 
 James Bromberger <james_AT_rcpt.to> www.rcpt.to/~james

       * *  C u in Bordeaux - 1st Debian Conference, July 2001 * * 
 Remainder moved to http://www.rcpt.to/~james/james/sig.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://lists.plug.org.au/pipermail/plug/attachments/20010513/1428672a/attachment.pgp>