RH Fedora as my gateway

Hi All


I am (trying) to run RH Fedora as my gateway for my local network. I have
a P III Compaq with one on board Intel NIC eth0 and a pci 3com NIC eth1.
I have bigpond cable on eth0 with bpalogin dhcp setup etc. Local network
consists of 192.168.0.0 /24 address range (all static ATM) with eth1 set
at 192.168.0.1 I have replaced eth1 with known good NIC, replaced cat5
cable to hub with known good cable so it must be the settings somewhere.
I have turned on IP forwarding run iptables firewall script (included
below) The problem is that I cannot ping from local network to my gateway
machine or vice versa. No problems getting the net from the gateway machine.
Any help appreciated


TIA


Steve Wall



iptables -L

Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- 192.168.0.0/24 anywhere
DROP all -- anywhere 255.255.255.255
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
LOG all -- anywhere anywhere limit: avg 3/hour burst 5 LOG level warning prefix `RED INPUT DROPPED: '

Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere 192.168.0.0/24
ACCEPT all -- 192.168.0.0/24 anywhere

Chain OUTPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere 192.168.0.0/24
ACCEPT all -- anywhere anywhere state NEW,RELATED,ESTABLISHED

route

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 * 255.255.255.0 U 0 0 0 eth1
144.XXX.XXX.0 * 255.255.252.0 U 0 0 0 eth0
169.254.0.0 * 255.255.0.0 U 0 0 0 eth1
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default CPE-144-XXX-XXX 0.0.0.0 UG 0 0 0 eth0

Steven Wall <stevenwall@bigfoot.com> wrote in message news:<pan.2004.02.15.05.29.20.1326@bigfoot.com>...
> Hi All
>
>
> I am (trying) to run RH Fedora as my gateway for my local network. I have
> a P III Compaq with one on board Intel NIC eth0 and a pci 3com NIC eth1.
> I have bigpond cable on eth0 with bpalogin dhcp setup etc. Local network
> consists of 192.168.0.0 /24 address range (all static ATM) with eth1 set

Not sure what you mean here by ATM -- not Asynchronous Transfer Mode,
surely, since this is an ethernet.

> at 192.168.0.1 I have replaced eth1 with known good NIC, replaced cat5
> cable to hub with known good cable so it must be the settings somewhere.

A hub or switch/router? What brand/model? How many boxes on LAN?
What OSs are they using? DHCP provided?

> I have turned on IP forwarding run iptables firewall script (included

Turn off the FW till you get LAN connected properly. At least flush
the tables when working on this issue.

> below) The problem is that I cannot ping from local network to my gateway

RH gw or the gw listed in route table? Both/either?

> machine or vice versa. No problems getting the net from the gateway machine.
> Any help appreciated
>
> TIA
>
> Steve Wall
>
> iptables -L
>
> Chain INPUT (policy DROP)
> target prot opt source destination
> ACCEPT all -- anywhere anywhere

Huh?

> ACCEPT all -- 192.168.0.0/24 anywhere
> DROP all -- anywhere 255.255.255.255
> ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
> LOG all -- anywhere anywhere limit: avg 3/hour burst 5 LOG level warning prefix `RED INPUT DROPPED: '
>
> Chain FORWARD (policy DROP)
> target prot opt source destination
> ACCEPT all -- anywhere 192.168.0.0/24
> ACCEPT all -- 192.168.0.0/24 anywhere
>
> Chain OUTPUT (policy DROP)
> target prot opt source destination
> ACCEPT all -- anywhere anywhere
> ACCEPT all -- anywhere 192.168.0.0/24
> ACCEPT all -- anywhere anywhere state NEW,RELATED,ESTABLISHED
>
> route
>
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 192.168.0.0 * 255.255.255.0 U 0 0 0 eth1
> 144.XXX.XXX.0 * 255.255.252.0 U 0 0 0 eth0
> 169.254.0.0 * 255.255.0.0 U 0 0 0 eth1
> 127.0.0.0 * 255.0.0.0 U 0 0 0 lo
> default CPE-144-XXX-XXX 0.0.0.0 UG 0 0 0 eth0

Where did these FW rules came from? Please, don't put them on my box!
Believe you need to re-think these -- I would not use them even
during testing/diagnosing a net problem. Better to just turn off the
FW till you get the LAN side working.

