Sorry, but this sounds like a "won't work". Your server is depending on sending spoofed packets. If this was on a local VLAN, you could simply put if2 in the same VLAN as the sniffer-if and let it work from there. I see you mentioned the traffic is fed by RSPAN, so I guess the traffic isn't local, and may even be from different VLAN's. That's when it would be a problem.
Put your server in a central place where all traffic must pass and do it from there, and if you have redundant paths you should also have redundant servers. Alternatively, you should look into building a "blackbox" to accept these packets and forward into the network. The Cisco gear won't do this for you. That said, if you want to experiment further, look into using RSPAN to send these packets out on the network again... This may mean you'll need a third if for management, but it could be worth a try. Best regards, Stig Meireles Johansen -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rafael Rodriguez Sent: 16. mai 2008 04:57 To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [email protected] Subject: Re: [c-nsp] Set a L3 routed interface on a 6500 + SUP2 to'promiscuous'mode? Thanks for the replies. Post below is a bit long but easy to read, please let me know if you guys have any advice. >What mac is it sending too? where does it get the arp entry from? Unfortunately this server does not attempt to 'arp' for the remote address, proxy-arp would be the solution in that case. Let me give some more details on what this server does: The server (just windows 2003 with software) is a content filter. It has two phy interfaces, one interface is the sniffer interface, the other/regular interface is were you manage the server and were the server sends its 'block' and tcp rst messages to end users. The sniffer interface just listens for traffic, it does not TX on this interface at all. The sniffer interface is being fed by rspan. The other/regular interface is were everything else happens. On this interface, any locally traffic generated by server works as one would expect... Oh, im trying to get to a remote network, let me send packet with dst mac address of my default gateway, let my default gateway figure out the rest. The part of locally generated traffic works perfectly. Now the problem. When the content filter makes a decision of 'blocking' someones web/http traffic based on traffic it sees on its sniifer interface, the server sends a 'block' message out the other/regular interface. The server sets the src IP of the packet to the 'bad' website and sets the dst IP to that of the offending end user. The server also sends a tcp rst to offending end user. ALL of that is perfectly fine. Problem comes down to how the server sends the data-link address part. Server is using the wrong dst MAC Address to send packets that reside on remote subnets. By wrong dst MAC Address I mean NOT the MAC Address of the servers default gateway. The server uses the src MAC Address of the 'offending' traffic from the sniffer interface as the dst MAC Address of the 'block' message. Why is this a problem? Well, dst MAC Address is not the MAC Address of the default gateway router - packet just gets dropped in hardware, never makes it up to L3 for processing. The information contained in this paragraph was confirmed/figured out with the help of wireshark. I am looking for a way to have router interface process all data-link packets regardless if the dst MAC Address is for the router interface. Thanks for reading, please reply with any info. Cheers, RR _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
