I am using the “Dmitry on Firewalling” (http://wiki.mikrotik.com/wiki/Dmitry_on_firewalling) example to try out the proxy server. It’s not getting any hits and I can’t figure out why. I want to make sure that there are no problems with that example. Has anyone run into this? I can see that mangling works fine for marking http (80 and 8080) but the rule is not hit for mangling with ‘proxy’ when port is 3128. Is the pre-routing chain the correct one for this?
Many thanks,
P
Do you have any traffic to destination port 3128 running through the router? If not the rule cant match anything.
Oh yes. I definitely see traffic to 3128. I’ve got dstnat redirect that handles that. So the flow is supposed to be something like:
mangle:tcp 80/8080 marked with ‘http’
dstnat: redirect ‘http’ to 3128
mangle: tcp 3128 marked with ‘proxy’
firewall filter: ‘proxy’ accepted as a local input service
I don’t think the connections are being marked with proxy because I don’t see them getting picked up by the firewall filter and nothing makes it as far as the proxy.
I solved my own problem but I’d love to hear confirmation from others since I can’t believe I’m the first to run into this when implementing the suggested rules in Dmitry on Firewalling:
So it turns out that the mangle rule that marks the redirected http connection with ‘proxy’ needs to be in the input chain rather than pre-routing since the redirect to the routers port for the web proxy goes directly to the input chain rather than pre-routing again. Can anyone confirm?
I have a feeling I’ve done something weird because I can’t believe no one would have caught this before…
Makes total sense.
http://wiki.mikrotik.com/wiki/Manual:Packet_Flow
Abbreviated:
[Stuff] → Pre-routing mangle → DST-NAT → [Stuff] → Routing Decision → Input mangle → [Stuff] → Local process gets the packet
Pre-routing mangle sees the packet, but it hasn’t been redirected yet. DST-NAT redirects the packet to the router itself. Pre-routing mangle is already past, so the packet isn’t ever seen in that facility again - packets do not re-enter the stack at the top when an action is taken. A routing decision is made, and the source address of the packet matches that of a local interface so it gets put into the ‘input’ chain - first mangle, then filter.
Should have caught that in the original post. Sorry.
I have found the same thing and then read your post. Would it make sense to also run the mangle list for the tcp-services and udp-services through for input as well?