Is this strange?

ilius168 · September 9, 2007, 9:44am

Dear All,
Could anyone tell me if this look strange?

Router 1 MT 2.9.45
Interface connected to the Modem
Interface connected to a distribution router (router 2)
NAT
WEB PROXY enabled

Router 2 MT 2.9.45
Bandwidth Management to individual IP

Questions:
The traffic from Interface always hit 1.5mbps while distribution only half of it (most of the time), is this because it is limited in Router 2?
and router 1 act like buffer? (web proxy working??)
It does effect others browsing activity.
Is this the sign of proxy being used or attacked?

I used torch to Interface it shows alot of Rapidshare IPs, that’s matched to one of the clients DST Address, but the client is limited to 128kbps only.

Hm, rather hard to explained…

ilius168 · September 9, 2007, 9:48am

forgot to add:

i used DST-NAT to redirect all port 80 traffic to Router 1 port 80

 6   ;;; PROXY via Satellite
     chain=dstnat action=dst-nat to-addresses=192.168.5.1 to-ports=80 
     src-address=192.168.1.0/24 dst-port=80 protocol=tcp

While in Router 1, DST NAT all port 80 to port 8080 (web proxy)

 
1   chain=dstnat in-interface=Distribution protocol=tcp dst-port=80 
     action=redirect to-ports=8080

hulk-bd · September 9, 2007, 4:30pm

I think your proxy is open, like it’s not blocked from your public interface in the 1st router OS which is connected to vsat, that’s why any one from outside (not your local network user) can use your web-proxy address and eating your bandwidth. you should block your web-proxy to be used from outside (your vsat link = real IP).

just read the MT ROUTER OS Manual how to block the open proxy.

ilius168 · September 10, 2007, 1:27am

I’m using local ip on router one, even the sat is local IP. I’ve done blockage to the proxy. (webproxy access).
It appears to me, once the client finished downloading (from rapidshare, 80.239.151.x) the traffic also stop.

I wonder if this is the effect of the proxy that act as buffer. (Stored whatever proxy requested, then distributed to the client, accordingly to the bandwidth set)

Thanks for responding!

ilius168 · September 10, 2007, 4:41am

I’m sure this is something to do with WEB-PROXY, once i disable the redirecting to web proxy (port 80 → port 8080), the traffic seems to be fine (incoming traffic = outgoing traffic).

According to some information from squid, there is a term “half open connection” or “half close client” not sure if this is relevant.
How is it done in MikroTik, as it is squid based as well.

PLease advice.

Thank you.

warwick09 · September 10, 2007, 2:06pm

Well mikrotik’s web-proxy 2.9.X is a stripped version of squid so you loose a lot of functionality… since you say that the weird traffic is being routed to a known client’s address then its not an attack on the router’s web proxy but rather a client being greedy … why not block rapidshare’s site entirely since you are routing all traffic to the web proxy and at least have control over that feature.

It would make things much clearer if you can include the port and protocol in a torch readout … also why not try changing your web-proxy’s port to something less standard? Id say 9045? - up to you.

Try adding this to your firewall list …

/

ip firewall filter

add chain=forward src-address=80.239.151.0/24 action=drop

Regards

hulk-bd · September 10, 2007, 3:48pm

Hi there,

Sorry I was wrong about the open proxy, after I wrote here I thought about the Scenario and found out something, why are you running the web proxy in your 1st router? let me ask you something are all your clients connected to your distributed router (2nd MT OS) and get their IP from this router? I think the graphs are ok cause all your clients are also having web proxy cache from the 1st router not from the 2nd router so when the clients use the Net they just pass through your 2nd router and all the request hits the 1st router which is also running the web proxy. I think you can enable the web proxy in your 2nd router and make a dst-nat for it only, and disable the 1st web proxy which is running in your 1st router. I don’t know I’m right or wrong, but you can do that to test the solution.

Thanks

ilius168 · September 10, 2007, 6:11pm

Yes you are right about the greedy client. Found out that he used DAP, it seems to be ‘colaborating’ with MT’s WEB PROXY to work as buffer!

Uhm, rapidshare is quite a popular web for download at the moment, so droping the IP is not an option at the moment

All the rapidshare IPs use port 80.

ilius168 · September 10, 2007, 6:19pm

well i’m running wep proxy on the first router cos if i have it in the 2nd MT, the bandwidth thru web proxy is not managed. I’ve got some other mangle rules that stop the queue to work with web-proxy. (i believe this has been discussed in the forum for sometime)
And according to what written in the forum, that it’s better to run a web proxy (or any proxy server) seperated from the distribution router for performance wise. CMIIW.

warwick09 · September 10, 2007, 6:39pm

Well which would you prefer… a pop with 1 happy client or a pop with no clients? If the experience of others are being adversly affected by a single customer then its best you either let him know that such “unfairness” will not be tolerated and if being adament is not enough then enforce … I would always choose the latter, in fact ive experienced several cases with clients that feel the need to download from rapid share and p2p programs all day but have since “fixed” it, made everything soo much better…

Im not saying that you should be the isp from hell but others are paying too…

Although all that stuff above is beside the point … why not place a simple queue as mentioned before at the router where the proxing/caching is taking place? (The router where the proxy server is located) … That would make more sense to me.

Regards

t3rm · September 10, 2007, 6:42pm

ilius168:
I think this situation happened because you activate web-proxy in MT#1.
Once you deactivate the web-proxy on MT#1 and leaving the connection to your users wide open without any proxy, the connection would be the same between MT#1 and MT#2

On MT#1 you activate web-proxy. On MT#2 you activate queuing. Of course the traffic flowing from Internet to Proxy would be as maximum as the capacity you have. This is happening to me also, specially when your users totally insane and greedy for bandwidth..

DAP, FlashGET, Download Manager. All the same. This could eating up all the capacity bandwidth you have if you place the queue in wrong location.

I suggest you put the Mikrotik Queue on #1, and let the users going to Internet using Squid-Linux Proxy you installed on the other box. Why use Squid under Linux ?
Because it really gives you a lots of option which MT didnt have.

TCP_OUTGOING_ADDRESS (Traffic from Proxy would be using different IP for different users)
Those traffic above entering MT#1 would be queue according to their class and can be manage fairly shared among other queue classes.
Lots more option to tune compared to Mikrotik Web Proxy.

I’m so sure, the problems you have would be solved.

ilius168 · September 11, 2007, 1:30pm

thank you all for the responds and advice.

I think i just found a solution, where i limit the number of connection to 5, hell it did stop the greedy client from download at its queue limit & the webproxy is not working to the max bandwidth anymore.

here is the code i use

65   ;;; Limit connection to 5
     chain=forward action=drop tcp-flags=syn src-address=192.168.10.13 
     protocol=tcp connection-limit=6,32

i’ll look into t3rm suggestion about squid in linux. But what i like about MT is the real time traffic monitoring where we can’t get in linux. Or is there something else?

Cheers