Mailing List Archive

On 07/30/07 05:31, Pawel wrote:
> I need to remove 3 machines from one subnet (192.168.0.0/25) to new
> physical subnet. I want to add new network card to my linux router
> and create new subnet (192.168.0.96/29).

Ok...

> My issuse: I cannot touch any IPs of any machine ....

Ah. Here in lies the rub.

> how to do it? What is the best solution? (proxy arp, additional
> routing table?)

Do you really need a new subnet or just a new physical network? If the
later is the case, add a new network card to the Linux router and bridge
that new card with the old card that the computers were on. Once you
have the bridge in place, move the IP address that was assigned to the
old network card to the bridge interface. This will allow the old
machines to function as they were as well as the machines that you
moved. If you do not want the old machines to be able to talk to the
ones that you moved, use an EBTables (Bridging) rule to block traffic
from passing from the old NIC to the new NIC wile still allowing them to
get to the router the way they need to.

This works *GREAT*! I have used it a lot of places and have been very
happy with the results.



Grant. . . .

Hi,
I need to remove 3 machines from one subnet (192.168.0.0/25) to new
physical subnet.
I want to add new network card to my linux router and create new subnet
(192.168.0.96/29).

My issuse: I cannot touch any IPs of any machine ....


how to do it?
What is the best solution? (proxy arp, additional routing table?)

Thanks for any suggestion

Pawel




----------------------------------------------------------------------
Sprawdz
czy Ty i Twoj partner pasujecie do siebie emocjonalnie i seksualnie

>>>http://link.interia.pl/f1b14

I need separate 3 foreign machines (security reason - firewall between
subnets is required).
I cannot divide one 128 pubic IPs subnet...
Foreign machines have to use public IPs....

Pawel

Grant Taylor wrote:
> On 07/30/07 05:31, Pawel wrote:
>> I need to remove 3 machines from one subnet (192.168.0.0/25) to new
>> physical subnet. I want to add new network card to my linux router
>> and create new subnet (192.168.0.96/29).
>
> Ok...
>
>> My issuse: I cannot touch any IPs of any machine ....
>
> Ah. Here in lies the rub.
>
>> how to do it? What is the best solution? (proxy arp, additional
>> routing table?)
>
> Do you really need a new subnet or just a new physical network? If
> the later is the case, add a new network card to the Linux router and
> bridge that new card with the old card that the computers were on.
> Once you have the bridge in place, move the IP address that was
> assigned to the old network card to the bridge interface. This will
> allow the old machines to function as they were as well as the
> machines that you moved. If you do not want the old machines to be
> able to talk to the ones that you moved, use an EBTables (Bridging)
> rule to block traffic from passing from the old NIC to the new NIC
> wile still allowing them to get to the router the way they need to.
>
> This works *GREAT*! I have used it a lot of places and have been very
> happy with the results.
>
>
>
> Grant. . . .
>
>
>


----------------------------------------------------------------------
Piekne kobiety wsrod samych swin!
Obejrzyj

>>>http://link.interia.pl/f1b18

On 07/31/07 14:28, Pawel Zawora wrote:
> I need separate 3 foreign machines (security reason - firewall
> between subnets is required).

*nod* This is not a problem at all.

> I cannot divide one 128 pubic IPs subnet...

You do not need to.

> Foreign machines have to use public IPs....

*nod*

Say you have the following systems:

+---------+
| a.b.c.1 +---+
+---------+ |
| a.b.c.3 +---+
+---------+ |
| a.b.c.5 +---+
+---------+ | +--------+
| a.b.c.7 +---+---+ Router +---(Internet)
+---------+ | +--------+
| a.b.c.9 +---+
+---------+ |
| a.b.c.8 +---+
+---------+ |
| a.b.c.6 +---+
+---------+

And you want to split some of the computers off on to their own segment
so that they can not talk to the others and others can not talk to them.

