Hi,

My network is as follows:

Shorewall gateway/router (10.215.144.92) --- INTERNAL SWITCH 1 (LAN1) --- 
Shorewall bridge (10.215.144.91) --- LAN2 (10.215.0.0)

I configured 10.215.144.91 as in the guide 
http://www.shorewall.net/3.0/NewBridge.html (it's an "old" box).

This morning I accidentally connected a cable from a LAN2 switch to a switch in 
LAN1, thus by-passing the bridge.
After a few minutes hosts in LAN2 started having network problems. Pings 
stopped working (between hosts WITHIN LAN2).

As soon as I disconnected that cable, hosts started to ping correctly again 
(within LAN2).

The Shorewall bridge is filtering traffic and its default policy for net to loc 
(ie. LAN1 to LAN2) is DROP.

I'd like to know what could have happened. 

I'm supposing that if ping requests went from LAN2 to "SWITCH 1" and then back 
through the bridge (10.215.144.91) then Shorewall would DROP those packets.
And I'm also supposing that if the default policy were to ACCEPT packets from 
LAN1 to LAN2, things would have kept "working".
However, the switch I connected from LAN1 to LAN2 was a peripheral switch and 
I'm guessing it should have affected a small amount of hosts.
Many hosts (way too many) were failing all at once, even hosts connected to a 
same switch (not the one I wrongly connected).

Correct me if I'm wrong but hosts connected to the same switch on LAN2 should 
have been able to communicate, even if another switch in LAN2 was connected to 
LAN1 (by-passing the bridge).
Unless there was some kind of network "poisoning" I'm unaware of.

Since my shorewall policy for net to all (that would include LAN1 to LAN2) is 
"DROP info" I should be getting some information from the log.
However, grepping -i "net2loc:drop" doesn't yield anything. So I'm puzzled as 
to why hosts within LAN2 were failing.

Any ideas and suggestions as to where to look and what to test?

Would a shorewall dump be of any help?

Thanks

Vieri



      

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to