Hey Alfredo, The question you are asking is related to the MAC address level of the bridge.. The bride flood the ports with the data.. Since the traffic comes to the port of the Proxy machine it gets the MAC level by demand.. There is no real need for the proxy machine to ask for arp unless there is a use of vlan.s which in this specific case the switch acts in the routing level and there is a proxy-arp that does all the work that is needed. How would someone send an IP packet without mac address? IPX? we are talking about TCP+IP which the switch does all the mac address level stuff and the proxy just uses this data. if the client wont answer to the ARP requests this client should be banned. The same goes if a two clients use the same MAC address... one of them should be banned on the port level. as an example I have 48 ports of 1GBps per port and two clients send a packet with the same MAC address.. one of the ports should block this MAC address by default. a PROXY should not be working on the MAC level in a very large network. In order to do that you should divide your network logically so that a suited switching machine would do the MAC level filtering and sniffing leaving the server the heavy lifting part of TPROXY and other IP level stuff. If you can describe the LAN part which is the main issue here I can try to understand and maybe get the situation in hands and maybe find a good solution to the problem. Eliezer On 10/06/2013 02:20 PM, Amos Jeffries wrote: > On 4/10/2013 11:16 p.m., Alfredo Rezinovsky wrote: >> I have a squid in tproxy mode running in a bridge. >> Let name LAN side the one connected to the clients and WAN side the >> one connected to the gateway. >> I'm using Ubuntu server LTS with a 3.5.0 kernel >> >> The LAN network has various sub-networks, handled with many different >> IPs in the gateway. >> >> When a client starts a connection to an external server, port 80, the >> proxy intercepts it, process, and answers, allways using the client IP >> for the outgoing packets and the external server ip for the packets >> sent to the client. >> >> The proxy still needs is own IP for 3 reasons: >> >> * Ask DNS queries to a local DNS server (still can't force squid to >> use the original destination IP without asking DNS, or to use the >> TPROXY client ip for the DNS query) >> * Ask ARP to the clients >> * Remote access to the proxy for administration. > > * serving error page embeded objects to clients. > >> >> Some clients that are in strict mode, refuses to answer ARP when the >> proxy asking IP is not in the same IP network. >> >> There's a way to let linux learn ARP in passive mode when no one >> answers ARP? >> > > You will have to ask the networking people for Linux that question. > > Amos