+---------+
| a.b.c.1 +---+
+---------+ |
| a.b.c.3 +---+
+---------+ |
| a.b.c.5 +---+
+---------+ |
| a.b.c.7 +---+---+
+---------+ | +-------------------------------+
+---+ |
+---+ |
+---------+ | +-------------------------------+
| a.b.c.9 +---+---+
+---------+ |
| a.b.c.8 +---+
+---------+ |
| a.b.c.6 +---+
+---------+

Let's assume that:
- eth0 (top) goes to the top set of computers
- eth1 (middle) goes to the internet
- eth2 (bottom) goes to the bottom set of computers

Add eth0 and eth2 to the bridge.

Allow all traffic to pass through the bridge by default.
Block traffic from coming in to the bridge from eth0 and going out eth2.
Block traffic from coming in to the bridge from eth2 and going out eth0.

This allows traffic to come in eth0 and go out eth1.
This allows traffic to come in eth1 and go out either eth0 or eth2.
This allows traffic to come in eth2 and go out eth1.

This prevents computers on either part of the bridge from talking with
each other. Thus your computers that you can not change the IP
addresses on are still at the same IP address.

This allows you to have two logically separated LANs so that they can
not communicate with each other.

Does this help explain what I'm talking about? Again, I have used this
scenario MANY MANY times and have been EXTREMELY pleased with it. Let
me know if I need to try to explain this differently.

If this is what you are wanting to do, EBTables can VERY easily
accomplish this. Let me know if this is what you need and I'll help
provide you with a mach EBTables set up.



Grant. . . .

Grant Taylor wrote:
> On 07/31/07 14:28, Pawel Zawora wrote:
>
>> I need separate 3 foreign machines (security reason - firewall between
>> subnets is required).
>
>
> *nod* This is not a problem at all.
>
>> I cannot divide one 128 pubic IPs subnet...
>
>
> You do not need to.
>
>> Foreign machines have to use public IPs....
>
>
> *nod*
>
> Say you have the following systems:
>
> +---------+
> | a.b.c.1 +---+
> +---------+ |
> | a.b.c.3 +---+
> +---------+ |
> | a.b.c.5 +---+
> +---------+ | +--------+
> | a.b.c.7 +---+---+ Router +---(Internet)
> +---------+ | +--------+
> | a.b.c.9 +---+
> +---------+ |
> | a.b.c.8 +---+
> +---------+ |
> | a.b.c.6 +---+
> +---------+
>
> And you want to split some of the computers off on to their own segment
> so that they can not talk to the others and others can not talk to them.
>
> +---------+
> | a.b.c.1 +---+
> +---------+ |
> | a.b.c.3 +---+
> +---------+ |
> | a.b.c.5 +---+
> +---------+ |
> | a.b.c.7 +---+---+
> +---------+ | +-------------------------------+
> +---+ |
> ======================| Bridge / OSI Layer 2 Firewall +---(Internet)
> +---+ |
> +---------+ | +-------------------------------+
> | a.b.c.9 +---+---+
> +---------+ |
> | a.b.c.8 +---+
> +---------+ |
> | a.b.c.6 +---+
> +---------+
>
> Let's assume that:
> - eth0 (top) goes to the top set of computers
> - eth1 (middle) goes to the internet
> - eth2 (bottom) goes to the bottom set of computers
>
> Add eth0 and eth2 to the bridge.
>
> Allow all traffic to pass through the bridge by default.
> Block traffic from coming in to the bridge from eth0 and going out eth2.
> Block traffic from coming in to the bridge from eth2 and going out eth0.
>
> This allows traffic to come in eth0 and go out eth1.
> This allows traffic to come in eth1 and go out either eth0 or eth2.
> This allows traffic to come in eth2 and go out eth1.
>
> This prevents computers on either part of the bridge from talking with
> each other. Thus your computers that you can not change the IP
> addresses on are still at the same IP address.
>
> This allows you to have two logically separated LANs so that they can
> not communicate with each other.
>
> Does this help explain what I'm talking about? Again, I have used this
> scenario MANY MANY times and have been EXTREMELY pleased with it. Let
> me know if I need to try to explain this differently.
>
> If this is what you are wanting to do, EBTables can VERY easily
> accomplish this. Let me know if this is what you need and I'll help
> provide you with a mach EBTables set up.
>
>

