MikroTik

hi all,

I'm configuring follow:
http://wiki.mikrotik.com/wiki/Queue_wit ... _Web-Proxy

MikroTik, I saw debung bellow:
/log print

feb/05 09:57:09 web-proxy,debug
feb/05 09:57:09 web-proxy,account 10.150.5.5 GET http://insider.msg.yahoo.com/client_ad. ... 3809925703 action=allow cache=MISS

do you have a question?

thanks normis,

I cant open web site but i can ping.
what error?

I'm use Mikrotik V 3.20

My configure:
/ip proxy
set always-from-cache=yes cache-administrator=webmaster cache-hit-dscp=4 cache-on-disk=yes enabled=yes max-cache-size=none max-client-connections=600 max-fresh-time=3d max-server-connections=600 parent-proxy=0.0.0.0 parent-proxy-port=0 port=3128 serialize-connections=yes src-address=0.0.0.0

/ip firewall nat
add action=masquerade chain=srcnat comment="Mikrotik2 to Mikrotik1" disabled=no src-address=10.150.5.5
add action=masquerade chain=srcnat comment="" disabled=no src-address=10.150.15.1
add action=redirect chain=dstnat comment="" disabled=no dst-port=80 protocol=tcp to-ports=3128

/ip firewall mangle
add action=change-mss chain=forward comment="This rule is needed to surf some sites which require lower MTU - Microsoft!!!" disabled=no new-mss=1440 protocol=tcp tcp-flags=syn
add action=mark-packet chain=prerouting comment="" disabled=no new-packet-mark=test-up passthrough=no
add action=mark-connection chain=forward comment="" disabled=no new-connection-mark=test-conn passthrough=yes
add action=mark-packet chain=output comment="" disabled=no new-packet-mark=test-down passthrough=no

do you try to disable webproxy and surfing same webpage again?

regards

thanks chapex,

when i disable web proxy, can open webpage.

Hi,

Let me add something to it.

Since i have upgraded to 3.20 i am unable to use Web-Proxy Feature. There is some sort of bug in it thats for sure.
Every thing was working fine till 3.17 then suddenly 3.18 started the problem, then came 3.19 almost the same problem, then 3.20 the problem is at its peak.

Please check the proxy feature in 3.20, becasue its not working for me since the time i upgraded.

So what happens?

"It's not working" is not much of a problem description.

Do you get any entries in the log?
Is it completely "dead" or does it work sometimes?
Is you sniff the outside interface, can you see the proxy trying to connect to the destination http server?

Are you both running in transparent mode? If you configure your browser to use the proxy as a normal HTTP proxy, does it work then?

I'm very curious as I'm just about to put a Mikrotik proxy into production running 3.20 or the upcoming 3.21 version that has a fix for HTTPS through a parent proxy. So of course I want to make sure it's completely stable. All my tests with 3.20 has worked flawlessly at least. But I've only been able to test it using a parent-proxy and as a normal non-transparent proxy though.

/Mathias

Hi,

Dear i have been using this feature for sometime now, but this is the first time i am facing issues.

I have send support file to support lets see what do they tell me.

Hi,
Dear i have been using this feature for sometime now, but this is the first time i am facing issues.

Dear? So you think that statement answers any of my questions above? How do you expect anyone to be able to help finding the problem if you can't provide any details and answer the questions we have?

I didn't ask all those questions to try telling you you have done anything wrong if that's what you thought, I asked them because knowing the answers would help pinpointing the problem and make it easier to reproduce the problem.

I've tried to reproduce the problem but cannot. I've tried 3.13, 3.17, 3.18, 3.20, 3.21(beta) and they all work perfect for me. They work both in transparent mode (redirecting 80 -> 8080) for HTTP, in normal proxy mode and with and without a parent proxy. I havn't been able to test fully without a parent proxy though as the network I'm testing on does not allow direct outbound connects, but I can see correct requests are sent out my external interface.

While testing I found bug though that causes the web-proxy to use the wrong src-address when processing requests that come from a client on the internal interface and the dest server is on the external interface. It then incorrectly picks the internal IP address as src-address when sending out the request to the dest server. So you might wanna test explicitly setting src-address to the IP address you want it to use.

This problem seemed to exist also in 3.13 and 3.17 as well as the newer ones so it shouldn't be your problem, unless something else changed at the same time causing you to get punished by this bug just at this time.

Try to put dstnat before srcnat. Just put dstnat in the first row.

Try to put dstnat before srcnat. Just put dstnat in the first row.

Hmm, does that really matter?

Isn't RouterOS using normal iptables/netfilter from the linux kernel todo packet filtering and nating? If so, it shouldn't matter as srcnat and dstnat rules goes into two different iptables chains, so I can't see why it should make any difference if you add a src- or dst- nat rules before the other or reverse.

But it never hurts trying though - I could be wrong

Hi,

Firewall rules are read from top to bottom, same in linux, it does not matter to which chain it belongs.
If the rule at top matches the query it will not go to any other rule to check. So its very important to make your DST-NAT Rule above all.

Hi,

Firewall rules are read from top to bottom, same in linux, it does not matter to which chain it belongs.
If the rule at top matches the query it will not go to any other rule to check. So its very important to make your DST-NAT Rule above all.

Wrong! (On Linux with iptables atleast)

Each chain is traversed independently from top to bottom. DNAT is done in the prerouting chain which is processed before the any routing decision is made, while SNAT is done in the postrouting chain. So the order you add rules in are only significant for a specific chain. If you add the SNAT rules first and then the DNAT rules, or you first add all DNAT rules and then the SNAT rules really shouldn't matter.

The DNAT rules will always be processed first anyway as they are processed by the prerouting chain.

Ref: http://www.faqs.org/docs/iptables/trave ... ables.html

why don't you test out? and report the result.

the problem also happens to me.
when i restart my mikrotik. i connect to the internet , no page load. there is ping.
but when i go to winbox and to to IP PROXY and go to settings and just press OK. the browse and the internet works simply.
we need to fix this issue.

Can we downgrade a single package ? as downgrading http proxy to 3.17 ? whats the name of the package.

Hi,

msundman is right, i just messed it up. Mikrotik is making my Linux skills weak. By the he is right, in linux iptables work on chaing

1. PREROUTING
2. INPUT
3. FORWARD
4. OUTPUT
5. POSTROUTING

Rules are read in chains following the orders of chain above.

However not same in Mikrotik, rules are read from top to bottom, and i had personally experienced it.

As this got very off-topic, I started a new thread about how NAT chains are traversed on ROS:

http://forum.mikrotik.com/viewtopic.php?f=2&t=29723