Commands used to set up the FW? You need the RH gw to MASQUERADE the
LAN boxes.

First thing is to verify connectivity between your LAN boxes and your
RH gw.

You have nets set up in routing table but what _interface_ is
associated with what net? What commands did you use to build the
table? The only gw listed is the one on your ISP's net.

The LAN boxes also must be set up correctly. What does route and
ifconfig show for them? The 169.254.0.0 on eth1 indicates a Win box
laying around taking advantage of Automatic Private IP Addressing.
I'm beginning to think that some (more than I realized?) Linux
distros/scripts are using this bane of mankind. For more info see
bottom of this thread:
http://groups.google.com/groups?hl=e...gle.com&rnum=4

You have to 'man route' carefully to understand how to build the
routing tables properly. The Net-HOWTO.html has some examples:
http://www.tldp.org/HOWTO/Net-HOWTO/
The right commands in the right sequence. This is why the commands
you used are needed.

I'm assuming you're reasonably comfortable with the commands needed
for all this -- just need to work out the "correct" way to set things
up. Right?

Basically, you need the routing table set up so that any packet that
comes in can be examined for its dest addr and then forwarded to the
correct _interface_ (identified by both IP addr and /dev/eth_x). Thus
the kernel needs info about which nets are connected/associated with
which interfaces. Once its on the correct wire, the ethernet card
will grab it. Masqing is related to but does not replace the routing
table setup. (Now you know why there are Post and Pre routing rules
in NAT -- Post = after the kernel routing table processing; Pre =
before the kernel routing table processing.)

Run route and ifconfig on each box and post output if you need any
help or questions answered. Once the LAN side is set up you can
proceed to the FW.

hth,
prg
email above disabled

On Sun, 15 Feb 2004 11:17:25 -0800, P Gentry wrote:


Hi

> Steven Wall <stevenwall@bigfoot.com> wrote in message news:<pan.2004.02.15.05.29.20.1326@bigfoot.com>...
>> Hi All
>>
>>
>> I am (trying) to run RH Fedora as my gateway for my local network. I have
>> a P III Compaq with one on board Intel NIC eth0 and a pci 3com NIC eth1.
>> I have bigpond cable on eth0 with bpalogin dhcp setup etc. Local network
>> consists of 192.168.0.0 /24 address range (all static ATM) with eth1 set
>
> Not sure what you mean here by ATM -- not Asynchronous Transfer Mode,
> surely, since this is an ethernet.

No ATM == At The Moment



>
>> at 192.168.0.1 I have replaced eth1 with known good NIC, replaced cat5
>> cable to hub with known good cable so it must be the settings somewhere.
>
> A hub or switch/router? What brand/model? How many boxes on LAN?
> What OSs are they using? DHCP provided?

9 port hub
2 PC + Notebook

! PC Fedora (My LAN Gateway and workstation)
1 PC XP (Wife and Kids)
Notebook dual boot XP Fedora

All PC's and Notebook static IP 192.168.0.x


>
>> I have turned on IP forwarding run iptables firewall script (included
>
> Turn off the FW till you get LAN connected properly. At least flush
> the tables when working on this issue.
>
>> below) The problem is that I cannot ping from local network to my gateway
>
> RH gw or the gw listed in route table? Both/either?

RH gw or outside my network for that matter