Hi Grant,

Your knowledge never cease to amaze me.

Could one use iptables to do this?

-A FORWARD -physdev --physdev-in eth0 --physdev-out eth2 -j DROP
-A FORWARD -physdev --physdev-in eth2 --physdev-out eth0 -j DROP
-A FORWARD -j ACCEPT

Regardless, I'd still be very interested in seeing the ebtables ruleset
to accomplish this.

Thanks,
Mike Wright :m)

ps pls reply to list; my email is a throwaway.

On 7/31/2007 5:40 PM, Mike Wright wrote:
> Your knowledge never cease to amaze me.

*nod* Thank you. I like to share my trials and tribulations with
others so that they do not have to fight the same problems that I have
had to fight. I'm still working on getting our sales staff to not write
such big checks with their moths that I can hardly cash with my sweat.

> Could one use iptables to do this?

Possibly. If you enable the "Bridged IP/ARP packets filtering"
(CONFIG_BRIDGE_NETFILTER) support in the kernel, yes IPTables would be
able to filter this. However I do not know if it would be better to do
this with EBTables or IPTables. The only thing that I can say to this
effect is that EBTables is (native) OSI Layer 2 and IPTables is (native)
OSI Layer 3+. With the "Bridged IP/ARP packets filtering" option
enabled, you can use the OSI Layer 3+ features of IPTables on OSI Layer
2, however you are using a higher layer and more complex match than is
in my opinion really needed. I think it would be akin to opening up
Excel to calculate some numbers via formula verses using calculator.
Seeing as how EBTables is (native) OSI Layer 2, which is where you are
really needing to do you work, I think it would be a better solution.

Question, does the box that you are adding this 3rd NIC to already have
IPTables set up and installed? If the answer is yes, I suppose that it
would work just fine. If the answer is no (you are doing your SNAT /
Masquerading elsewhere) then EBTables's basic match of in / out
interface may work just as easily. Consider the complexity of what is
in kernel.

If you do do your NATing / Masquerading on the system in question, you
could have (for maintenance reasons) a clear separation of where your
OSI Layer 2 and OSI Layer 3 filtering is done, with EBTables and
IPTables respectively.

If you are concerned about needing to learn a new filtering structure
and command syntax, don't be as EBTables is so similar to IPTables that
it is uncanny. Incidentally so is ARPTables from what I remember. Nor
do I think this similarity is by accident.

> -A FORWARD -physdev --physdev-in eth0 --physdev-out eth2 -j DROP
> -A FORWARD -physdev --physdev-in eth2 --physdev-out eth0 -j DROP
> -A FORWARD -j ACCEPT

I have never worked with the physdev match extension so I can not say
for sure. I do not recall which features were being taken out of main
line NetFilter code, but I want to say that physdev was one of them,
thus meaning you would have to keep patching the kernel when you upgrade
to make this work. Thus in my opinion making the EBTables option more
maintainable and thus more appealing.


> Regardless, I'd still be very interested in seeing the ebtables
> ruleset to accomplish this.

ebtables -A FORWARD -i eth0 -o eth2 -j DROP
ebtables -A FORWARD -i eth2 -o eth0 -j DROP

Note, you do not need to set the ACCEPT target because the default
policy is to ACCEPT.

> Thanks,

*nod*

> ps pls reply to list; my email is a throwaway.

No problem. I generally only reply to the list / news group unless
explicitly asked to do so. That way the answer is in the archives for
others to benefit from.



Grant. . . .

Am Tuesday, den 31 July hub Grant Taylor folgendes in die Tasten:

Hi!

