Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Mar 2001 09:07:03 +0200
From:      "Patrick O'Reilly" <patrick@mip.co.za>
To:        "Peter Brezny" <peter@black.purplecat.net>, <freebsd-net@FreeBSD.ORG>
Subject:   RE: route clarification
Message-ID:  <NDBBIMKICMDGDMNOOCAIMEHBCEAA.patrick@mip.co.za>
In-Reply-To: <Pine.BSF.4.05.10103131046140.16675-100000@black.purplecat.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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: <your 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?NDBBIMKICMDGDMNOOCAIMEHBCEAA.patrick>