Connection tracking and vlan

Post by Adayadil Thomas
If two connections have same 5 tuple, src ip, dst ip, src port, dst
port, protocol(tcp/udp)
but on different vlans (different vlan id), does the conntrack separate these ?

Probably not. Patrick, can you confirm this?

Cheers,

--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <***@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Eric Dumazet

2009-10-30 15:31:50 UTC

Post by Adayadil Thomas
If two connections have same 5 tuple, src ip, dst ip, src port, dst
port, protocol(tcp/udp)
but on different vlans (different vlan id), does the conntrack separ=

ate these ?

Post by Herbert Xu
=20
Probably not. Patrick, can you confirm this?
=20

Very strange, this question about vlan looks like discussion we had
yesterday (or the day before...) about interfaces (versus packet defrag=
mentation)

"IP conntracking" is about IP, and [V]LAN doesnt matter at all at this =
protocol level.

Same thing if you have two interfaces, eth0 & eth1 : IP conntrack tuple=
s dont
include interface name/index

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

Herbert Xu

2009-10-30 15:46:39 UTC

Same thing if you have two interfaces, eth0 & eth1 : IP conntrack tuples dont
include interface name/index

Indeed, but imagine what happens when eth0 is the LAN and eth1 is
the wild wild Internet. Do you really want their packets to mix?

Cheers,

Eric Dumazet

2009-10-30 16:19:30 UTC

Same thing if you have two interfaces, eth0 & eth1 : IP conntrack tu=

ples dont

include interface name/index

=20
Indeed, but imagine what happens when eth0 is the LAN and eth1 is
the wild wild Internet. Do you really want their packets to mix?
=20

No, Abayadi needs firewall rules (or RPF), before entering conntrack.

Allowing spoofed packets to come from wild Internet would be...
interesting in many aspects.

And since some setups use several links to LAN, several links to
Internet, its user policy decisions.

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

Patrick McHardy

2009-10-30 16:27:10 UTC

Same thing if you have two interfaces, eth0 & eth1 : IP conntrack t=

uples dont

include interface name/index

Indeed, but imagine what happens when eth0 is the LAN and eth1 is
the wild wild Internet. Do you really want their packets to mix?

=20
No, Abayadi needs firewall rules (or RPF), before entering conntrack.
=20
Allowing spoofed packets to come from wild Internet would be...
interesting in many aspects.
=20
And since some setups use several links to LAN, several links to
Internet, its user policy decisions.

Correct, users need to take care of this manually.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Herbert Xu

2009-10-30 16:55:00 UTC

Post by Eric Dumazet
No, Abayadi needs firewall rules (or RPF), before entering conntrack.

rp_filter doesn't help because routing occurs after conntrack,
so IP fragments from the untrusted side may have already been
folded into a fragment from the trusted side.

Yes netfilter rules pre-conntrack would help but I bet there
are a lot folks out there who don't have them.

Cheers,

Patrick McHardy

2009-10-30 16:26:11 UTC

Post by Adayadil Thomas
If two connections have same 5 tuple, src ip, dst ip, src port, dst
port, protocol(tcp/udp)
but on different vlans (different vlan id), does the conntrack sepa=

rate these ?

Post by Herbert Xu
Probably not. Patrick, can you confirm this?

Yes, you are right.

Post by Eric Dumazet
Very strange, this question about vlan looks like discussion we had
yesterday (or the day before...) about interfaces (versus packet defr=

agmentation)

Indeed, we did have that discussion a couple of years ago. IIRC
Rusty also suggested to add the interface to the defragmentation
key to avoid having fragments from different interfaces being
reassembled since iptables interface matches will only match on
the interface of the first fragment.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Adayadil Thomas

2009-10-30 19:20:21 UTC

Post by Eric Dumazet
Very strange, this question about vlan looks like discussion we had
yesterday (or the day before...) about interfaces (versus packet defragmentation)
"IP conntracking" is about IP, and [V]LAN doesnt matter at all at this protocol level.
Same thing if you have two interfaces, eth0 & eth1 : IP conntrack tuples dont
include interface name/index

I am concerned about the following situation -

The linux device is configured as a bridge and is deployed between the
trunk ports
of 2 switches. In this situation the linux device will be seeing 802.1q packets
with vlan headers specifying the vlanids.

It is valid to have an environment where private IP addresses are duplicated
on different virtual LANs. i.e. it is valid to have machine A (
10.10.10.1) talking to
machine B (10.10.10.2) on vlan 1,
and
at the same time machine C ( 10.10.10.1) talking to machine D
(10.10.10.2) on vlan 2.

