Hey Henry, what you have done using routing is the best option. By web the basic assumption is that you mean port 80. Once you intercept Web traffic you must intercept it all at least for one way stream. let say you have a TCP stream you can use the router ports to separate between the directions.. On a router I would not go to use connection tracking iptables in the application level but a simple stream tracking can be used like in vyatta. If you wont use connection tracking at all in the router box you would probably will allow the router more traffic but it's very simple to set what you need up. mark with iptables all traffic of dport(80) + src_lan_ip and these streams will go to the the TPROXY from router1 and also from router2 to tproxy. it's a very elegant solution which is less perfect then others that works in application level for all traffic but it still a very very good solution. If you have a "block web-page" host it on a server that is marked as "non intercepted" in any interception part of the system. I would recommend you to put this server in the lan segment rather then pass it even near the TPROXY system. let say 10.0.0.1/24 is the client so use a dedicated 10.0.101.100/X server so the traffic to this service will go only the basic routing like: 10.0.0.1 --> routerX--|--tproxy --|--other-services --|--dns --|--etc The routerX can be either router1 or another downstream router. Eliezer On 09/18/2013 03:53 PM, Henry Pootel wrote:

I would like to make an URL filter (block with forward to "block web-page") for special WEB-servers on a TPROXY box. The all web-trafic is too big for bridging scheme. So I route small trafic for special WEB-servers (by destination IP) to TPROXY box for access approvement.

Oh, I'm upset.

thank you John.

Henry.

18.09.2013 15:24, John Lauro wrote:

...

That could be useful for matching flow records / auditing, but for your case it doesn't matter, even if the ports were kept the same the sequence numbers would get off and the stream would break as soon as something is/isn't in the cache (probably sooner from header changes). The connection must be terminated on the TPROXY box.

Two options: 1. Have TPROXY resend the requests with it's IP instead of keeping the client IP. As the client IP is on a private net anyways (10.10.175.111), might as well, little reason to try to preserve a private IP, you will have private IP logs from SQUID... 2. Have router2 route the opposite back through TPROXY as router1 did. IE: If router1 is routing destination port 80 via TPROXY, have router2 route source port 80 via TPROXY also.

----- Original Message -----

...

From: "Henry Pootel" <Henry.Pootel@regall.net> To: tproxy@lists.balabit.hu Sent: Wednesday, September 18, 2013 5:45:53 AM Subject: [tproxy] SQUID+TPROXY for assymetric routes

Hello.

I've a scheme

+--------+ +---------+ +---------+ +-----+ | client |------| router1 |--------| router2 |------| web | +--------+ +----+----+ +----+----+ +-----+ | | | | | +--------+ | +---| TPROXY |-----+ +--------+

client IP: 10.10.175.111 web IP: 5.5.5.5

The routing is assymetric. Packets from "client" to "web" is go through TPROXY, but from "web" is go directly through "router2" and "router1".

The "TPROXY" is an OpenSuSE 12.3 linux computer with Squid 3.2.11 and TPROXY v4.1.0 with kernel Linux 3.7.10-1.16-default.

I've attached a diff of tshark dumps of client oungoing and web incoming trafics. My problem is a changing source port on "TPROXY".

Is the source port may be changed by squid+tproxy? Can I forbid it and keep client's source port like as client's IP?

Thanks, Henry

_______________________________________________ tproxy mailing list tproxy@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/tproxy

_______________________________________________ tproxy mailing list tproxy@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/tproxy

_______________________________________________ tproxy mailing list tproxy@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/tproxy