interface based conntrack entry

interface based conntrack entry

[Sohan Shetty]

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 netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: interface based conntrack entry

[Patrick McHardy]

Sohan Shetty wrote:
> 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? 

There is a patch to do something pretty similar:

http://candelatech.com/oss/conntrack_mark_with_ssyctl.patch

It allows to set default skb mark values per device and
uses those as additional key for conntrack lookups.