At Friday, 2 January 2004, Debian User <[EMAIL PROTECTED] com> wrote:
>At Friday, 2 January 2004, Debian User <[EMAIL PROTECTED] >com> wrote: > >>At Friday, 2 January 2004, Antony Gelberg <[EMAIL PROTECTED]> wrote: >> >>>On Fri, Jan 02, 2004 at 10:46:06AM -0500, Debian User wrote: >>>> in a previous post, i asked this question but not sure if an answer >>>> was found ... >>>> >>>> >>>> i am trying to set up a network in my office at work. >>>> >>>> +---------------+ +---------------+ >>>> | 192.168.1.100 |-----| 192.168.1.1 | >>>> | 255.255.255.0 | | 255.255.255.0 | +---------------+ >>>> +---------------+ | 10.20.1.158 |---| 10.20.4.48 | >>>> | 255.255.0.0 | | 255.255.0.0 | >>>> +---------------+ +---------------+ >>>> >>>> the 192.168.1.100 machine can ping the 192.168.1.1 and 10.20.1.158 >>>> interface but not the 10.20.4.48 interface. the 10.20.1.158 interface > >> >>>> can ping the 10.20.4.48 interface. >>>> >>>> my routing table is as follows: >>>> >>>> dest gateway genmask flags metric ref use iface >>>> 192.186.1.0 * 255.255.255.0 u 0 0 0 eth1 >>>> 10.20.0.0 * 255.255.0.0 u 0 0 0 eth0 >>>> default 10.20.4.48 0.0.0.0 ug 0 0 0 eth0 >>>> >>>> >>>> >>>> any suggestions as to what i am doing wrong? >>> >>>Not turning on IP routing? cat /proc/sys/net/ipv4/ip_forward. >If it's >>>0, routing is off. >>> >>>I suppose TDW for this is to set ip_forward=1 in /etc/network/options. >>>What this does is effectively echo 1 > /proc/sys/net/ipv4/ip_forward >>> >>>A >> >>right ... forgot about that. when i ping 10.20.4.48 from 192.168. >>1.100, the requests time out. this tells me that there is a route >>to the host ... if this matters. anyway, i am still unable to reach >>10.20.4.48 from 192.168.1.100. >> >>anything else? >> >> > >because the 10.20.x.x network is a private network, don't i need >masquerading? i am thinking this b/c the 192.168.1.100 machine does >not flag 'no route to host' so it must know where to send the packets. >the gateway (10.20.4.48) must not be sending the packets to the >192.168.x.x net correct? > routing table is/was fine ... turned out to be iptable rules that were not masking the 192.168.1.100 address from the 10.20.x.x private net. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]