Since they are on different LANs (VLANs), there should not be any issues.

Now when VLANs are shared across switches, the trunk port will sent
802.1q tagged
packets between the switches. Imagine these packets when going through
the linux bridge.
The 802.1q header should identify the separate vlans by the vlan id.

If ip_conntrack does not consider vlans, it is possible that all 5
tuple are the same
and thus affect the connection tracking.

I hope I have described the scenario well. If not I can explain in a
more detailed fashion.

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

Caitlin Bestler

2009-10-30 19:51:30 UTC

Yes, it is legitimate for a Bridge to see two different 10.*.*.*
networks on different VLANs.
A Bridge can even see that same MAC address being used by two
different end stations
on different VLANs (especially if the global bit is not set).

What is not legitimate is presenting both of those 10.*.*.* networks
for local delivery.

If you are only bridging the frames then there are no connections to
track, only frames.

On Fri, Oct 30, 2009 at 12:20 PM, Adayadil Thomas

Post by Eric Dumazet
Very strange, this question about vlan looks like discussion we had
yesterday (or the day before...) about interfaces (versus packet def=

ragmentation)

Post by Eric Dumazet
"IP conntracking" is about IP, and [V]LAN doesnt matter at all at th=

is protocol level.

Post by Eric Dumazet
Same thing if you have two interfaces, eth0 & eth1 : IP conntrack tu=

ples dont

Post by Eric Dumazet
include interface name/index

I am concerned about the following situation -
The linux device is configured as a bridge and is deployed between th=

Post by Adayadil Thomas
trunk ports
of 2 switches. In this situation the linux device will be seeing 802.=

1q packets

Post by Adayadil Thomas
with vlan headers specifying the vlanids.
It is valid to have an environment where private IP addresses are dup=

licated

Post by Adayadil Thomas
on different virtual LANs. i.e. it is valid to have machine A (
10.10.10.1) talking to
machine B (10.10.10.2) on vlan 1,
and
at the same time machine C ( 10.10.10.1) talking to machine D
(10.10.10.2) on vlan 2.
Since they are on different LANs (VLANs), there should not be any iss=

ues.

Post by Adayadil Thomas
Now when VLANs are shared across switches, the trunk port will sent
802.1q tagged
packets between the switches. Imagine these packets when going throug=

Post by Adayadil Thomas
the linux bridge.
The 802.1q header should identify the separate vlans by the vlan id.
If ip_conntrack does not consider vlans, it is possible that all 5
tuple are the same
and thus affect the connection tracking.
I hope I have described the scenario well. If not I can explain in a
more detailed fashion.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.ht=

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

Adayadil Thomas

2009-10-30 20:40:21 UTC

On Fri, Oct 30, 2009 at 3:51 PM, Caitlin Bestler

Post by Caitlin Bestler
Yes, it is legitimate for a Bridge to see two different 10.*.*.*
networks on different VLANs.
A Bridge can even see that same MAC address being used by two
different end stations
on different VLANs (especially if the global bit is not set).
What is not legitimate is presenting both of those 10.*.*.* networks
for local delivery.

I did not mean this case.

Post by Caitlin Bestler
If you are only bridging the frames then there are no connections to
track, only frames.

This is more like what I was trying to do with the device, but with
stateful firewall functionality
for which I was using iptables/netfilter.

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

Eric W. Biederman

2009-10-30 23:15:56 UTC

I am concerned about the following situation -
The linux device is configured as a bridge and is deployed between the
trunk ports
of 2 switches. In this situation the linux device will be seeing 802.1q packets
with vlan headers specifying the vlanids.
It is valid to have an environment where private IP addresses are duplicated
on different virtual LANs. i.e. it is valid to have machine A (
10.10.10.1) talking to
machine B (10.10.10.2) on vlan 1,
and
at the same time machine C ( 10.10.10.1) talking to machine D
(10.10.10.2) on vlan 2.
Since they are on different LANs (VLANs), there should not be any issues.
Now when VLANs are shared across switches, the trunk port will sent
802.1q tagged
packets between the switches. Imagine these packets when going through
the linux bridge.
The 802.1q header should identify the separate vlans by the vlan id.
If ip_conntrack does not consider vlans, it is possible that all 5
tuple are the same
and thus affect the connection tracking.
I hope I have described the scenario well. If not I can explain in a
more detailed fashion.

Unless you have multiple network namespaces linux assumes all packets are
in the same ip space. And 10.10.10.1 is the same machine no matter
which interface you talk to it on.

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

Ben Greear

2009-10-30 23:25:17 UTC

Post by Eric W. Biederman

