Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

surfcontrol

Status
Not open for further replies.

jimfixit

MIS
Aug 5, 2003
116
US
IS anyone using this product and if so, I wonder if you are having the same issues we are.

Occassionally, for no reason I can discern, this thing just gets wadded up and starts putting packets on the wire that have the same source mac address as our firewall. When that happens, packets begin to drop because the switch, having adjusted it's mac-address table for the source addresses it sees coming in on various ports, keeps becoming confused about where the firewall really is.

I can shut off the port that surfcontrol is attached to, or I can stop surfcontrol's redirection feature, and either will solve the problem.

SC is 'working as designed' in that the way it blocks sites is to redirect the conversation away from the disallowed site and instead offer you up the 'you can't go there' page. This it does by spoofing the site's destination mac address as the source for the blocked page packet.

But why it suddenly starts crafting packets with the source mac address of our Nokia firewall is beyond me. At first I thought someone was trying to hit that device with their browser. But I've used wireshark to trap packets but I don't see evidence of that. SC's logging isn't very complete so that doesn't tell me much, either.

If anyone else has worked with this product, or similar products and has seen the way it causes the mac-address table to become confused, I'd be grateful for input.
 
I haven't had this issue. We have our mirror port set only to the sc protocol and the second server nic handling the auth/man.
Are you using that setup?
We are also on 1 version back of sc.
 
The destination/source (depending on direction) MAC address for any site outside of your subnet is going to be the MAC of the default gateway, which sounds like the Nokia firewall in your case. That is how routing works. I do not know what the source MAC address of a packet originating from SurfControl's blocking port should be; it will either be the blocking port's MAC, or the firewall's MAC. Have you checked to see if SurfControl spoofs the MAC of the firewall, as well as the sites IP when everything is working correct? The other thing you can check is to make sure you are excluding your internal subnets from SurfControl's blocking. If you go into the SC Manager, go to Maintenance, Web Filter Settings, and then the Subnets tab, you can configure which networks to monitor/ignore.

HTH
 
We finally figured it out...there was a rule on the surf-control unit that was constantly being evoked.

The surfcontrol product was crafting packets as though from the firewall, and that would cause the mac table in the switch to momentarily see the wrong port for anything that should be directed to the firewall. But generally those packets would be followed immediately with return traffic from the firewall for some legitmate purpose so the mac-address-table would right itself immediately.

What was happening is our security team had a badly written rule that was constantly being evoked. So it was like a 'war' between the real firewall port and the blocking port that was assuming that firewall's mac address.

Finally turned off that rule and it's been quiet ever since.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top