[..].
> >-A FORWARD -physdev --physdev-in eth0 --physdev-out eth2 -j DROP
> >-A FORWARD -physdev --physdev-in eth2 --physdev-out eth0 -j DROP
> >-A FORWARD -j ACCEPT

> I have never worked with the physdev match extension so I can not say
> for sure. I do not recall which features were being taken out of main
> line NetFilter code, but I want to say that physdev was one of them,
> thus meaning you would have to keep patching the kernel when you upgrade
> to make this work. Thus in my opinion making the EBTables option more
> maintainable and thus more appealing.

The physdev match is in the vanilla kernel for some time now.
I've used it on several bridgewall without patching the kernel.

max@pandora:linux-2.6.21.3$ grep PHYSDEV net/netfilter/Kconfig
config NETFILTER_XT_MATCH_PHYSDEV

Ciao
Max
--
Follow the white penguin.

Hello,

Maximilian Wilhelm a écrit :
> Am Tuesday, den 31 July hub Grant Taylor folgendes in die Tasten:
>
>>I have never worked with the physdev match extension so I can not say
>>for sure. I do not recall which features were being taken out of main
>>line NetFilter code, but I want to say that physdev was one of them [...]
>
> The physdev match is in the vanilla kernel for some time now.

AFAIK, the physdev match for iptables is in the 2.6 vanilla kernel since
version 2.6.0 (as well as bridge-neftilter) and has never been removed.
The physdev match for ip6tables was added in version 2.6.9.

I have no experience with bridgging ...
Is there any way to use my linux router as bridge ?
I'm using multiple routing tables (source routing) to route between
interfaces (3 IPS , 4 local networks + tunells)

Is there no way to use routing instead of bridging?
Can I mark packet (via iptables) and next create routing rules based on
the mark? (on the router)
How to enforce routing via gw (my router) from machines in "my" subnet
to "foregin" subnet? (by default thay seem that host a.b.c.97 is in
local subnet ?
Is any way to enfore routing (somethig like DR used by LVS? ) )


my subnet foreign
subnet
+------------+ +----------------+ +------------+
| a.b.c.2/25 +---+ | router (bride?) + -----+| a.b.c.97/29 +
+------------+ | +----------------+ +------------+
+------------+ |
| a.b.c.3/25 +---+
+------------+ |


Thanks for suggestions...

Pawel


