Very Strange Behavior in INPUT Chain!
Frost
frost@engen.com
Tue, 14 Aug 2001 09:40:21 -0700
This is a multi-part message in MIME format.
------=_NextPart_000_0019_01C124A5.22C19400
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
It would appear to me that your response "should" be incorrect by design. As
the packet passes through PREROUTING and arrives at IN-ROUTE, it should not be
passed to the incorrect interface's INPUT chain as you show. Even though the
packet arrives on the external (pvc0 in this case) interface, it's destination
is the INPUT chain of the internal interface (eth0 in this case). Are you
saying that the packet flows like this PREROUTING --> In-Route --> INPUT
pvc0 --> OUTPUT pvc0 --> INPUT eth0? I would just like to understand the flow
entirely.
Thank you for replying!!
Harv
-----Original Message-----
From: Arnoud [mailto:a.buurman@wxs.nl]
Sent: Tuesday, August 14, 2001 9:12 AM
To: 'Frost'
Cc: netfilter-admin@lists.samba.org
Subject: RE: Very Strange Behavior in INPUT Chain!
As far as I know,
the trafficis stil comming IN through interface pvc0 even though there 's not
your Ip nummer.... But that card is Actualy putting the packets into the stack,
so -i pvc0 should work.
Don't think IP in this case , but think pysical card....
Arnoud
-----Original Message-----
From: netfilter-admin@lists.samba.org
[mailto:netfilter-admin@lists.samba.org]On Behalf Of Frost
Sent: Tuesday, August 14, 2001 5:08 PM
To: Netfilter
Subject: Very Strange Behavior in INPUT Chain!
Hello all,
I have kind of a different setup than perhaps the norm. My Linux server has
one ethernet card (eth0) and one Frame Relay Card (pvc0) configured and working.
My problem is that I don't want anyone connecting to the IP address of the
Frame card (pvc0) because this is just a serial IP assigned by our provider. I
wish to have the public connect to our internal public IP address on eth0 for
public services ie. port 80 as an example.
* Version 1 (doesn't work)
iptables -A INPUT -i $INTIF -p tcp --syn -m state --state NEW \
-s $UNIVERSE --sport $UNPRIVPORTS \
-d $INTIP --dport http -j ACCEPT
* Version 2 (does work)
iptables -A INPUT -p tcp --syn -m state --state NEW \
-s $UNIVERSE --sport $UNPRIVPORTS \
-d $INTIP --dport http -j ACCEPT
My question is why does specifying ALL interfaces work (ver 2) and
specifying the actual interface (ver 1) doesn't. If I understand the flow
correctly, when packets reach the IN-Route stage, will they not be routed to the
INPUT chain of the Internal interface which is their destination? I can't
imagine that the FORWARD chain would even be involved as the destination IS this
server. Everything is working specifying ALL interfaces but I'm puzzled as to
why and would appreciate hearing from someone who might shed some light. Thanks
a million.
Regards,
Harv
____________________________________________________________________
Harv Frost En.gen (a Division of J. River, Inc.)
mailto:frost@engen.com 2727 W. Baseline Rd #13
http://www.engen.com Tempe, AZ 85283
ftp://ftp.engen.com Tel: 602-438-1110
------=_NextPart_000_0019_01C124A5.22C19400
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4616.200" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D160463216-14082001>It would=20
appear to me that your response "should" be incorrect by design. =
As the=20
packet passes through PREROUTING and arrives at IN-ROUTE, it should not =
be=20
passed to the incorrect interface's INPUT chain as you show. Even =
though=20
the packet arrives on the external (pvc0 in this case) interface, it's=20
destination is the INPUT chain of the internal interface (eth0 in this=20
case). Are you saying that the packet flows like this PREROUTING =
-->=20
In-Route --> INPUT pvc0 --> OUTPUT pvc0 --> INPUT eth0? I =
would=20
just like to understand the flow entirely.</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D160463216-14082001></SPAN></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D160463216-14082001>Thank you=20
for replying!!</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D160463216-14082001>Harv</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px =
solid; MARGIN-RIGHT: 0px">
<DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B> Arnoud=20
[mailto:a.buurman@wxs.nl]<BR><B>Sent:</B> Tuesday, August 14, 2001 =
9:12=20
AM<BR><B>To:</B> 'Frost'<BR><B>Cc:</B>=20
netfilter-admin@lists.samba.org<BR><B>Subject:</B> RE: Very Strange =
Behavior=20
in INPUT Chain!<BR><BR></FONT></DIV>
<DIV><SPAN class=3D830450916-14082001><FONT face=3DArial =
color=3D#0000ff size=3D2>As=20
far as I know,</FONT></SPAN></DIV>
<DIV><SPAN class=3D830450916-14082001><FONT face=3DArial =
color=3D#0000ff size=3D2>the=20
trafficis stil comming IN through interface pvc0 even though there 's =
not your=20
Ip nummer.... But that card is Actualy putting the packets into the =
stack, so=20
-i pvc0 should work.</FONT></SPAN></DIV>
<DIV><SPAN class=3D830450916-14082001><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D830450916-14082001><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Don't think IP in this case , but think pysical=20
card....</FONT></SPAN></DIV>
<DIV><SPAN class=3D830450916-14082001><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D830450916-14082001><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Arnoud</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B>=20
netfilter-admin@lists.samba.org=20
[mailto:netfilter-admin@lists.samba.org]<B>On Behalf Of=20
</B>Frost<BR><B>Sent:</B> Tuesday, August 14, 2001 5:08 =
PM<BR><B>To:</B>=20
Netfilter<BR><B>Subject:</B> Very Strange Behavior in INPUT=20
Chain!<BR><BR></FONT></DIV>
<DIV><SPAN class=3D830184814-14082001><FONT face=3D"Courier New" =
size=3D2>Hello=20
all,</FONT></SPAN></DIV>
<DIV><SPAN class=3D830184814-14082001><FONT face=3D"Courier New" =
size=3D2>I have=20
kind of a different setup than perhaps the norm. My Linux =
server has=20
one ethernet card (eth0) and one Frame Relay Card (pvc0) configured =
and=20
working.</FONT></SPAN></DIV>
<DIV><SPAN class=3D830184814-14082001><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D830184814-14082001><FONT face=3D"Courier New" =
size=3D2>My=20
problem is that I don't want anyone connecting to the IP address of =
the=20
Frame card (pvc0) because this is just a serial IP assigned by =
our=20
provider. I wish to have the public connect to our internal =
public IP=20
address on eth0 for public services ie. port 80 as an=20
example.</FONT></SPAN></DIV>
<DIV><SPAN class=3D830184814-14082001><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D830184814-14082001><FONT face=3D"Courier New" =
size=3D2>*=20
Version 1 (doesn't work)</FONT></SPAN></DIV>
<DIV><SPAN class=3D830184814-14082001><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D830184814-14082001><FONT face=3D"Courier New" =
size=3D2>iptables=20
-A INPUT -i $INTIF -p tcp --syn -m state --state NEW=20
\<BR> -s $UNIVERSE --sport =
$UNPRIVPORTS \<BR> -d =
$INTIP=20
--dport http -j ACCEPT</FONT></SPAN></DIV>
<DIV><SPAN class=3D830184814-14082001><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D830184814-14082001><FONT face=3D"Courier New" =
size=3D2>*=20
Version 2 (does work)</FONT></SPAN></DIV>
<DIV><SPAN class=3D830184814-14082001><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D830184814-14082001><FONT face=3D"Courier New" =
size=3D2>iptables=20
-A INPUT -p tcp --syn -m state --state NEW=20
\<BR> -s $UNIVERSE --sport =
$UNPRIVPORTS \<BR> -d =
$INTIP=20
--dport http -j ACCEPT<BR></FONT></SPAN></DIV>
<DIV><SPAN class=3D830184814-14082001><FONT face=3D"Courier New" =
size=3D2>My=20
question is why does specifying ALL interfaces work (ver 2) and =
specifying=20
the actual interface (ver 1) doesn't. If I understand the flow =
correctly, when packets reach the IN-Route stage, will they not be =
routed to=20
the INPUT chain of the Internal interface which is their =
destination? =20
I can't imagine that the FORWARD chain would even be involved as the =
destination IS this server. Everything is working specifying =
ALL=20
interfaces but I'm puzzled as to why and would appreciate hearing =
from=20
someone who might shed some light. Thanks a=20
million.</FONT></SPAN></DIV>
<DIV><SPAN class=3D830184814-14082001><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D830184814-14082001><FONT face=3D"Courier New"=20
size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D830184814-14082001><FONT face=3D"Courier New"=20
size=3D2>Harv</FONT></SPAN></DIV>
<DIV><SPAN class=3D830184814-14082001><FONT face=3D"Courier New" =
size=3D2>
<P><FONT face=3D"Courier New"=20
=
size=3D2>________________________________________________________________=
____<BR>Harv=20
=
Frost &n=
bsp; =20
En.gen (a Division of J. River, Inc.)<BR></FONT><A target=3D_blank=20
href=3D"mailto:frost@engen.com"><FONT face=3D"Courier New"=20
size=3D2>mailto:frost@engen.com</FONT></A><FONT face=3D"Courier New" =
size=3D2> 2727 W. =
Baseline Rd=20
#13<BR></FONT><A target=3D_blank =
href=3D"http://www.engen.com/"><FONT=20
face=3D"Courier New" size=3D2>http://www.engen.com</FONT></A><FONT=20
face=3D"Courier New"=20
=
size=3D2> =
Tempe,=20
AZ 85283<BR></FONT><A target=3D_blank =
href=3D"ftp://ftp.engen.com/"><FONT=20
face=3D"Courier New" size=3D2>ftp://ftp.engen.com</FONT></A><FONT=20
face=3D"Courier New"=20
=
size=3D2> &nbs=
p;=20
Tel: 602-438-1110 </FONT></P></DIV>
=
<DIV><BR></DIV></BLOCKQUOTE></BLOCKQUOTE></FONT></SPAN></BODY></HTML>
------=_NextPart_000_0019_01C124A5.22C19400--