From owner-freebsd-net@FreeBSD.ORG Tue Mar 22 12:29:35 2005 Return-Path: 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 53DD716A4CE for ; Tue, 22 Mar 2005 12:29:35 +0000 (GMT) Received: from gw.Awfulhak.org (awfulhak.demon.co.uk [80.177.173.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7247543D48 for ; Tue, 22 Mar 2005 12:29:34 +0000 (GMT) (envelope-from brian@Awfulhak.org) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.13.3/8.13.3) with ESMTP id j2MCTPDJ089449; Tue, 22 Mar 2005 12:29:26 GMT (envelope-from brian@Awfulhak.org) Date: Tue, 22 Mar 2005 12:29:24 +0000 From: Brian Somers To: "Chris Tusa at Linisys, LLC" Message-ID: <20050322122924.71b7c46a@dev.lan.Awfulhak.org> In-Reply-To: <3083138605032116273eacd0f7@mail.gmail.com> References: <3083138605032116273eacd0f7@mail.gmail.com> X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on gw.lan.Awfulhak.org cc: freebsd-net@freebsd.org Subject: Re: PPP Lan Bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2005 12:29:35 -0000 On Mon, 21 Mar 2005 18:27:58 -0600, "Chris Tusa at Linisys, LLC" wrote: > Greetings, > > I am an experienced BSD administator. I am currently implementing a > solution to connect two campus area buildings together using 2 > machines running FreeBSD 5.3 with 56K modems & PPP. I need some > assistance as follows. I am trying to be verbose so as to provide a > complete overview of what has been done and so this thread may be used > a future guide for others. > > Scenario: > > * A countryclub has a maintainence department located on the other > side of the golf course, too far to have a cable run or a > line-of-sight wireless connection. The purpose of this connection is > to provide a TCP/IP timeclock with access to the main building's > network to transmit data. > > * Maintainence Shed (client): FreeBSD 5.3 client, Serial 56K modem > running ppp-user. Timeclock connected to dial-up client via CrossOver > ethernet cable. > > * Clubhouse (server): FreeBSD 5.3 server, Serial 56K modem running > mgetty. Server connected to LAN switch. > > * The LAN at the clubhouse consists of a CABLE Modem connection, with > an OpenBSD based firewall that provides NAT/PROXY services to the > internal network. > > Current Setup: > > (see this diagram I posted: URL = > http://people.linisys.com/ctusa/images/diagram.jpg ) > > > * main WAN router= 192.168.1.1 > * dialup Server (fxp0)= 192.168.1.230 gateway_enable="yes" > * dialup Server (tun0)= 192.168.1.230 -> 192.168.1.232 (modem) > * dialup Client (tun0)= 192.168.1.232 > * dialup Client (fxp0)= 192.168.2.1 gateway_enable="yes" > > > Problem: > > * It seems that NAT is functioning well, and the systems behind can > communicate. However, the timeclock is unable to communicate with its > counterpart at the clubhouse. I believe this is because they are on > different subnets and routing is not taking place. > > * The timeclock communicates on port 3301 - some sort of forwarding > must be enabled through the ppp nat ? > > * how can the 192.168.2.0 network be accessible from the 192.168.1.0 > network? I know that the 192.168.1.232 (modem) / 192.1681.230 > (ethernet) server box at the main clubhouse is the gateway. How can > other machines find out about this? or can the man residential gateway > learn about this? > > Current possible diagnosis: > > * The complexity of having 2 gateways, it seems that in order for each > machine to be able to see the 192.168.2.0 network at the client side > (maintainence shed), a static route must be added. I would like to > avoid this. > > What I would like: > > * To have the timeclock be on the SAME network as the rest of the clubhouse. The issue is that 192.168.1.0/24 machines have to know to route 192.168.2.0/24 stuff through 192.168.1.230, or else the timeclock machine needs some sort of presence on 192.168.1.0/24. This can be done by allocating a segment of 192.168.1.0/24 to the ppp client and adding ``enable proxyall'' to the ppp server config. server: enable proxyall set ifaddr 192.168.1.230 192.168.1.232/30 client: set ifaddr 192.168.1.233 192.168.1.230 and then setting the addresses on the crossover cable to 192.168.1.233 and 192.168.1.234. The ``enable proxyall'' bit tells ppp to create proxy arp entries for all of 192.168.1.232/30 (except for .232 and .235), allowing everything else on 192.168.1.0/24 to think it's talking directly to these machines. -- Brian Somers Don't _EVER_ lose your sense of humour !