netdev - interface based conntrack entry

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <1C6541574A2FC447B53A6B4522B678AF015A12C5@moe.nextone.local>
Date:	Mon, 17 Mar 2008 16:13:45 -0400
From:	"Sohan Shetty" <sshetty@...tpointnetworks.com>
To:	"Netfilter Developer Mailing List" <netfilter-devel@...r.kernel.org>,
	<netdev@...r.kernel.org>
Cc:	"Paritosh Tyagi" <ptyagi@...tpointnetworks.com>
Subject: interface based conntrack entry

Forwarding query from Paritosh Tyagi to Netfilter mailing list.

--------------------------------------------------------------------
Hello,

We are using 2.6.18 version of the kernel and we have following issue related to conntrack module and Vlan interfaces.

      Ep1 (192.168.1.100)                   Eth1.100  (192.168.1.1)    (ip interface) 169.254.16.1
       |-------------------------------------------|-------------------------------|

      Ep2 (192.168.1.100)                   Eth1.101  (192.168.1.1)    (ip interface) 169.254.16.2
       |-------------------------------------------|-------------------------------|

      Here, our box is connected to two distinct networks 192.168.1/24 via a different vlan. Our application is exposing the same ip address (192.168.1.1) on both the vlans. On eth1.100 internal ip address 169.254.16.1  is configured and on eth1.101 internal ip address 169.254.16.2 is configured. 
     Ep1 and ep2 talk to 192.168.1.1 on the two vlans.
     Iptables and arptables rules are added to map incoming/outgoing ip/arp packets on eth1.100 to/from 169.254.16.1 and on eth1.101 to/from 169.254.16.2. 

    The problem we are seeing is, that when an incoming packet comes in from ep1 a conntrack entry is created for 
Proto=udp, srcip=192.168.1.100, dstip=192.168.1.1, sport=5060, dport=5060, this packet is DNAT'ed to 169.254.16.1  and our application receives it on the socket bound to that ip. However, when ep2 sends a packet, it seems that the conntrack entry matches it and the ip table NAT rule (which should map this packet to 169.254.16.2) is ignored and because of the 4-tuple match with existing udp conntrack entry, the packet is sent to 169.254.16.1. 

   Is there a patch to support the in-interface and out-interface or mark in the conntrack module? So, we can have two entries in there where the 4 tuple is the same only the interface is different? 

-paritosh

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html