Hi there

General question, I have a VM that is running SQUID as a proxy. This works perfect when I update any computer to use the Proxy server directly.
This works for HTTP and HTTPS

I have one Mikrotik router that connects to the internet on eth1.
Question, is it possible to use the SQUID proxy as a VM as a proxy for all connections to MK before reaching the internet?
Example, I any device connects to the router to use the internet, it needs to send the internet traffic to the proxy server, from the proxy server it will go back to the same router to reach the internet.

Hi there

General question, I have a VM that is running SQUID as a proxy. This works perfect when I update any computer to use the Proxy server directly.
This works for HTTP and HTTPS

I have one Mikrotik router that connects to the internet on eth1.
Question, is it possible to use the SQUID proxy as a VM as a proxy for all connections to MK before reaching the internet?
Example, I any device connects to the router to use the internet, it needs to send the internet traffic to the proxy server, from the proxy server it will go back to the same router to reach the internet.

Yes, it is possible to use the SQUID proxy running on a VM as a proxy for all connections that pass through the Mikrotik router before reaching the internet.

One way to do this is by configuring the Mikrotik router to forward all incoming traffic to the SQUID proxy server. This is typically done by setting up port forwarding on the router, so that all traffic on port 80 (for HTTP) and port 443 (for HTTPS) is forwarded to the IP address of the SQUID proxy server.

Another way is by configure the Mikrotik as a transparent proxy, in this way the Mikrotik will intercept the traffic and forward to the Squid proxy, this can be done by the Mikrotik firewall rules, marking the HTTP and HTTPS traffic, and redirecting them to the proxy.

In either case, the SQUID proxy server will need to be configured to allow the router's IP address as a trusted client, and to allow traffic to pass through to the internet.

Keep in mind that if your Squid proxy has SSL bumping feature enable for SSL, you should make sure that Mikrotik router can handle SSL, otherwise the traffic will be blocked by Squid.

You should test the configuration with some troubleshooting and monitoring, to see if there's any issues or traffic not being forwarded correctly.

Also, you should keep the security in mind, the traffic between the Mikrotik and the proxy will be sent unencrypted, so it is a good idea to use a VPN connection between these two devices for secure communication.

Hi there

General question, I have a VM that is running SQUID as a proxy. This works perfect when I update any computer to use the Proxy server directly.
This works for HTTP and HTTPS

I have one Mikrotik router that connects to the internet on eth1.
Question, is it possible to use the SQUID proxy as a VM as a proxy for all connections to MK before reaching the internet?
Example, I any device connects to the router to use the internet, it needs to send the internet traffic to the proxy server, from the proxy server it will go back to the same router to reach the internet.

Yes, it is possible to use the SQUID proxy running on a VM as a proxy for all connections that pass through the Mikrotik router before reaching the internet.

One way to do this is by configuring the Mikrotik router to forward all incoming traffic to the SQUID proxy server. This is typically done by setting up port forwarding on the router, so that all traffic on port 80 (for HTTP) and port 443 (for HTTPS) is forwarded to the IP address of the SQUID proxy server.

Another way is by configure the Mikrotik as a transparent proxy, in this way the Mikrotik will intercept the traffic and forward to the Squid proxy, this can be done by the Mikrotik firewall rules, marking the HTTP and HTTPS traffic, and redirecting them to the proxy.

In either case, the SQUID proxy server will need to be configured to allow the router's IP address as a trusted client, and to allow traffic to pass through to the internet.

Keep in mind that if your Squid proxy has SSL bumping feature enable for SSL, you should make sure that Mikrotik router can handle SSL, otherwise the traffic will be blocked by Squid.

You should test the configuration with some troubleshooting and monitoring, to see if there's any issues or traffic not being forwarded correctly.

Also, you should keep the security in mind, the traffic between the Mikrotik and the proxy will be sent unencrypted, so it is a good idea to use a VPN connection between these two devices for secure communication.

Hi there

Thank you for taking the time to reply.
I have explored those two options, with no luck. I have done some reading on how to implement it, and the traffic reaches the proxy server, but doesn't do anything else. The client connection will then timeout.

When using the mark packets options, there is no way to set a route to a specific port number on the proxy server, so you will then forward all marked http 80 traffic to port 80 on the proxy server. That is my assumption. The connection times out and I receive error:transaction-end-before-headers error on SQUID.

When using the port forwarding, I can forward all http 80 traffic to port 3128 on the proxy server. This gives me the same error as above. However, it appears that the client doesn't timeout, and is able to use the internet, but the actual data flow isn't going through the proxy server, but still direct to the mikrotik router.

Will still try to explore

Transparent proxy for HTTPS (port 443) is not possible - not in TLS v1.3 and higher (because SNI is already encrypted). Transparent proxy with port redirection in general is connection hijacking: client thinks it's talking to end server, in reality it talks to proxy server. Which is fine until client can not verify server's identity - which is true in case of plain HTTP but not true with HTTPS (because server has to present certificate) - or client doesn't care about server's identity (e.g. if user clicks the "accept risk and continue").

