[pptp-server] Troubles with GRE masquerading
Anthony Foiani
tkil at scrye.com
Thu Sep 30 23:53:03 CDT 1999
My apologies if this is not the appropriate list for this topic. Any
pointers to a more appropriate list would be welcome. My further
apologies for this message being as long as it is; I was perhaps
overzealous in adding information. Thanks for your patience. :)
I'm trying to set up PPTP between external MS clients and an internal
(behind a masquerading Linux firewall) "poptop" PPTP server, using
private IP addresses behind the firewall.
I can get the PPTP client to talk to the server when they are both on
the private IP LAN behind the firewall. When I try to go through the
firewall, however, I am not having any luck.
The firewall is running linux 2.2.12, with the "ip_masq_vpn-2.2.11"
patch applied. I'm using rinetd to forward the intial tcp/1723
traffic, and that part of the process is working well. The PPTP
server starts up, and tries to launch ppp. The communication from
pppd seems very one-sided, however:
| Sep 30 20:02:29 pptp-server pptpd[2193]: MGR: Launching /usr/local/sbin/pptpctrl to handle client
| Sep 30 20:02:29 pptp-server pptpd[2193]: CTRL: local address = 192.168.1.221
| Sep 30 20:02:29 pptp-server pptpd[2193]: CTRL: remote address = 192.168.1.201
| Sep 30 20:02:29 pptp-server pptpd[2193]: CTRL: Client 192.168.1.1 control connection started
| Sep 30 20:02:29 pptp-server pptpd[2193]: CTRL: Received PPTP Control Message (type: 1)
| Sep 30 20:02:29 pptp-server pptpd[2193]: CTRL: Made a START CTRL CONN RPLY packet
| Sep 30 20:02:29 pptp-server pptpd[2193]: CTRL: I wrote 156 bytes to the client.
| Sep 30 20:02:29 pptp-server pptpd[2193]: CTRL: Sent packet to client
| Sep 30 20:02:30 pptp-server pptpd[2193]: CTRL: Received PPTP Control Message (type: 7)
| Sep 30 20:02:30 pptp-server pptpd[2193]: CTRL: Set parameters to 152 maxbps, 16 window size
| Sep 30 20:02:30 pptp-server pptpd[2193]: CTRL: Made a OUT CALL RPLY packet
| Sep 30 20:02:30 pptp-server pptpd[2193]: CTRL: Starting call (launching pppd, opening GRE)
| Sep 30 20:02:30 pptp-server pptpd[2193]: CTRL: pty_fd = 4
| Sep 30 20:02:30 pptp-server pptpd[2193]: CTRL: tty_fd = 5
| Sep 30 20:02:30 pptp-server pptpd[2193]: CTRL: I wrote 32 bytes to the client.
| Sep 30 20:02:30 pptp-server pptpd[2194]: CTRL (PPPD Launcher): Connection speed = 115200
| Sep 30 20:02:30 pptp-server pptpd[2194]: CTRL (PPPD Launcher): local address = 192.168.1.221
| Sep 30 20:02:30 pptp-server pptpd[2194]: CTRL (PPPD Launcher): remote address = 192.168.1.201
| Sep 30 20:02:30 pptp-server pptpd[2193]: CTRL: Sent packet to client
| Sep 30 20:02:30 pptp-server pppd[2194]: pppd 2.3.8 started by root, uid 0
| Sep 30 20:02:30 pptp-server pppd[2194]: Using interface ppp0
| Sep 30 20:02:30 pptp-server pppd[2194]: Connect: ppp0 <--> /dev/pts/2
| Sep 30 20:02:30 pptp-server pppd[2194]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap 81> <magic 0xf3425008> <pcomp> <accomp>]
| Sep 30 20:02:30 pptp-server pptpd[2193]: CTRL: Received PPTP Control Message (type: 15)
| Sep 30 20:02:30 pptp-server pptpd[2193]: CTRL: Got a SET LINK INFO packet with standard ACCMs
| Sep 30 20:02:33 pptp-server pppd[2194]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap 81> <magic 0xf3425008> <pcomp> <accomp>]
| Sep 30 20:02:57 pptp-server last message repeated 8 times
| Sep 30 20:03:00 pptp-server pppd[2194]: LCP: timeout sending Config-Requests
| Sep 30 20:03:00 pptp-server pptpd[2193]: GRE: read(fd=4,buffer=804d700,len=8196) from PTY failed: status = -1 error = Input/output error
| Sep 30 20:03:00 pptp-server pptpd[2193]: CTRL: PTY read or GRE write failed (pty,gre)=(4,5)
| Sep 30 20:03:00 pptp-server pptpd[2193]: CTRL: Client 192.168.1.1 control connection finished
| Sep 30 20:03:00 pptp-server pptpd[2193]: CTRL: Exiting now
| Sep 30 20:03:00 pptp-server pppd[2194]: Connection terminated.
| Sep 30 20:03:00 pptp-server pppd[2194]: Exit.
Note that it is sending the LCP packets, never receiving. I presume
this is at least one of the reasons that the PPTP session is failing,
and it looks like my GRE masquerading is not happinging.
Trying to test this with the patched "traceroute" utility was
unenlightening. "traceroute -G external_client" from the firewall
external interface works; but doing the same from the pptpd server
doesn't work; it only gets as far as the firewall. The firewall
claims (in the log) that it's setting up a GRE masq, but it doesn't
seem to ever be used.
The firewall is configured with ipchains, and the only DENY rule (on
the input chain) is set to log all denied packets. I have a gre MASQ
rule in place, and it is triggered; should I not be using the ipchains
masquerading for GRE? I have downloaded "ipfwd", but I find it
confusing; I would expect a masquerading tool to have both a "to" and
"from" setting, and ipfwd only accepts one address -- and it's not
obvious to me which it is.
The ipchains configuration is taken from one of the FAQs (which one, I
must say that I don't quite remember anymore; I've been working on
this off and on for a week or more). To fit it into the RedHat (6.0)
boot scheme, it is run by sourcing:
/etc/sysconfig/network-scripts/ifcfg-eth0
where eth0 is the external interface; the masquerading option (which
does work for internal TCP services) must be selected on the external
port, which I found mildly counterintuitive. In this case, my
"ifcfg-eth0" file contains:
| DEVICE=eth0
| ONBOOT=yes
| MASQUERADE=no
| INTERNAL=no
|
| IPADDR=216.17.137.20
| GATEWAY=216.17.137.30
| NETMASK=255.255.255.224
|
| MASQ_VPN_PPTP=yes
| PPTP_CLIENT=0/0
| PPTP_SERVER=192.168.1.11
which is sourced before the following code is run:
| if [ "x${MASQ_VPN_PPTP}x" = "xyesx" ] ;
| then
| if [ -n "$PPTP_CLIENT" -a -n "$PPTP_SERVER" ] ;
| then
| ipchains -A input -j ACCEPT -p tcp -i $DEVICE \
| -s $PPTP_CLIENT pptp -d $IPADDR
| ipchains -A forward -j MASQ -p tcp -i $DEVICE \
| -s $PPTP_SERVER -d $PPTP_CLIENT pptp
| ipchains -A output -j ACCEPT -p tcp -i $DEVICE \
| -s $IPADDR -d $PPTP_CLIENT pptp
|
| ipchains -A input -j ACCEPT -p gre -i $DEVICE \
| -s $PPTP_CLIENT -d $IPADDR
| ipchains -A forward -j MASQ -p gre -i $DEVICE \
| -s $PPTP_SERVER -d $PPTP_CLIENT
| ipchains -A output -j ACCEPT -p gre -i $DEVICE \
| -s $IPADDR -d $PPTP_CLIENT
| else
| echo "WARNING: cannot do VPN MASQ without PPTP_* specs"
| fi
| fi
This results in ipchains which look like:
| # ipchains -L input -vxn | nl -v -1
| -1 Chain input (policy DENY: 1613 packets, 136292 bytes):
| 0 pkts bytes target prot opt tosa tosx ifname mark outsize source destination ports
| 24 0 0 ACCEPT tcp ------ 0xFF 0x00 eth0 0.0.0.0/0 216.17.137.20 1723 -> *
| 25 80 4240 ACCEPT gre ------ 0xFF 0x00 eth0 0.0.0.0/0 216.17.137.20 n/a
| # ipchains -L forward -vxn | nl -v -1
| -1 Chain forward (policy ACCEPT: 276 packets, 12972 bytes):
| 0 pkts bytes target prot opt tosa tosx ifname mark outsize source destination ports
| 1 0 0 MASQ tcp ------ 0xFF 0x00 eth0 192.168.1.11 0.0.0.0/0 * -> 1723
| 2 58 2784 MASQ gre ------ 0xFF 0x00 eth0 192.168.1.11 0.0.0.0/0 n/a
| # ipchains -L output -vxn | nl -v -1
| -1 Chain output (policy ACCEPT: 269548 packets, 58413041 bytes):
| 0 pkts bytes target prot opt tosa tosx ifname mark outsize source destination ports
| 5 0 0 ACCEPT tcp ------ 0xFF 0x00 eth0 216.17.137.20 0.0.0.0/0 * -> 1723
| 6 260 12480 ACCEPT gre ------ 0xFF 0x00 eth0 216.17.137.20 0.0.0.0/0 n/a
If it helps examples, here's my configuration.
external client address: 199.174.224.195 (ppp to netcom denver)
immediate external network: 216.17.137.0/27
external firewall interface: 216.17.137.20 (eth0)
internal firewall interface: 192.168.1.1 (eth1)
internal network: 192.168.1.0/24
internal PPTP server: 192.168.1.11 (eth0)
Any tips would be appreciated. Even if you don't have answers, I
could definitely use suggestions about how to get more information
about this problem. I'm currently completely clueless about where
these packets are going, and why they're not coming back. (Well, I
suspect that they're being sent off without getting properly
masqueraded; but what do I use to masquerade them? ipfwd? If so,
what's a reasonable invocation line for my setup?)
If I can provide more information that might help pin this problem
down, please just let me know.
Thanks very much in advance for your time,
Tony
p.s. When I did get pptpd to connect over the LAN, it kept this
pattern up for the duration of the connection; this pattern
appears in the log about once every second or two.
| Sep 30 19:02:31 pptp-server pppd[2138]: rcvd [CCP ConfReq id=0x8 <mppe 1 0 0 1>]
| Sep 30 19:02:31 pptp-server pppd[2138]: sent [CCP ConfRej id=0x8 <mppe 1 0 0 60>]
| Sep 30 19:02:32 pptp-server pppd[2138]: sent [CCP ConfReq id=0x1]
| Sep 30 19:02:32 pptp-server pppd[2138]: rcvd [CCP ConfAck id=0x1]
I'm guessing that the PPTP client is trying to upgrade the
connection to some form of encrypted conversation, and pptpd is
refusing. Where should I look to fix this issue? My
/etc/ppp/options file contains:
| lock
| name pptp-server
| debug
| auth
| +chap
| +chapms
| +chapms-v2
| require-chap
| mppe-40
| mppe-128
| mppe-stateless
| proxyarp
And I did compile pptp (and pppd) according to the instructions
on the poptop HOWTO/FAQ, including the crypto libraries. Hm... I
wonder if those "+" signs were supposed to be in there, or just
some sort of patch indication?
More information about the pptp-server
mailing list