Mike Wright wrote:
> Grant Taylor wrote:
>> On 07/31/07 14:28, Pawel Zawora wrote:
>>
>>> I need separate 3 foreign machines (security reason - firewall
>>> between subnets is required).
>>
>>
>> *nod* This is not a problem at all.
>>
>>> I cannot divide one 128 pubic IPs subnet...
>>
>>
>> You do not need to.
>>
>>> Foreign machines have to use public IPs....
>>
>>
>> *nod*
>>
>> Say you have the following systems:
>>
>> +---------+
>> | a.b.c.1 +---+
>> +---------+ |
>> | a.b.c.3 +---+
>> +---------+ |
>> | a.b.c.5 +---+
>> +---------+ | +--------+
>> | a.b.c.7 +---+---+ Router +---(Internet)
>> +---------+ | +--------+
>> | a.b.c.9 +---+
>> +---------+ |
>> | a.b.c.8 +---+
>> +---------+ |
>> | a.b.c.6 +---+
>> +---------+
>>
>> And you want to split some of the computers off on to their own
>> segment so that they can not talk to the others and others can not
>> talk to them.
>>
>> +---------+
>> | a.b.c.1 +---+
>> +---------+ |
>> | a.b.c.3 +---+
>> +---------+ |
>> | a.b.c.5 +---+
>> +---------+ |
>> | a.b.c.7 +---+---+
>> +---------+ | +-------------------------------+
>> +---+ |
>> ======================| Bridge / OSI Layer 2 Firewall +---(Internet)
>> +---+ |
>> +---------+ | +-------------------------------+
>> | a.b.c.9 +---+---+
>> +---------+ |
>> | a.b.c.8 +---+
>> +---------+ |
>> | a.b.c.6 +---+
>> +---------+
>>
>> Let's assume that:
>> - eth0 (top) goes to the top set of computers
>> - eth1 (middle) goes to the internet
>> - eth2 (bottom) goes to the bottom set of computers
>>
>> Add eth0 and eth2 to the bridge.
>>
>> Allow all traffic to pass through the bridge by default.
>> Block traffic from coming in to the bridge from eth0 and going out eth2.
>> Block traffic from coming in to the bridge from eth2 and going out eth0.
>>
>> This allows traffic to come in eth0 and go out eth1.
>> This allows traffic to come in eth1 and go out either eth0 or eth2.
>> This allows traffic to come in eth2 and go out eth1.
>>
>> This prevents computers on either part of the bridge from talking
>> with each other. Thus your computers that you can not change the IP
>> addresses on are still at the same IP address.
>>
>> This allows you to have two logically separated LANs so that they can
>> not communicate with each other.
>>
>> Does this help explain what I'm talking about? Again, I have used
>> this scenario MANY MANY times and have been EXTREMELY pleased with
>> it. Let me know if I need to try to explain this differently.
>>
>> If this is what you are wanting to do, EBTables can VERY easily
>> accomplish this. Let me know if this is what you need and I'll help
>> provide you with a mach EBTables set up.
>>
>>
>
> Hi Grant,
>
> Your knowledge never cease to amaze me.
>
> Could one use iptables to do this?
>
> -A FORWARD -physdev --physdev-in eth0 --physdev-out eth2 -j DROP
> -A FORWARD -physdev --physdev-in eth2 --physdev-out eth0 -j DROP
> -A FORWARD -j ACCEPT
>
> Regardless, I'd still be very interested in seeing the ebtables
> ruleset to accomplish this.
>
> Thanks,
> Mike Wright :m)
>
> ps pls reply to list; my email is a throwaway.
>
>
>


----------------------------------------------------------------------
Najseksowniejsi chlopcy, najladniejsze dziewczyny, sprawdz i ocen

>>>http://link.interia.pl/f1b23

On 08/01/07 15:14, Pawel Zawora wrote:
> I have no experience with bridgging ...

Not a problem. Bridging is *VERY* easy to work with. In fact, I'd be
willing to bet that after you set it up you will look back and think
"Hum, that was ridiculously easy.".

> Is there any way to use my linux router as bridge ?

Yes, it is very easy to do. Add support for bridging to the kernel
"(2.6) Device Drivers -> Networking support -> Networking options ->
802.1d Ethernet Bridging".

To do the separation that I'm talking about you will need EBTables
support in the kernel too "(2.6) Device Drivers -> Networking support ->
Networking options -> Network packet filtering -> Bridge: Netfilter
Configuration -> Ethernet Bridge tables (ebtables) support".

*IF* you do want to use IPTables to filter the packets and not EBTables
you will need to turn on "(2.6) Device Drivers -> Networking support ->
Networking options -> Network packet filtering -> Bridged IP/ARP packets
filtering" which is used to allow IPTables Netfilter code to see bridged
packets just like forwarded packets.

I would recommend that you use EBTables to do the OSI Layer 2
firewalling over IPTables.

> I'm using multiple routing tables (source routing) to route between
> interfaces (3 IPS , 4 local networks + tunells)

Ok...

> Is there no way to use routing instead of bridging?

Ugh, I'm sure there is, but I'm not sure how to go about it. In my
opinion routing verses bridging any time you want the same subnet on
multiple separated interfaces is akin to buying a DC to AC converter to
power a battery charger to charge the battery in a car verses just
fixing the alternator. Sure it will work, buy why do it the long way
when there is a much simpler *MUCH* cleaner and more maintainable way to
do it. If you get routing involved when you have the same subnet on two
non connected interfaces, you have all sorts of different (IMHO) nasty
issues to work with where as bridging, routing is just like it was,
clean and simple with out rules to specify which condition triggers
which routing table.

