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

[Eric Leblond]

[-- Attachment #1: Type: text/plain, Size: 1965 bytes --]

Hello,

On Monday, 2008 March 17 at 16:13:45 -0400, 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.
>       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 no such patch. A similar question was asked some time ago and
if I remember well, the conclusion was the setup was too weird from a 
firewall point-of-view.
Suggestion was made to use some virtualization solution.

BR,
-- 
Eric Leblond
INL: http://www.inl.fr/
NuFW: http://www.nufw.org/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: interface based conntrack entry

[Jan Engelhardt]

On Mar 18 2008 00:25, Eric Leblond wrote:
>On Monday, 2008 March 17 at 16:13:45 -0400, Sohan Shetty wrote:
>> Forwarding query from Paritosh Tyagi to Netfilter mailing list.
>> 
>> 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 no such patch. A similar question was asked some time ago and
>if I remember well, the conclusion was the setup was too weird from a 
>firewall point-of-view.
>Suggestion was made to use some virtualization solution.

I believe that nf_conntrack deliberately does not use interfaces
as tuple parts because packets may very well come in on
and/or leave on different interfaces (routing on fwmark).

Re: interface based conntrack entry

[Benny Amorsen]

Jan Engelhardt <jengelh@computergmbh.de> writes:

> I believe that nf_conntrack deliberately does not use interfaces
> as tuple parts because packets may very well come in on
> and/or leave on different interfaces (routing on fwmark).

As a reminder, this makes it very important that Linux firewalls have
rp_filter set to true -- or that they drop packets coming in on the
"wrong" interface BEFORE the customary -A FORWARD -m state --state
RELATED,ESTABLISHED -j ACCEPT


/Benny

Re: interface based conntrack entry

[Pascal Hambourg]

Hello,

Eric Leblond a écrit :
> 
> On Monday, 2008 March 17 at 16:13:45 -0400, Sohan Shetty wrote:
>>
>> Here, our box is connected to two distinct networks 192.168.1/24 [...]
> 
> There is no such patch. A similar question was asked some time ago and
> if I remember well, the conclusion was the setup was too weird from a 
> firewall point-of-view.

s/weird/broken by design/

The purpose of prefixes is to identify networks. If you use the same 
prefix on distinct networks, expect trouble.
--
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

[Eric Leblond]

[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]

Hi,

On Tuesday, 2008 March 18 at  1:49:37 +0100, Pascal Hambourg wrote:
> Hello,
>
> Eric Leblond a écrit :
>> On Monday, 2008 March 17 at 16:13:45 -0400, Sohan Shetty wrote:
>>>
>>> Here, our box is connected to two distinct networks 192.168.1/24 [...]
>> There is no such patch. A similar question was asked some time ago and
>> if I remember well, the conclusion was the setup was too weird from a 
>> firewall point-of-view.
>
> s/weird/broken by design/
>
> The purpose of prefixes is to identify networks. If you use the same prefix 
> on distinct networks, expect trouble.

No, not really. If you use advanced routing capabability of linux this
setup can be easily achieved and except for filtering will be working
well (with one routing private table per network interface pair).

The correct explanation about the problem of conntrack relatively to
this setup is given by Jan Engelhardt in his mail.

BR,
-- 
Eric Leblond
INL: http://www.inl.fr/
NuFW: http://www.nufw.org/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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.