netfilter buglog - Dec 2009 - [Bug 625] New: IN/SRC, OUT/DST backwards in LOG when used with a VLAN

http://bugzilla.netfilter.org/show_bug.cgi?id=625

           Summary: IN/SRC, OUT/DST backwards in LOG when used with a VLAN
           Product: iptables
           Version: 1.3.5
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: blocker
          Priority: P4
         Component: iptables
        AssignedTo: laforge at netfilter.org
        ReportedBy: ToddAndMargo at verizon.net


Hi All,

eth1 = Internet
eth0 = internal net
eth0.5 = VLAN attached to eth0

$ rpm -qa \*iptables\*
iptables-1.3.5-5.3.el5_4.1

$ uname -r
2.6.18-164.6.1.el5

$ cat /etc/redhat-release
CentOS release 5.4 (Final)

Reproduced under both 32 bit and 64 bit versions of CentOS 5.4

I do believe I have uncovered a bug in the "LOG" portion of iptables. 
Please
note that everything is correct except for the way the LOG displays in and out
and src and dst.  Also, I am not asking for support; I am just reporting a bug.
 I could also be blind, but I don't think so.

http://bugzilla.netfilter.org/show_bug.cgi?id=625


ToddAndMargo at verizon.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|IN/SRC, OUT/DST backwards in|IN/SRC, OUT/DST, SPT/DPT are
                   |LOG when used with a VLAN   |backwards in LOG when used
                   |                            |with a VLAN




------- Comment #1 from ToddAndMargo at verizon.net  2009-12-12 05:13 -------
Here is the LOG from when I was trying to create a rule to allow Cobian's
eMail
report out.  This was triggered by Cobian's SMTP configuration
"test":

Nov  3 18:13:52 server kernel: dsl-for Everything Else IN=eth1 OUT=eth0.5
SRC=207.228.35.39 DST=192.168.254.12 LEN=52 TOS=0x00 PREC=0x00 TTL=61 ID=0 DF
PROTO=TCP SPT=25 DPT=49709 WINDOW=5840 RES=0x00 ACK SYN URGP=0 

Again, note that IN and OUT, SRC and DST are backwards.  I actually opened a
trouble ticket at my ISP (207.228.35.39) as to why they were sending me a SYN
packet on port 25.  (Into everyone's life a little humility must fall.)

By the way, on the above the SPT and DPT are backwards as well.


-- 
Configure bugmail: http://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.netfilter.org/show_bug.cgi?id=625


kernel at linuxace.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kernel at linuxace.com
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




------- Comment #2 from kernel at linuxace.com  2009-12-16 20:19 -------
There is absolutely nothing wrong with iptables here - only your understanding
of what is occurring.  Note in each logged packet the flags "ACK SYN"
are
present, meaning this is a _RESPONSE_ to your request.  As such, the in/out
&
src/dst are 100% accurate.  

As further evidence, look at the source port in the SMTP log entry: "SPT=25
DPT=49709" which shows the server is responding from its port 25 to your
ephemeral port.  

You probably are missing a "-m state --state ESTABLISHED,RELATED" at
the top of
your ruleset.  Regardless, such a user error is not a bug, and this bug will be
closed.  If you have further questions, ask for assistance on the iptables
_USER_ mailing list.


-- 
Configure bugmail: http://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.netfilter.org/show_bug.cgi?id=625





------- Comment #3 from ToddAndMargo at verizon.net  2009-12-17 19:21 -------
(In reply to comment #2)
> Note in each logged packet the flags "ACK SYN" are
> present, meaning this is a _RESPONSE_ to your request.
Hi Phil,

You are correct.  I missed the "ACK SYN".  I thought I was only
looking at a
"SYN".  Now my next project is to figure out how a "SYN"
packet with no rules
leaked out of my firewall.

Thank you for pointing this out to me.  Hopefully the next time I write you, it
will be an actual bug.

-T


-- 
Configure bugmail: http://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.