>
>> machine or vice versa. No problems getting the net from the gateway machine.
>> Any help appreciated
>>
>> TIA
>>
>> Steve Wall
>>
>> iptables -L
>>
>> Chain INPUT (policy DROP)
>> target prot opt source destination
>> ACCEPT all -- anywhere anywhere
>
> Huh?
>
>> ACCEPT all -- 192.168.0.0/24 anywhere
>> DROP all -- anywhere 255.255.255.255
>> ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
>> LOG all -- anywhere anywhere limit: avg 3/hour burst 5 LOG level warning prefix `RED INPUT DROPPED: '
>>
>> Chain FORWARD (policy DROP)
>> target prot opt source destination
>> ACCEPT all -- anywhere 192.168.0.0/24
>> ACCEPT all -- 192.168.0.0/24 anywhere
>>
>> Chain OUTPUT (policy DROP)
>> target prot opt source destination
>> ACCEPT all -- anywhere anywhere
>> ACCEPT all -- anywhere 192.168.0.0/24
>> ACCEPT all -- anywhere anywhere state NEW,RELATED,ESTABLISHED
>>
>> route
>>
>> Kernel IP routing table
>> Destination Gateway Genmask Flags Metric Ref Use Iface
>> 192.168.0.0 * 255.255.255.0 U 0 0 0 eth1
>> 144.XXX.XXX.0 * 255.255.252.0 U 0 0 0 eth0
>> 169.254.0.0 * 255.255.0.0 U 0 0 0 eth1
>> 127.0.0.0 * 255.0.0.0 U 0 0 0 lo
>> default CPE-144-XXX-XXX 0.0.0.0 UG 0 0 0 eth0
>
> Where did these FW rules came from? Please, don't put them on my box!
> Believe you need to re-think these -- I would not use them even
> during testing/diagnosing a net problem. Better to just turn off the
> FW till you get the LAN side working.
>
> Commands used to set up the FW? You need the RH gw to MASQUERADE the
> LAN boxes.

This came from a script I picked up from the net

>
> First thing is to verify connectivity between your LAN boxes and your
> RH gw.
>
> You have nets set up in routing table but what _interface_ is
> associated with what net? What commands did you use to build the
> table? The only gw listed is the one on your ISP's net.
>
> The LAN boxes also must be set up correctly. What does route and
> ifconfig show for them? The 169.254.0.0 on eth1 indicates a Win box
> laying around taking advantage of Automatic Private IP Addressing.
> I'm beginning to think that some (more than I realized?) Linux
> distros/scripts are using this bane of mankind. For more info see
> bottom of this thread:
> http://groups.google.com/groups?hl=e...gle.com&rnum=4
>
> You have to 'man route' carefully to understand how to build the
> routing tables properly. The Net-HOWTO.html has some examples:
> http://www.tldp.org/HOWTO/Net-HOWTO/
> The right commands in the right sequence. This is why the commands
> you used are needed.
>

Some good reading, thanks


> I'm assuming you're reasonably comfortable with the commands needed
> for all this -- just need to work out the "correct" way to set things
> up. Right?
>

Right

> Basically, you need the routing table set up so that any packet that
> comes in can be examined for its dest addr and then forwarded to the
> correct _interface_ (identified by both IP addr and /dev/eth_x). Thus
> the kernel needs info about which nets are connected/associated with
> which interfaces. Once its on the correct wire, the ethernet card
> will grab it. Masqing is related to but does not replace the routing
> table setup. (Now you know why there are Post and Pre routing rules
> in NAT -- Post = after the kernel routing table processing; Pre =
> before the kernel routing table processing.)
>
> Run route and ifconfig on each box and post output if you need any
> help or questions answered. Once the LAN side is set up you can
> proceed to the FW.
>

Thanks for the input. I have flushed all iptables rules and discovered
that I still have no connectivity from RH box to internal LAN :-( Next
step is to replace the NIC (again)

[root@gw sw]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

[root@gw sw]# ping 192.168.0.10
PING 192.168.0.10 (192.168.0.10) 56(84) bytes of data.
From 192.168.0.1 icmp_seq=0 Destination Host Unreachable
From 192.168.0.1 icmp_seq=1 Destination Host Unreachable
From 192.168.0.1 icmp_seq=2 Destination Host Unreachable
From 192.168.0.1 icmp_seq=3 Destination Host Unreachable
From 192.168.0.1 icmp_seq=4 Destination Host Unreachable
From 192.168.0.1 icmp_seq=5 Destination Host Unreachable

--- 192.168.0.10 ping statistics ---
8 packets transmitted, 0 received, +6 errors, 100% packet loss, time 7034ms
, pipe 4

[root@gw sw]# ping www.google.com
PING www.google.akadns.net (216.239.57.99) 56(84) bytes of data.
64 bytes from 216.239.57.99: icmp_seq=0 ttl=239 time=224 ms
64 bytes from 216.239.57.99: icmp_seq=1 ttl=239 time=216 ms
64 bytes from 216.239.57.99: icmp_seq=2 ttl=239 time=284 ms
64 bytes from 216.239.57.99: icmp_seq=3 ttl=239 time=248 ms
64 bytes from 216.239.57.99: icmp_seq=4 ttl=239 time=255 ms
64 bytes from 216.239.57.99: icmp_seq=5 ttl=239 time=241 ms

--- www.google.akadns.net ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5043ms
rtt min/avg/max/mdev = 216.407/245.190/284.789/22.290 ms, pipe 2




> hth,
> prg
> email above disabled

Steven Wall <stevenwall@bigfoot.com> wrote in message news:<pan.2004.02.16.12.59.53.269902@bigfoot.com>. ..

[snip]

> > First thing is to verify connectivity between your LAN boxes and your
> > RH gw.

Till this is cleared only the RH box will have inet access via your
ISP.

> >
> > You have nets set up in routing table but what _interface_ is
> > associated with what net? What commands did you use to build the
> > table? The only gw listed is the one on your ISP's net.
> >
> > The LAN boxes also must be set up correctly. What does route and
> > ifconfig show for them? The 169.254.0.0 on eth1 indicates a Win box
> > laying around taking advantage of Automatic Private IP Addressing.
> > I'm beginning to think that some (more than I realized?) Linux
> > distros/scripts are using this bane of mankind. For more info see
> > bottom of this thread:
> > http://groups.google.com/groups?hl=e...gle.com&rnum=4
> >
> > You have to 'man route' carefully to understand how to build the
> > routing tables properly. The Net-HOWTO.html has some examples:
> > http://www.tldp.org/HOWTO/Net-HOWTO/
> > The right commands in the right sequence. This is why the commands
> > you used are needed.
> >
> Some good reading, thanks

If you want to "hand tool" a firewall rather than using RH's Lokit,
look here for more good reading:
http://www.linuxguruz.com/iptables/
For info on Masquerading start with:
http://tldp.org/HOWTO/IP-Masquerade-HOWTO/index.html
In fact grabbing all the HOWTOs is handy -- no Linux user should be
without 'em.

>
[snip]

> > Run route and ifconfig on each box and post output if you need any
> > help or questions answered. Once the LAN side is set up you can
> > proceed to the FW.

This output is the first thing that will allow someone to spot the
source of the problem. Don't worry that your private addresses for
your LAN will in any way compromise your systems. You can always
dummy the subnet address, ie., 192.168.xxx.1, etc., though cut-n-paste
works easier if someone sends you a "solution".

>
> Thanks for the input. I have flushed all iptables rules and discovered
> that I still have no connectivity from RH box to internal LAN :-( Next
> step is to replace the NIC (again)

I really doubt it's the NIC -- check ip forwarding, each interface set
up on each box, each LAN card is directed to LAN interface on RH gw as
default route, routing tables on RH gw set correctly

> [root@gw sw]# iptables -L
> Chain INPUT (policy ACCEPT)
> target prot opt source destination
>
> Chain FORWARD (policy ACCEPT)
> target prot opt source destination
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source destination

Be aware that this leaves your RH & anything else downstream without
_any_ firewall. Lokit that comes with RH is a weeney of a firewall,
but it's adequate for now and better than nothing. Also check that
you're not running any inet services like httpd, ftpd, nfs, etc.

>
> [root@gw sw]# ping 192.168.0.10
> PING 192.168.0.10 (192.168.0.10) 56(84) bytes of data.
> From 192.168.0.1 icmp_seq=0 Destination Host Unreachable
[snip]
> --- 192.168.0.10 ping statistics ---
> 8 packets transmitted, 0 received, +6 errors, 100% packet loss, time 7034ms

Because the kernel doesn't know which interface to correctly forward
these to. It's using the ISP's gw which couldn't know how to route
your LAN -- and private addresses aren't routable on the inet anyway.

> [root@gw sw]# ping www.google.com
> PING www.google.akadns.net (216.239.57.99) 56(84) bytes of data.
> 64 bytes from 216.239.57.99: icmp_seq=0 ttl=239 time=224 ms
[snip]
> --- www.google.akadns.net ping statistics ---
> 6 packets transmitted, 6 received, 0% packet loss, time 5043ms
> rtt min/avg/max/mdev = 216.407/245.190/284.789/22.290 ms, pipe 2

This time the RH kernel is correctly forwarding these packets out the
interface connected to your ISP, through the default route, and the
ISP's router is sending these on out to the inet.
I expected both these results from your symptoms.

hth,
prg
email above disabled