From owner-freebsd-net Tue Mar 13 23: 8:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from mip.co.za (puck.mip.co.za [209.212.106.44]) by hub.freebsd.org (Postfix) with ESMTP id 0C44337B719 for ; Tue, 13 Mar 2001 23:08:29 -0800 (PST) (envelope-from patrick@mip.co.za) Received: from patrick (patrick.mip.co.za [10.3.13.181]) by mip.co.za (8.9.3/8.9.3) with SMTP id JAA64443; Wed, 14 Mar 2001 09:07:03 +0200 (SAST) (envelope-from patrick@mip.co.za) From: "Patrick O'Reilly" To: "Peter Brezny" , Subject: RE: route clarification Date: Wed, 14 Mar 2001 09:07:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Peter, > My question is, why didn't routed or something figure this out on its own? What? These are just computers, remember? Computers have a nasty habit of doing what we tell them to do, not what we want them to do! ;-) Seriously though, You do need to tell the firewall/nat box about the 10.20.21.0/24 network before it will route correctly to that network. While there was no route it would have used the default route, which would have sent the packets out onto the web (I presume), and your ISP probably filtered them at their router as these are reserved private addresses. The only thing I would change is that the route entry should really be: # route add -net 10.20.21.0/24 10.30.1.20 and not: # route add -net 10.20.21.124 10.30.1.20 This will ensure that the whole 10.20.21.0/24 network is correctly routed, not just the given IP. You will notice if you perform a 'route get 10.20.21.124' after using your original 'route add' that the result is: ---- # route get 10.20.21.124 route to: 10.20.21.124 destination: 10.20.21.124 mask: 255.255.255.255 <--- here is your problem gateway: 10.30.1.20 ---- Try 'route get 10.20.21.125' (I presume you want this IP to route the same way?) ---- # route get 10.20.21.125 route to: 10.20.21.125 destination: default mask: default gateway: ---- If you do: # route add -net 10.20.21.0/24 10.30.1.20 Try 'route get 10.20.21.125' and now you get: ---- # route get 10.20.21.125 route to: 10.20.21.125 destination: 10.20.21.0 mask: 255.255.255.0 <--- the netmask is correct now gateway: 10.30.1.20 ---- Have fun, Patrick. -----Original Message----- From: owner-freebsd-net@FreeBSD.ORG [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Peter Brezny Sent: 13 March 2001 17:52 To: freebsd-net@FreeBSD.ORG Subject: route clarification I've managed to get things working, but I've still got a question or two. Here's what i'm working with > internet ---- firewal/nat box ---- client firewall ---- client lan. > pub pub/10.30.1.1 10.30.1.20/10.20.21.1 10.20.21.x >From Right to Left, each machine's default GW is the internal address of the machine to it's left. So the workstations on the client lan have their GW set to 10.20.21.1 and so on. With this config, the workstations on the client lan could ping both the inside and outside interface of the client firewall, but not the firewall/nat box. the client firewall could ping everything on either side. FInally with some help i figured out that packets were probably making it to the firewall/nat box due to the default route, but wern't finding their way out of the firewall/nat box back to where they came from. placing a route route add -net 10.20.21.124 10.30.1.20 on the firewall/nat box fixed this problem. My question is, why didn't routed or something figure this out on its own? Is this normal? or is the firewall on the firewall/nat box causing problems? Thanks in advance for your help. pb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message