When configuring browser explicitly to use proxy things work because client knows it's going to talk to proxy. In addition, often it uses HTTP connection to proxy to fetch HTTPS contents ... in this case it delegates the task to verify server's identity to (trusted) proxy. If proxy connection is over HTTPS (that's also an option), then again client knows it's talking to proxy and certificate is used to verify proxy's identity.

Yes, it is possible to use the SQUID proxy running on a VM as a proxy for all connections that pass through the Mikrotik router before reaching the internet.

One way to do this is by configuring the Mikrotik router to forward all incoming traffic to the SQUID proxy server. This is typically done by setting up port forwarding on the router, so that all traffic on port 80 (for HTTP) and port 443 (for HTTPS) is forwarded to the IP address of the SQUID proxy server.

Another way is by configure the Mikrotik as a transparent proxy, in this way the Mikrotik will intercept the traffic and forward to the Squid proxy, this can be done by the Mikrotik firewall rules, marking the HTTP and HTTPS traffic, and redirecting them to the proxy.

In either case, the SQUID proxy server will need to be configured to allow the router's IP address as a trusted client, and to allow traffic to pass through to the internet.

Keep in mind that if your Squid proxy has SSL bumping feature enable for SSL, you should make sure that Mikrotik router can handle SSL, otherwise the traffic will be blocked by Squid.

You should test the configuration with some troubleshooting and monitoring, to see if there's any issues or traffic not being forwarded correctly.

Also, you should keep the security in mind, the traffic between the Mikrotik and the proxy will be sent unencrypted, so it is a good idea to use a VPN connection between these two devices for secure communication.

Hi there

Thank you for taking the time to reply.
I have explored those two options, with no luck. I have done some reading on how to implement it, and the traffic reaches the proxy server, but doesn't do anything else. The client connection will then timeout.

When using the mark packets options, there is no way to set a route to a specific port number on the proxy server, so you will then forward all marked http 80 traffic to port 80 on the proxy server. That is my assumption. The connection times out and I receive error:transaction-end-before-headers error on SQUID.

When using the port forwarding, I can forward all http 80 traffic to port 3128 on the proxy server. This gives me the same error as above. However, it appears that the client doesn't timeout, and is able to use the internet, but the actual data flow isn't going through the proxy server, but still direct to the mikrotik router.

Will still try to explore

It sounds like you are running into some issues with configuring your Mikrotik router and SQUID proxy server to work together correctly.

When using the mark packets options, you're correct that you would forward all marked HTTP traffic to port 80 on the proxy server. However, this would only work if your Mikrotik router is able to also set a route to send that marked traffic to the IP address of the proxy server. If the router is not able to set that route, the traffic will not reach the proxy server and the connection will timeout.

Regarding port forwarding, when you forward all HTTP traffic to port 3128 on the proxy server, it means that the traffic is reaching the proxy server, however it's possible that the configuration of the SQUID proxy is not correct.

A common issue that can cause these problems is a mismatch between the IP address of the Mikrotik router and the IP address of the SQUID proxy server.
Make sure that the IP address of the router and the IP address of the proxy server are in the same network and that the port forwarding is set to the correct IP address of the proxy server.

Another thing you could check is that the proxy server is set up to allow the traffic from the router. This can be done by checking the access control list (ACL) on the SQUID server, which defines which IP addresses or networks are allowed to connect to the proxy.

Lastly, it would also be helpful to check the squid access.log and cache.log to see if there are any errors or issues that are preventing the traffic from flowing through the proxy.

Transparent proxy for HTTPS (port 443) is not possible - not in TLS v1.3 and higher (because SNI is already encrypted). Transparent proxy with port redirection in general is connection hijacking: client thinks it's talking to end server, in reality it talks to proxy server. Which is fine until client can not verify server's identity - which is true in case of plain HTTP but not true with HTTPS (because server has to present certificate) - or client doesn't care about server's identity (e.g. if user clicks the "accept risk and continue").

When configuring browser explicitly to use proxy things work because client knows it's going to talk to proxy. In addition, often it uses HTTP connection to proxy to fetch HTTPS contents ... in this case it delegates the task to verify server's identity to (trusted) proxy. If proxy connection is over HTTPS (that's also an option), then again client knows it's talking to proxy and certificate is used to verify proxy's identity.

You are correct that transparent proxying of HTTPS traffic (port 443) is not possible using traditional methods because the SNI (Server Name Indication) extension in the HTTPS handshake is typically encrypted, so the proxy server cannot read it to determine the hostname of the requested website. This is true in TLS v1.3 and higher.

It is also correct that Transparent proxy with port redirection in general is connection hijacking, the client thinks it's talking to the end server, but in reality it talks to the proxy server, this is not a problem for HTTP because the client does not care about the server's identity, but for HTTPS it does because the server has to present a valid certificate for the client to trust it.

Therefore, in general, when configuring a browser explicitly to use a proxy, things work because the client knows it's going to talk to the proxy. This allows the proxy to intercept the HTTPS request and present its own certificate to the client, which is then used to verify the identity of the proxy server.

There are other alternatives to transparently proxy HTTPS traffic such as SSL bump (or SSL interception) but it requires that the client to trust the root CA of the certificate presented by the proxy. This can be done by installing the root CA on the client or the client device, but it will warn the user about an untrusted certificate.

Another option is to use a man-in-the-middle (MITM) proxy, but it also require the client to trust a root CA certificate installed on the proxy. this is often used in enterprise environments where the client is under control of the organization.