Post by Adayadil Thomas
If ip_conntrack does not consider vlans, it is possible that all 5
tuple are the same
and thus affect the connection tracking.
I hope I have described the scenario well. If not I can explain in a
more detailed fashion.

Unless you have multiple network namespaces linux assumes all packets are
in the same ip space. And 10.10.10.1 is the same machine no matter
which interface you talk to it on.

It only takes a relatively small patch that lets conn-track hash on a
skb->foo_mark, and allow that mark to be set on incoming packets
based on netdevice or whatever, (before the conn-track lookup is
done).

This is logically somewhat similar to using multiple routing
tables and has been working well for me for several years....

Thanks,
Ben

--
Ben Greear <***@candelatech.com>
Candela Technologies Inc http://www.candelatech.com

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

Adayadil Thomas

2009-11-02 16:14:02 UTC

If the vlan id is used for hash, it still may not avoid the problem completely,
i.e. in case of both connections hashing to the same bucket.

I was wondering about your opinion about adding an optional member to the tuple
structure, vid (for vlan id).

I have attached the patch for this change. I would be grateful for any comments
such as dependencies on the rest of the system.

Thanks much

Post by Ben Greear

Post by Eric W. Biederman

Unless you have multiple network namespaces linux assumes all packets are
in the same ip space. And 10.10.10.1 is the same machine no matter
which interface you talk to it on.

It only takes a relatively small patch that lets conn-track hash on a
skb->foo_mark, and allow that mark to be set on incoming packets
based on netdevice or whatever, (before the conn-track lookup is
done).
This is logically somewhat similar to using multiple routing
tables and has been working well for me for several years....
Thanks,
Ben
--
Candela Technologies Inc http://www.candelatech.com

Adayadil Thomas

2009-11-02 16:30:16 UTC

A small correction to the patch. Thanks for any comments you can
provide on this patch.

Thanks

On Mon, Nov 2, 2009 at 11:14 AM, Adayadil Thomas

Post by Adayadil Thomas
If the vlan id is used for hash, it still may not avoid the problem completely,
i.e. in case of both connections hashing to the same bucket.
I was wondering about your opinion about adding an optional member to the tuple
structure, vid (for vlan id).
I have attached the patch for this change. I would be grateful for any comments
such as dependencies on the rest of the system.
Thanks much

Post by Ben Greear

Post by Eric W. Biederman

Unless you have multiple network namespaces linux assumes all packets are
in the same ip space. And 10.10.10.1 is the same machine no matter
which interface you talk to it on.

It only takes a relatively small patch that lets conn-track hash on a
skb->foo_mark, and allow that mark to be set on incoming packets
based on netdevice or whatever, (before the conn-track lookup is
done).
This is logically somewhat similar to using multiple routing
tables and has been working well for me for several years....
Thanks,
Ben
--
Candela Technologies Inc http://www.candelatech.com

Patrick McHardy

2009-11-02 16:33:43 UTC

Absolutely not, conntrack is not meant to deal with anything below
the network layer and I don't want to add any hacks for the bridge
netfilter "integration", which has already caused an endless amount
of problems. Additionally this is just one of many possible identifiers
people might want to use to distinguish similar entries and has a
number of practical issues, like breaking asymetric setups using
different VLANs for each direction.

I might be willing to consider a generically usable numerical
identifier to distinguish similar entries, something like
"conntrack zones". This could also help with the defragmentation
issue discussed earlier, the identifier would also be added to
the defragmentation identifier, for asymetric setups the interfaces
would be put in the same "zone".

But it would be preferrable if we could do this using network
namespaces somehow.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Eric Dumazet

2009-11-02 16:41:14 UTC

Post by Patrick McHardy
=20
But it would be preferrable if we could do this using network
namespaces somehow.

eg eth0.100 and eth0.101 on namespace 1, eth0.200 and eth0.201 on name=
space 2 ?

Can we do that with current kernel ? (different vlans on an unique phys=
ical device)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Patrick McHardy

2009-11-02 16:48:41 UTC

Post by Patrick McHardy
But it would be preferrable if we could do this using network
namespaces somehow.

=20
eg eth0.100 and eth0.101 on namespace 1, eth0.200 and eth0.201 on na=

mespace 2 ?

=20
Can we do that with current kernel ? (different vlans on an unique ph=

ysical device)

By default the underlying device needs to exist in the same namespace
in which the VLAN device is created. I believe it should be possible
to move the VLAN device to a different namespace after creating it,
but I'm not sure about that.

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

Eric W. Biederman

2009-11-02 17:02:29 UTC