From owner-freebsd-net Thu Jan 9 18: 4:37 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F062937B405 for ; Thu, 9 Jan 2003 18:04:33 -0800 (PST) Received: from lariat.org (lariat.org [63.229.157.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9B0843EB2 for ; Thu, 9 Jan 2003 18:04:32 -0800 (PST) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp1000.lariat.org@lariat.org [63.229.157.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id TAA19385 for ; Thu, 9 Jan 2003 19:04:20 -0700 (MST) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <4.3.2.7.2.20030109182517.02963410@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Jan 2003 19:04:18 -0700 To: freebsd-net@freebsd.org From: Brett Glass Subject: PPTP tunneling over PPPoE link Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm having trouble doing something which I'd THOUGHT would just work... but it's not. Any help would be much appreciated. Here's the story. A client's LAN is connected to the Internet via a FreeBSD firewall/router. The FreeBSD box is using PPPoE (userland PPP plus NetGraph PPPOE) to connect to the upstream router. The LAN inside the firewall is NATted to 192.168/16. It works perfectly; it even correctly passes SMTP connections on to an internal machine with the address 192.168.0.2 (see the configuration file below). The client calls and says that expects to be away for awhile, and wants to tunnel back into the LAN with his Windows laptop. Since userland PPP is already running on the machine and works fine, I set up PPTP on his server, using PopTop (yes, it's GPLed, but there's no actively maintained alternative) and userland PPP. The result, in theory, will be a tunnel that uses PPTP (which is encrypted PPP over GRE) over PPP over Ethernet. A bit awkward, but necessary given the need for an encrypted tunnel. Alas, try as I might, I can't tunnel in from the outside world. I can verify that TCP port 1723 (which is used by PPTP for a control channel) is open on the firewall and accepting connections. But attempts to establish a tunnel fail; the client reports that the server isn't responding to it. The log looks like this: Jan 9 09:55:00 www ppp[3119]: Phase: Using interface: tun1 Jan 9 09:55:00 www ppp[3119]: Phase: deflink: Created in closed state Jan 9 09:55:00 www ppp[3119]: tun1: Command: default: ident user-ppp VERSION (built COMPILATIONDATE) Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: set timeout 0 Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: set dial Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: set login Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: set ifaddr 192.168.0.1/32 Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: set server /var/run/pptp_ppp_%d ******** 0700 Jan 9 09:55:00 www ppp[3119]: tun1: Phase: Listening at local socket /var/run/pptp_ppp_1. Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: disable chap Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: deny chap Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: disable pap Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: disable passwdauth Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: disable deflate pred1 Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: deny deflate pred1 Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: disable utmp Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: enable mschapv2 mppe Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: set mppe * stateless Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: disable proxy Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: accept dns Jan 9 09:55:00 www ppp[3119]: tun1: Command: pptp: set dns 192.168.0.1 Jan 9 09:55:00 www ppp[3119]: tun1: Phase: PPP Started (direct mode). Jan 9 09:55:00 www ppp[3119]: tun1: Phase: bundle: Establish Jan 9 09:55:00 www ppp[3119]: tun1: Phase: deflink: closed -> opening Jan 9 09:55:00 www ppp[3119]: tun1: Phase: deflink: Connected! Jan 9 09:55:00 www ppp[3119]: tun1: Phase: deflink: opening -> carrier Jan 9 09:55:00 www ppp[3119]: tun1: Phase: deflink: carrier -> lcp Jan 9 09:55:00 www ppp[3119]: tun1: LCP: FSM: Using "deflink" as a transport Jan 9 09:55:00 www ppp[3119]: tun1: LCP: deflink: State change Initial --> Closed Jan 9 09:55:00 www ppp[3119]: tun1: LCP: deflink: State change Closed --> Stopped Jan 9 09:55:01 www ppp[3119]: tun1: LCP: deflink: LayerStart Jan 9 09:55:01 www ppp[3119]: tun1: LCP: deflink: SendConfigReq(1) state = Stopped Jan 9 09:55:01 www ppp[3119]: tun1: LCP: ACFCOMP[2] Jan 9 09:55:01 www ppp[3119]: tun1: LCP: PROTOCOMP[2] Jan 9 09:55:01 www ppp[3119]: tun1: LCP: ACCMAP[6] 0x00000000 Jan 9 09:55:01 www ppp[3119]: tun1: LCP: MRU[4] 1500 Jan 9 09:55:01 www ppp[3119]: tun1: LCP: MAGICNUM[6] 0x02b7e69a Jan 9 09:55:01 www ppp[3119]: tun1: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x81) Jan 9 09:55:01 www ppp[3119]: tun1: LCP: deflink: State change Stopped --> Req-Sent Jan 9 09:55:04 www ppp[3119]: tun1: LCP: deflink: SendConfigReq(1) state = Req-Sent Jan 9 09:55:04 www ppp[3119]: tun1: LCP: ACFCOMP[2] Jan 9 09:55:04 www ppp[3119]: tun1: LCP: PROTOCOMP[2] Jan 9 09:55:04 www ppp[3119]: tun1: LCP: ACCMAP[6] 0x00000000 Jan 9 09:55:04 www ppp[3119]: tun1: LCP: MRU[4] 1500 Jan 9 09:55:04 www ppp[3119]: tun1: LCP: MAGICNUM[6] 0x02b7e69a Jan 9 09:55:04 www ppp[3119]: tun1: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x81) Jan 9 09:55:07 www ppp[3119]: tun1: LCP: deflink: SendConfigReq(1) state = Req-Sent Jan 9 09:55:07 www ppp[3119]: tun1: LCP: ACFCOMP[2] Jan 9 09:55:07 www ppp[3119]: tun1: LCP: PROTOCOMP[2] Jan 9 09:55:07 www ppp[3119]: tun1: LCP: ACCMAP[6] 0x00000000 Jan 9 09:55:07 www ppp[3119]: tun1: LCP: MRU[4] 1500 Jan 9 09:55:07 www ppp[3119]: tun1: LCP: MAGICNUM[6] 0x02b7e69a Jan 9 09:55:07 www ppp[3119]: tun1: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x81) Jan 9 09:55:10 www ppp[3119]: tun1: LCP: deflink: SendConfigReq(1) state = Req-Sent Jan 9 09:55:10 www ppp[3119]: tun1: LCP: ACFCOMP[2] Jan 9 09:55:10 www ppp[3119]: tun1: LCP: PROTOCOMP[2] Jan 9 09:55:10 www ppp[3119]: tun1: LCP: ACCMAP[6] 0x00000000 Jan 9 09:55:10 www ppp[3119]: tun1: LCP: MRU[4] 1500 Jan 9 09:55:10 www ppp[3119]: tun1: LCP: MAGICNUM[6] 0x02b7e69a Jan 9 09:55:10 www ppp[3119]: tun1: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x81) Jan 9 09:55:13 www ppp[3119]: tun1: LCP: deflink: SendConfigReq(1) state = Req-Sent Jan 9 09:55:13 www ppp[3119]: tun1: LCP: ACFCOMP[2] Jan 9 09:55:13 www ppp[3119]: tun1: LCP: PROTOCOMP[2] Jan 9 09:55:13 www ppp[3119]: tun1: LCP: ACCMAP[6] 0x00000000 Jan 9 09:55:13 www ppp[3119]: tun1: LCP: MRU[4] 1500 Jan 9 09:55:13 www ppp[3119]: tun1: LCP: MAGICNUM[6] 0x02b7e69a Jan 9 09:55:13 www ppp[3119]: tun1: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x81) Jan 9 09:55:16 www ppp[3119]: tun1: LCP: deflink: LayerFinish Jan 9 09:55:16 www ppp[3119]: tun1: LCP: deflink: State change Req-Sent --> Stopped Jan 9 09:55:16 www ppp[3119]: tun1: LCP: deflink: State change Stopped --> Closed Jan 9 09:55:16 www ppp[3119]: tun1: LCP: deflink: State change Closed --> Initial Jan 9 09:55:16 www ppp[3119]: tun1: Phase: deflink: Disconnected! Jan 9 09:55:16 www ppp[3119]: tun1: Phase: deflink: Connect time: 16 secs: 0 octets in, 300 octets out Jan 9 09:55:16 www ppp[3119]: tun1: Phase: deflink: : 0 packets in, 5 packets out Jan 9 09:55:16 www ppp[3119]: tun1: Phase: total 18 bytes/sec, peak 24 bytes/sec on Thu Jan 9 09:55:16 2003 Jan 9 09:55:16 www ppp[3119]: tun1: Phase: deflink: lcp -> closed Jan 9 09:55:16 www ppp[3119]: tun1: Phase: bundle: Dead Jan 9 09:55:16 www ppp[3119]: tun1: Phase: PPP Terminated (normal). What's wrong? It looks (though I'm not positive) as if the GRE packets, which carry the underlying PPP session, can't get through the PPPoE link. I've checked the documentation for userland PPP, and there's nothing to indicate that they wouldn't (or how to allow them to pass if they're blocked by default). The /etc/ppp.conf file looks like this, with passwords erased to protect the guilty. Note that the top portion is for the PPPoE connection and the bottom portion is for PPTP: default: set log Phase Chat LCP IPCP CCP tun command ident user-ppp VERSION (built COMPILATIONDATE) lariat: set device PPPoE:fxp1:provider set mru 1492 set mtu 1492 set speed sync set authname USERID set authkey PASSWORD set timeout 0 set cd 5 enable lqr set lqrperiod 15 disable chap disable pap disable mppe deny mppe nat enable yes nat unregistered_only yes nat same_ports yes nat port tcp 192.168.0.2:smtp smtp set dial set login set redial 0 0 pptp: set timeout 0 set dial set login set ifaddr 192.168.0.1/32 set server /var/run/pptp_ppp_%d "" 0700 disable chap deny chap disable pap disable passwdauth disable deflate pred1 deny deflate pred1 disable utmp enable mschapv2 mppe set mppe * stateless disable proxy accept dns set dns 192.168.0.1 --Brett Glass To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message