> Can I mark packet (via iptables) and next create routing rules based
> on the mark? (on the router)

I'm sure that you can mark packets and decide which routing table(s) to
use based on the mark. However I'm not sure how well this will achieve
what you are wanting to do based on how complex the routing becomes.

> How to enforce routing via gw (my router) from machines in "my"
> subnet to "foregin" subnet? (by default thay seem that host a.b.c.97
> is in local subnet ?

Ok, I think you are going a bit backwards here. I thought I understood
you to mean that you did not want machines in your (local) a.b.c subnet
to be able to communicate with machines in the foreign (remote) a.b.c
subnet and vice versa. Is that indeed the case, or not? This decides
what firewalling would and / or would not be in place.

> Is any way to enfore routing (somethig like DR used by LVS? )

I'm not sure what you are wanting to enforce? I'm cursorily aware of
what Direct Routing in a Linux Virtual Server is, but not enough so to
comment on how DR would compare to what I'm proposing via bridging.

Basically, what bridging (as I have proposed it) will do is take a
system with with three network cards in it with each connected to
physically separate networks that do not interconnect join two of three
said networks as if it was one (logical) network. Thus allowing one
subnet to be common to both of the two physical networks in the one
logical network.

Another way to say this would be to have two buildings connected
together with switches and a router in one of the buildings out to the
internet. The LAN common to both buildings shares one IP subnet and
stations are assigned static IPs across the subnet in both buildings in
such a way as it is practically (for all intents and purposes)
impossible to break the two buildings in to two different networks and
subnets. However you have to do something to keep the computers in one
building from talking to the computers in the other building and vice
versa. Bridging will VERY easily accomplish this. To do this with
bridging, add a third network card to the router and connect the cable
from the other building in to the new network card. Now create a bridge
(via brctl) on the router and add the two network cards facing the
buildings to the bridge. Move the IP address that was assigned to the
network card facing the building(s) off of the physical ethernet
interface to the logical bridge interface. Now you have the two
buildings bridged together via the bridge / router. Using EBTables you
can now put firewalling rules in place to control who can access what in
between the two buildings. Depending on what your EBTables firewall
rules are, the buildings can possibly communicate with each other any
where between fully to absolutely noting at all or to a very limited extent.



Grant. . . .

Grant Taylor wrote:
> On 08/01/07 15:14, Pawel Zawora wrote:
>
>> I have no experience with bridgging ...
>>
>
> Not a problem. Bridging is *VERY* easy to work with. In fact, I'd be
> willing to bet that after you set it up you will look back and think
> "Hum, that was ridiculously easy.".
>
>
>> Is there any way to use my linux router as bridge ?
>>
>
> Yes, it is very easy to do. Add support for bridging to the kernel
> "(2.6) Device Drivers -> Networking support -> Networking options ->
> 802.1d Ethernet Bridging".
>
> To do the separation that I'm talking about you will need EBTables
> support in the kernel too "(2.6) Device Drivers -> Networking support ->
> Networking options -> Network packet filtering -> Bridge: Netfilter
> Configuration -> Ethernet Bridge tables (ebtables) support".
>
> *IF* you do want to use IPTables to filter the packets and not EBTables
> you will need to turn on "(2.6) Device Drivers -> Networking support ->
> Networking options -> Network packet filtering -> Bridged IP/ARP packets
> filtering" which is used to allow IPTables Netfilter code to see bridged
> packets just like forwarded packets.
>
> I would recommend that you use EBTables to do the OSI Layer 2
> firewalling over IPTables.
>
>
Stupid question:
Is it possible to filter packet based on src or dst IP? or using TCP
state (contrack, port,flags)

>> I'm using multiple routing tables (source routing) to route between
>> interfaces (3 IPS , 4 local networks + tunells)
>>
>
> Ok...
>
>
>> Is there no way to use routing instead of bridging?
>>
>
> Ugh, I'm sure there is, but I'm not sure how to go about it. In my
> opinion routing verses bridging any time you want the same subnet on
> multiple separated interfaces is akin to buying a DC to AC converter to
> power a battery charger to charge the battery in a car verses just
> fixing the alternator. Sure it will work, buy why do it the long way
> when there is a much simpler *MUCH* cleaner and more maintainable way to
> do it. If you get routing involved when you have the same subnet on two
> non connected interfaces, you have all sorts of different (IMHO) nasty
> issues to work with where as bridging, routing is just like it was,
> clean and simple with out rules to specify which condition triggers
> which routing table.
>
>
>> Can I mark packet (via iptables) and next create routing rules based
>> on the mark? (on the router)
>>
>
> I'm sure that you can mark packets and decide which routing table(s) to
> use based on the mark. However I'm not sure how well this will achieve
> what you are wanting to do based on how complex the routing becomes.
>
>
Yes, It it so complex
>> How to enforce routing via gw (my router) from machines in "my"
>> subnet to "foregin" subnet? (by default thay seem that host a.b.c.97
>> is in local subnet ?
>>
>
> Ok, I think you are going a bit backwards here. I thought I understood
> you to mean that you did not want machines in your (local) a.b.c subnet
> to be able to communicate with machines in the foreign (remote) a.b.c
> subnet and vice versa. Is that indeed the case, or not? This decides
> what firewalling would and / or would not be in place.
>
>

I have one "big" subnet (assume 1.1.1.0/24) now I want remove 3
machines (1.1.1.98 - 100) to separete "small" subnet
"small" subnet: It is enough to change subnet size to /29 and define
new default gw
router - I need to create 1 additional routing table that will send
data to my smal subnet based on dst address
"big" subnet - I have to told *each* machine: send packet to GW even
1.1.1.98... seems be in local network.

Similarly thinks are done in DR (in this case I dont need to create
extra routing rules ) But probably I cannot use DR mechanism in my
situation...



After this I can create any iptables rules on the router..........



>> Is any way to enfore routing (somethig like DR used by LVS? )
>>
>
> I'm not sure what you are wanting to enforce? I'm cursorily aware of
> what Direct Routing in a Linux Virtual Server is, but not enough so to
> comment on how DR would compare to what I'm proposing via bridging.
>
> Basically, what bridging (as I have proposed it) will do is take a
> system with with three network cards in it with each connected to
> physically separate networks that do not interconnect join two of three
> said networks as if it was one (logical) network. Thus allowing one
> subnet to be common to both of the two physical networks in the one
> logical network.
>
> Another way to say this would be to have two buildings connected
> together with switches and a router in one of the buildings out to the
> internet. The LAN common to both buildings shares one IP subnet and
> stations are assigned static IPs across the subnet in both buildings in
> such a way as it is practically (for all intents and purposes)
> impossible to break the two buildings in to two different networks and
> subnets. However you have to do something to keep the computers in one
> building from talking to the computers in the other building and vice
> versa. Bridging will VERY easily accomplish this. To do this with
> bridging, add a third network card to the router and connect the cable
> from the other building in to the new network card. Now create a bridge
> (via brctl) on the router and add the two network cards facing the
> buildings to the bridge. Move the IP address that was assigned to the
> network card facing the building(s) off of the physical ethernet
> interface to the logical bridge interface. Now you have the two
> buildings bridged together via the bridge / router. Using EBTables you
> can now put firewalling rules in place to control who can access what in
> between the two buildings. Depending on what your EBTables firewall
> rules are, the buildings can possibly communicate with each other any
> where between fully to absolutely noting at all or to a very limited extent.
>
>
>
> Grant. . . .
>
>
>
>
Thank you for explanation
Probably bridging is easiest way to solve my problem....
Does snort work correctly on brigde server?
What is the best way to trace and log tcp connections in that scenario ?

Thank you
Pawel


----------------------------------------------------------------------
Jestes sexy? Dodaj swoje fotki i daj sie ocenic na
>>>http://link.interia.pl/f1b21

On 8/1/2007 5:44 PM, Pawel Zawora wrote:
> Stupid question: Is it possible to filter packet based on src or
> dst IP? or using TCP state (contrack, port, flags)

Yes, you can filter based on port. To do connection state filtering I
think you will need to use IPTables. With the Bridged IP/ARP Netfilter
code you can use all of IPTables features on layer 2 in the bridge and
not have to worry about crossing subnets.

> Yes, It it so complex

Indeed, probably too complex.

> I have one "big" subnet (assume 1.1.1.0/24) now I want remove 3
> machines (1.1.1.98 - 100) to separete "small" subnet "small" subnet:
> It is enough to change subnet size to /29 and define new default gw
> router - I need to create 1 additional routing table that will send
> data to my smal subnet based on dst address "big" subnet - I have to
> told *each* machine: send packet to GW even 1.1.1.98... seems be in
> local network.

Again, I'm a bit confused as to whether or not you want the machines you
are moving to a different network to be able to communicate with the
machines that are staying on the big network or not. Let me ask it a
different way, what is your reasoning / motivation for moving the
machines in question to a different network?

> Similarly thinks are done in DR (in this case I dont need to create
> extra routing rules ) But probably I cannot use DR mechanism in my
> situation...

Again, will you please try to explain more of your situation (if you
can) as to what you have now and what you are wanting to achieve and why
you are going that route. In other words, what is your original problem
/ desire?

> After this I can create any iptables rules on the router..........

Yes. The bridge is as much a real interface as any ppp interface, so
you can do just about any thing you want to with it.

> Thank you for explanation

You are welcome.

> Probably bridging is easiest way to solve my problem....

Probably. Though I can not say for sure with out knowing more about
your situation. I keep asking, because bridging is a very good solution
in a lot of situations, but what you do with it is how you tune the
bridging setup to your environment.

> Does snort work correctly on brigde server?

I see no reason why it would not. I have successfully ran any and all
utilities against a bridge interface with out a problem. TCPDump, DHCP,
any web server / dns server / mail server, just about any thing. The
only draw back that I see with using a bridge for Snort is that you
can't physically cut the transmit line so you have to use the no arp
methods to stop arp replies.

> What is the best way to trace and log tcp connections in that
> scenario?

Probably the same thing that you are doing now. TCPDump, Snort should
work, libpcap, you name it.

> Thank you

You are welcome.



Grant. . . .

P.S. If you would be more comfortable discussing details off of news
group just drop me a line.

Hi guys,

On Thu, 2 Aug 2007 Grant Taylor wrote:

> > On 8/1/2007 5:44 PM, Pawel Zawora wrote:
> > I have one "big" subnet (assume 1.1.1.0/24) now I want remove 3
> > machines (1.1.1.98 - 100) to separete "small" subnet "small" subnet:
>
> If you would be more comfortable discussing details off of news
> group just drop me a line.

Obviously you should remove from your posts any information which you
think is too sensitive for publication, but for those of us following
this with interest, please try to keep it on the list if you can.

--

73,
Ged.

>From: netfilter-bounces@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of G.W. Haywood

>Hi guys,

>On Thu, 2 Aug 2007 Grant Taylor wrote:

>> > On 8/1/2007 5:44 PM, Pawel Zawora wrote:
>> > I have one "big" subnet (assume 1.1.1.0/24) now I want remove 3
>> > machines (1.1.1.98 - 100) to separete "small" subnet "small" subnet:
>>
>> If you would be more comfortable discussing details off of news
>> group just drop me a line.

>Obviously you should remove from your posts any information which you
>think is too sensitive for publication, but for those of us following
>this with interest, please try to keep it on the list if you can.
>--
>73,
>Ged.

I think he already sanitized the IPs!
The 1.0.0.0/8 net is reserved and unassigned.
--
73,
KE5FBT