Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I fear I led you astray in post #25. Following my example, the rule you used for accepting LAN connections only accepts TCP packets, blocking ICMP (used for pings) and UDP (used for DNS resolution). Below is your script with the changed rule in red.
I am not sure this accounts for everything I saw in your log, but it is at least a good start. Let me know if there are still problems, and I apologize for my mistake.
Code:
#!/bin/sh
# Firewall script
# Define interfaces and IP addresses for Internet and LAN
EXTIF="eth0"
EXTIF_IP="200.17.xxx.xxx"
INTIF="eth1"
INTIF_NET="192.168.30.0/24"
# Define the TCP ports the should be accessible from Internet and LAN
# These should be space separated, quoted strings.
# Internet Access:
# TCP UDP protocol
# 80 http
# 443 https
# 25 smtp (mail)
# 53 53 DNS
EXT_TCP="80 443 25 53"
EXT_UDP="53"
# Internal LAN Access: all ports open
# Command definitions:
IPTABLES="/sbin/iptables"
MODPROBE="/sbin/modprobe"
# Set policies for each chain
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P FORWARD DROP
$IPTABLES -t nat -P PREROUTING ACCEPT
$IPTABLES -t nat -P POSTROUTING ACCEPT
$IPTABLES -t nat -P OUTPUT ACCEPT
$IPTABLES -t mangle -P PREROUTING ACCEPT
$IPTABLES -t mangle -P OUTPUT ACCEPT
# Flush all standard chains and delete all user chains
$IPTABLES -F
$IPTABLES -F -t nat
$IPTABLES -F -t mangle
$IPTABLES -X
$IPTABLES -X -t nat
$IPTABLES -X -t mangle
# Load modules for iptables
$MODPROBE ip_conntrack_ftp
$MODPROBE ip_nat_ftp
$MODPROBE ip_conntrack_irc
$MODPROBE ip_nat_irc
# -------------- INPUT Chain Firewall Rules ---------------
#
# Accept all established connections and all loopback packets
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -i lo -j ACCEPT
# Rules which allow new Internet connections
for port in $EXT_TCP; do
$IPTABLES -A INPUT -p TCP -i $EXTIF --dport $port \
-m state --state NEW -j ACCEPT
done
for port in $EXT_UDP; do
$IPTABLES -A INPUT -p UDP -i $EXTIF --dport $port \
-m state --state NEW -j ACCEPT
done
# Rules which allow new LAN connections
$IPTABLES -A INPUT -s $INTIF_NET \
-m state --state NEW -j ACCEPT
# Policy drops everything else. But first log them.
$IPTABLES -A INPUT -j LOG --log-prefix "INPUT DROP: "
# -------------- FORWARD Chain Firewall Rules ---------------
#
# Accept establish connections.
# Accept new connections from $LAN that are destined for the Internet
# Log any packets that will be dropped
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -o $EXTIF -s $INTIF_NET \
-m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -j LOG --log-prefix "FORWARD DROP: "
# -------------- POSTROUTING Chain Firewall Rules ---------------
#
# SNAT all LAN originated packets destined for the Internet.
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -s $INTIF_NET \
-j SNAT --to $EXTIF_IP
Last edited by blackhole54; 08-08-2006 at 10:41 AM.
I beg to differ, I should apologize for not seen this.
Thank you very much for your prompt reply.
It seems to be working fine now. However, I am seen some forward drops, which I was not expecting. I am sorry for the length of the log I included, but I wanted to give the complete information.
Code:
Aug 8 14:22:53 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=64.72.124.159 DST=200.17.xxx.xxx LEN=1500 TOS=0x00 PREC=0x00 TTL=49 ID=44860 DF PROTO=TCP SPT=80 DPT=1241 WINDOW=1728 RES=0x00 ACK URGP=0
Aug 8 14:23:09 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=64.72.124.159 DST=200.17.xxx.xxx LEN=1500 TOS=0x00 PREC=0x00 TTL=49 ID=52813 DF PROTO=TCP SPT=80 DPT=1248 WINDOW=1728 RES=0x00 ACK URGP=0
Aug 8 14:23:16 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=207.68.178.61 DST=200.17.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=240 ID=59450 PROTO=TCP SPT=80 DPT=4955 WINDOW=9300 RES=0x00 RST URGP=0
Aug 8 14:23:27 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=23048 DF PROTO=TCP SPT=1248 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0
Aug 8 14:23:27 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=23058 DF PROTO=TCP SPT=1241 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0
Aug 8 14:23:30 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=23235 DF PROTO=TCP SPT=1241 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0
Aug 8 14:23:30 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=23236 DF PROTO=TCP SPT=1248 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0
Aug 8 14:23:36 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=23803 DF PROTO=TCP SPT=1241 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0
Aug 8 14:23:36 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=23804 DF PROTO=TCP SPT=1248 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0
Aug 8 14:23:47 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=24933 DF PROTO=TCP SPT=1241 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0
Aug 8 14:23:47 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=24934 DF PROTO=TCP SPT=1248 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0
Aug 8 14:24:02 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=64.92.212.235 DST=200.17.xxx.xxx LEN=1500 TOS=0x00 PREC=0x00 TTL=49 ID=3070 DF PROTO=TCP SPT=80 DPT=6235 WINDOW=5840 RES=0x00 ACK URGP=0
Aug 8 14:24:10 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=26068 DF PROTO=TCP SPT=1241 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0
Aug 8 14:24:10 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=26069 DF PROTO=TCP SPT=1248 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0
Aug 8 14:24:13 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=64.92.212.235 DST=200.17.xxx.xxx LEN=1500 TOS=0x00 PREC=0x00 TTL=49 ID=3072 DF PROTO=TCP SPT=80 DPT=6235 WINDOW=5840 RES=0x00 ACK URGP=0
Aug 8 14:24:41 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.14.123.140 LEN=449 TOS=0x00 PREC=0x00 TTL=63 ID=26248 DF PROTO=TCP SPT=1164 DPT=80 WINDOW=64240 RES=0x00 ACK PSH FIN URGP=0
Aug 8 14:24:47 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=217.146.185.136 DST=200.17.xxx.xxx LEN=64 TOS=0x00 PREC=0x00 TTL=49 ID=30573 PROTO=ICMP TYPE=8 CODE=0 ID=10678 SEQ=0
Aug 8 14:24:47 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=217.146.185.136 DST=200.17.xxx.xxx LEN=64 TOS=0x00 PREC=0x00 TTL=49 ID=31256 PROTO=ICMP TYPE=8 CODE=0 ID=10678 SEQ=256
Aug 8 14:24:48 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=217.146.185.136 DST=200.17.xxx.xxx LEN=64 TOS=0x00 PREC=0x00 TTL=49 ID=31855 PROTO=ICMP TYPE=8 CODE=0 ID=10678 SEQ=512
Aug 8 14:24:48 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=217.146.185.136 DST=200.17.xxx.xxx LEN=64 TOS=0x00 PREC=0x00 TTL=49 ID=32604 PROTO=ICMP TYPE=8 CODE=0 ID=10678 SEQ=768
Aug 8 14:24:57 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=26329 DF PROTO=TCP SPT=1241 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0
Aug 8 14:24:57 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=26330 DF PROTO=TCP SPT=1248 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0
Aug 8 14:25:18 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.233.185.83 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=26496 DF PROTO=TCP SPT=1614 DPT=80 WINDOW=65073 RES=0x00 ACK FIN URGP=0
Aug 8 14:25:22 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=64.92.212.235 DST=200.17.xxx.xxx LEN=1500 TOS=0x00 PREC=0x00 TTL=49 ID=3076 DF PROTO=TCP SPT=80 DPT=6235 WINDOW=5840 RES=0x00 ACK URGP=0
Aug 8 14:25:41 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.86.91.82 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=27434 DF PROTO=TCP SPT=1574 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0
Aug 8 14:25:43 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.233.185.83 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=27514 DF PROTO=TCP SPT=1614 DPT=80 WINDOW=65073 RES=0x00 ACK FIN URGP=0
Aug 8 14:26:16 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=64.86.91.82 DST=200.17.xxx.xxx LEN=1500 TOS=0x00 PREC=0x00 TTL=50 ID=26199 DF PROTO=TCP SPT=80 DPT=1639 WINDOW=32850 RES=0x00 ACK URGP=0
Aug 8 14:26:34 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.233.185.83 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=31365 DF PROTO=TCP SPT=1614 DPT=80 WINDOW=65073 RES=0x00 ACK FIN URGP=0
Aug 8 14:26:50 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=64.86.91.82 DST=200.17.xxx.xxx LEN=1500 TOS=0x00 PREC=0x00 TTL=50 ID=51575 DF PROTO=TCP SPT=80 DPT=1639 WINDOW=32850 RES=0x00 ACK URGP=0
Aug 8 14:26:54 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=64.92.212.235 DST=200.17.xxx.xxx LEN=1500 TOS=0x00 PREC=0x00 TTL=49 ID=3078 DF PROTO=TCP SPT=80 DPT=6235 WINDOW=5840 RES=0x00 ACK URGP=0
Aug 8 14:27:35 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=64.86.91.82 DST=200.17.xxx.xxx LEN=1500 TOS=0x00 PREC=0x00 TTL=50 ID=59680 DF PROTO=TCP SPT=80 DPT=1639 WINDOW=32850 RES=0x00 ACK URGP=0
Aug 8 14:27:57 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.14.123.138 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=39933 DF PROTO=TCP SPT=1147 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0
hi heberrdacruz... i've tweaked the latest version of the script (post #31)... they are minor tweaks, but they should be worthwhile...
it is my understanding that you've in fact normalized the physical connections to your NICs, right?? if that's the case, then this should work fine:
Code:
#!/bin/sh
EXTIF="eth0"
EXTIF_IP="200.17.xxx.xxx"
INTIF="eth1"
INTIF_NET="192.168.30.0/24"
EXT_TCP_PORTS="80 443 25 53"
EXT_UDP_PORTS="53"
IPTABLES="/sbin/iptables"
MODPROBE="/sbin/modprobe"
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -t mangle -P PREROUTING ACCEPT
$IPTABLES -t mangle -P INPUT ACCEPT
$IPTABLES -t mangle -P FORWARD ACCEPT
$IPTABLES -t mangle -P OUTPUT ACCEPT
$IPTABLES -t mangle -P POSTROUTING ACCEPT
$IPTABLES -t nat -P PREROUTING ACCEPT
$IPTABLES -t nat -P POSTROUTING ACCEPT
$IPTABLES -t nat -P OUTPUT ACCEPT
$IPTABLES -F
$IPTABLES -F -t nat
$IPTABLES -F -t mangle
$IPTABLES -X
$IPTABLES -X -t nat
$IPTABLES -X -t mangle
$MODPROBE ip_conntrack_ftp
$MODPROBE ip_nat_ftp
$MODPROBE ip_conntrack_irc
$MODPROBE ip_nat_irc
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -i lo -j ACCEPT
for port in $EXT_TCP_PORTS; do
$IPTABLES -A INPUT -p TCP -i $EXTIF --dport $port \
-m state --state NEW -j ACCEPT
done
for port in $EXT_UDP_PORTS; do
$IPTABLES -A INPUT -p UDP -i $EXTIF --dport $port \
-m state --state NEW -j ACCEPT
done
$IPTABLES -A INPUT -i $INTIF -s $INTIF_NET \
-m state --state NEW -j ACCEPT
$IPTABLES -A INPUT -j LOG --log-prefix "INPUT DROP: "
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -s $INTIF_NET \
-m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -j LOG --log-prefix "FORWARD DROP: "
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j SNAT \
--to-source $EXTIF_IP
not sure what to tell you about those FORWARD DROPs you are seeing... perhaps blackhole54 does... they might just be old connections which weren't in the state table anymore... had you just rebooted?? have you experienced weird behavior from clients on the LAN during these DROPs??
interesting... i've gone over the script line by line and can't find anything out of the ordinary... hmmm... it should be pointed-out that most of those are ACK/FIN packets, which are part of the connection termination phase...
which distro and kernel versions you are running??
Code:
uname -a
i ask cuz if you're running something extremely old and unmaintained, for example, then that *might* have something to do with it... i'm just spitballing, of course... for now, i can't really think of any other explanation of why you'd get so many DROPs from within... anyody??
Further analysis showed that all but two of the forward drops were to DPT=80. The exceptions were
Code:
Aug 8 10:15:07 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.92 DST=207.46.27.77 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=60794 DF PROTO=TCP SPT=39430 DPT=1863 WINDOW=16022 RES=0x00 ACK FIN URGP=0
Aug 8 14:44:54 newton kernel: FORWARD DROP: IN=eth1 OUT=eth1 SRC=192.168.30.148 DST=169.254.242.28 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=23198 DF PROTO=TCP SPT=1465 DPT=1135 WINDOW=65535 RES=0x00 SYN URGP=0
I am not sure why the first packet got dropped. Along with win32sux I'lll note that it is ACK-FIN (I'm not totally sure of the shutdown handshake) and wonder if the kernel no longer considers the connection active. Maybe this is a repeat packet from an impatient client and the first one shut down the connection? Win32sux, is that plausable?
The second packet has to do with that (weird?) entry in your routing table:
Code:
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
which routes this packet out eth1.
The rule in the FORWARD chain for NEW packets only accepts them if the are going out eth0. You could let packets like this out by removing "-o $EXTIF" from that rule. Since I don't understand why your routing table contains that entry, I can't comment whether you should do this. If you do wan't to let this packet through, I would wonder whether it should also be SNATed.
I am also wondering about all of those packets the INPUT chain is blocking The echo requests (pings) being blocked is probably a good thing (at least I like to block those). But what are all of those SPT=80's. Is that just somebody's mischief, or are you trying to do web access from newton? (EDIT: I should clarify -- I mean are you using a browser on newton trying to access some other website.)
@win32sux
Quote:
Originally Posted by win32sux
... cuz if you're running something _extremely_ old, for example, then that *might* have something to do with it...
heberrdacruz can of course answer this for you, but since he probably won't be posting till morning, I thought I would let you know he is running FC5 on newton and RH9 on another box he has sometimes mentioned.
Last edited by blackhole54; 08-09-2006 at 12:24 AM.
I am not sure why the first packet got dropped. Along with win32sux I'lll note that it is ACK-FIN (I'm not totally sure of the shutdown handshake) and wonder if the kernel no longer considers the connection active. Maybe this is a repeat packet from an impatient client and the first one shut down the connection? Win32sux, is that plausable?
sounds plausible to me, although i would then wonder why the ACK wasn't received (making the FIN/ACK get re-sent)...
Quote:
The second packet has to do with that (weird?) entry in your routing table:
Code:
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
which routes this packet out eth1.
The rule in the FORWARD chain for NEW packets only accepts them if the are going out eth0. You could let packets like this out by removing "-o $EXTIF" from that rule. Since I don't understand why your routing table contains that entry, I can't comment whether you should do this. If you do wan't to let this packet through, I would wonder whether it should also be SNATed.
yeah, i really think that said entry should be removed from the table, since it seems it might be bogus, from what one could interpret from this post:
Quote:
Originally Posted by heberrdacruz
I don’t know where the 169 ... comes from.
IMHO the outgoing interface specifier should be left there, for maximum security and control... if special routing is needed for the "weird" packets, a rule should be added specially for them, while leaving the main rule intact... this is just my opinion, of course...
Quote:
@win32sux
heberrdacruz can of course answer this for you, but since he probably won't be posting till morning, I thought I would let you know he is running FC5 on newton and RH9 on another box he has sometimes mentioned.
oh, okay... FC5 is super new so no way it's an aged kernel issue... thanks for clarifying!!!
sounds plausible to me, although i would then wonder why the ACK wasn't received (making the FIN/ACK get re-sent)...
I was thinking it might be a timing issue. I.e. the ACK was coming back through newton just about the time the client decided to resend. I.e. I'm trying to blame this on Internet latency (or weird MS programing! -- at least some clients are MS). The other idea that occured to me about this (as well as an entry in the log entries posted in #30) was wondering if it could be considered an "invalid" packet. But I've never researched what that really means.
Thank you very much for all the comments. A lot has happened since my last entry.
Thank you, win32sux, for the enlightment on TCP protocol. I have much to learn.
Quote:
Originally Posted by win32sux
which distro and kernel versions you are running??
This entry is a mystery to me. I didn’t create it and I can’t figure how to remove, or even if I should remove it.
Quote:
Originally Posted by blackhole54
are you using a browser on newton trying to access some other website.)
Not to my knowledge. This machine does not run GUI (it start on runlevel 3). It runs squid, however.
Quote:
Originally Posted by win32sux
yeah, I really think that said entry should be removed from the table, since it seems it might be bogus,
Do you mean the 169.254.0.0 entry from the network?
Quote:
Originally Posted by win32sux
IMHO the outgoing interface specifier should be left there,
Do you mean the iptable rule?
Quote:
Originally Posted by blackhole54
I was thinking it might be a timing issue.
Is there anything I can do about that?
Would it make any difference if I saved the rules specified by the script as standard for iptables and rebooted the computer?
This entry is a mystery to me. I didn’t create it and I can’t figure how to remove, or even if I should remove it.
i don't have a red hat box to try this on... but i did a quick google and it seems this 169.254.0.0 thing might be due to zerconf... according to what i read, to disable it you would put a line like:
Code:
NOZEROCONF=yes
inside your /etc/sysconfig/network file... i'm pretty sure you would then need to restart the network, or reboot...
Quote:
Do you mean the 169.254.0.0 entry from the network?
yeah, as described above...
Quote:
Do you mean the iptable rule?
yeah, i was referring to this rule in particular:
Code:
$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -s $INTIF_NET \
-m state --state NEW -j ACCEPT
in other words, my opinion was/is that you should leave it like that...
That might account for the SPT=80 packets, but I don't know why they would be dropped. (Unless they really are malicious packets unrelated to your machine.) Does sqid seem to be operating normally?
This entry [169.254.0.0] is a mystery to me. I didn’t create it and I can’t figure how to remove, or even if I should remove it.
If win32sux's suggestion about zerconf doesn't work I have something else for you to try if you can take eth1 offline momentarily (no more than 2 minutes I would imagine).
This is based on the way the old RedHat distros used to do things, so it is possible things are different with FC. But it might be worth checking out. I want you to look at the way the routing table changes as you take eth1 down and bring it back up. You should log in as root. If you use su, use the dash option so that you actually use root's PATH variable. (To minimize eth1 downtime you might want to check that the commands used below actually can be found using the which command before taking eth1 offline.) So as root do the following:
Code:
route -n
ifdown eth1
route -n
ifup eth1
route -n
I would expect to see all routes involving eth1 to vanish when you take eth1 down. The question is whether that 169.254 line reappears when you bring it back up. If it doesn't reappear we need to look elsewhere. If it does reappear, do the following.
See if you have a file called /sbin/ifup-local, and if so,see whether this script creates this route. (It is probably a small file if it exists.) Also check the file /etc/sysconfig/network-scripts/ifup-post using the search function in you favorite editor or pager to search for 169. Also look at a file called /etc/sysconfig/network-scripts/ifcfg-eth1 to see if there is any reference to this subnet. The ifup-local file is an optional file (it may not exist.). If the last two files don't exist, then FC works differently from the old RH distros.
This worked fine, thank you. The 169.254.0.0 entry has disappeared now. It is odd this business. I had never heard about it. It exists on RH 9, too.
Quote:
Originally Posted by win32sux
yeah, i was referring to this rule in particular:
Code:
$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -s $INTIF_NET \
-m state --state NEW -j ACCEPT
in other words, my opinion was/is that you should leave it like that..
Sure. It is still there.
Thank you blackhole54 for your suggestion. As win32sux's suggestion regarding about zeroconf worked I didn’t think it was necessary to try yours.
I run the firewall script and using iptables-save saved the rules on a file and copied to /etc/sysconfig/iptables, so that it became the standard iptables rule. Did I do right?
In the process I noticed there is another file /etc/sysconfig/iptables-config. Removing the comments and blank lines its contents are below.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Following my example, the rule you used for accepting LAN connections only accepts TCP packets, blocking ICMP (used for pings) and UDP (used for DNS resolution). Below is your script with the changed rule in red.
