streaming on blue?
No. I am streaming on green.
This is almost exactly my setting.
From my point of view, the answer is: no difference. A transparent proxy is just a convenience, however if you correctly set all the web browsers of your users to use http://ipfire.localdomain:800 you will have the same effect without introducing the complexity of a voluntary “man in the middle attack” kind of setting. You already need to do this for encrypted communications, why not go all the way and do the same also for unencrypted connections?
In your screen shot
Green is no enabled.
This is why I ask.
1 Like
I disabled it temporarily to get my streaming working.
Glade you got it working
Your still ahead of me.
Have not tried proxy.
Did you have to add additional ports
For additional services?
I am curious to know if while you keep the transparent proxy disabled, you enable the proxy on green and set the proxy on your browser. Does the stream still work? I would bet that it does and the problem is limited to the transparent setting.
The streaming device is a separate box. I’ve gone through all of the device’s menus and their Community (discourse also!). There are no proxy settings.
So I need to find a way to tell the web proxy to ignore the streaming box at 192.168.60.218
and / or
to ignore the streaming service at http://name-changed.s3.amazonaws.com.
So eventually I’d like to set up the conventional proxy (non-transparent mode) but I don’t think it will help today since the streaming device does not have proxy settings.
what about suricata. Can it be a change of some of the rules there?
suricata (IPS) is disabled at the moment while I do testing. So I am not sure if this will help.
I’m reading through this:
https://wiki.squid-cache.org/SquidFaq/SquidAcl
and trying to decide which directive will help
Just in case it can help you to figure this out: from my understanding the transparent proxy is done in two steps.
- a rule in iptables, in the prerouting queue where all the traffic going for port 80 is redirected to port 3128. Something like
iptables -t nat -A PREROUTING -i blue0 -p tcp --dport 80 -j REDIRECT --to-port 3128
- in squid configuration
http_port 3128 intercept
that instructs squid to proxy that traffic.
So maybe I could add an iptables entry before to help me ?!? That’s a possibility!
I am experimenting with adding acl’s at the moment. So if this doesn’t work I’ll add this to the list!
Current test with this in the include.acl
EDIT: Wow! this is tougher than imagined!
from this Q&A on serverfault:
This did not work:
acl someserver dstdomain name-changed.s3.amazonaws.com
cache deny someserver
and this did not work:
acl local-servers dstdomain name-changed.s3.amazonaws.com
always_direct allow local-servers
On to more acl “tests”!
I suspect yours is a routing problem. I am afraid that an ACL list, even if used as intended, is not going to prevent the changing of IP caused by the iptable redirect rule and therefore your connection will still be waiting for 683 seconds for an answer that is lost in the bit oblivion. However Jon, you know that I know very little of these things, therefore I expect to be wrong. You will figure this out. At this point, I am very curious to see this to the end.
2 Likes
Interesting bypass solution! ← next test.
https://wiki.squid-cache.org/KnowledgeBase/TransparentProxySelectiveBypass
Again ip address
Interesting iptables is involved.
Pre routing.
Could a firewall rule work the same?
Ip streaming severs host group.
NAT to
Streaming device ip.
?
Maybe! This is beyond me at the moment. Time to read and learn about iptables.
I am not sure how to integrate something similar to this (below) into the IPFire firewall rules and iptables.
iptables -t nat -N BYPASS
iptables -t nat -A PREROUTING -s SQUIDIP -p tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 80 -j BYPASS
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3129
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -t nat -A BYPASS -d www.example.com -j ACCEPT
I can see some of this already exists within the nat iptables:
iptables --list-rules --table nat
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-N CAPTIVE_PORTAL
-N CUSTOMPOSTROUTING
-N CUSTOMPREROUTING
-N IPSECNAT
-N NAT_DESTINATION
-N NAT_DESTINATION_FIX
-N NAT_SOURCE
-N OVPNNAT
-N REDNAT
-N SQUID
-A PREROUTING -j CUSTOMPREROUTING
-A PREROUTING -j CAPTIVE_PORTAL
-A PREROUTING -j SQUID
-A PREROUTING -j NAT_DESTINATION
-A OUTPUT -j NAT_DESTINATION
-A POSTROUTING -j CUSTOMPOSTROUTING
-A POSTROUTING -j OVPNNAT
-A POSTROUTING -j IPSECNAT
-A POSTROUTING -j NAT_SOURCE
-A POSTROUTING -j NAT_DESTINATION_FIX
-A POSTROUTING -j REDNAT
-A NAT_DESTINATION -s 192.168.60.0/24 -p tcp -m tcp --dport 53 -j REDIRECT
-A NAT_DESTINATION -s 192.168.60.0/24 -p udp -m udp --dport 53 -j REDIRECT
-A NAT_DESTINATION -s 192.168.65.0/24 -p tcp -m tcp --dport 53 -j REDIRECT
-A NAT_DESTINATION -s 192.168.65.0/24 -p udp -m udp --dport 53 -j REDIRECT
-A NAT_DESTINATION -s 192.168.60.0/24 -p udp -m udp --dport 123 -j REDIRECT
-A NAT_DESTINATION -s 192.168.65.0/24 -p udp -m udp --dport 123 -j REDIRECT
-A NAT_DESTINATION_FIX -m mark --mark 0x1000000/0xf000000 -j SNAT --to-source 192.168.60.1
-A NAT_DESTINATION_FIX -m mark --mark 0x2000000/0xf000000 -j SNAT --to-source 192.168.65.1
-A NAT_DESTINATION_FIX -m mark --mark 0x4000000/0xf000000 -j SNAT --to-source 10.1.1.1
-A REDNAT -o red0 -m policy --dir out --pol ipsec -j RETURN
-A REDNAT -o red0 -j MASQUERADE
-A SQUID -d 73.123.345.0/32 -i green0 -p tcp -m tcp --dport 80 -j RETURN
-A SQUID -i green0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
-A SQUID -d 73.123.345.0/32 -i blue0 -p tcp -m tcp --dport 80 -j RETURN
-A SQUID -i blue0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
This looked interesting
Some acl types require suspending the current request in order
to access some external data source.
Those which do are marked with the tag [slow], those which
don’t are marked as [fast].
See SquidFaq/SquidAcl - Squid Web Proxy Wiki
for further information
***** ACL TYPES AVAILABLE *****
acl aclname src ip-address/mask ... # clients IP address [fast]
acl aclname src addr1-addr2/mask ... # range of addresses [fast]
acl aclname dst [-n] ip-address/mask ... # URL host's IP address [slow]
acl aclname localip ip-address/mask ... # IP address the client connected to [fast]
http://www.squid-cache.org/Doc/config/acl/
I particularly this part
acl aclname dst [-n] ip-address/mask … # URL host’s IP address [slow]
1 Like
I’m back! But I cannot get a squid bypass to work. I thought I understood iptables enough to make this work. But no. 
This is where I am at today.
Problem
I cannot use a streaming device and it is related to Squid 5.x. No issues found with Squid 4.x.
The streaming service suddenly ends with Transparent web proxy enabled. I get this squid message in the access log:
1647144914.348 683 192.168.60.218 TCP_MISS_ABORTED/100 0
PUT http://name-changed.s3.amazonaws.com/SID_1234567890/123456/data.ts -
ORIGINAL_DST/52.217.123.123 -
No other messages found in any other logs.
Workaround (not preferred)
If I disable the Web Proxy (and the Transparent), all works A-OK:
No bad messages in the squid access log (or the message log).
Past Experiment #1 - bypass the Squid 
with ACLs
I tried various squid settings (e.g., ACLs) to bypass for one local IP 192.168.60.218 and that did not work.
I left out this info just to keep this post a little shorter.
I set squid ACLs aside for a little time . . .
Past Experiment #2 - bypass the Squid with iptables
I am hoping I can use iptables to bypass squid.
Here is the bypass post:
and I am stuck in the same spot. I am not sure how to integrate the below into my existing iptables.
I added this in the firewall.local file:
iptables -t nat -N BYPASS
iptables -t nat -A PREROUTING -s 192.168.60.218/32 -p tcp -m tcp --dport 80 -j BYPASS
iptables -t nat -A BYPASS -d 52.0.0.0/8 -j ACCEPT
and then I ran /etc/rc.d/init.d/firewall restart && /etc/rc.d/init.d/squid restart
And then I see:
[root@ipfire ~] # iptables --list-rules --table nat
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-N BYPASS
-N CAPTIVE_PORTAL
-N CUSTOMPOSTROUTING
-N CUSTOMPREROUTING
-N IPSECNAT
-N NAT_DESTINATION
-N NAT_DESTINATION_FIX
-N NAT_SOURCE
-N OVPNNAT
-N REDNAT
-N SQUID
-A PREROUTING -j CUSTOMPREROUTING
-A PREROUTING -j CAPTIVE_PORTAL
-A PREROUTING -j SQUID
-A PREROUTING -j NAT_DESTINATION
-A PREROUTING -s 192.168.60.218/32 -p tcp -m tcp --dport 80 -j BYPASS
-A OUTPUT -j NAT_DESTINATION
-A POSTROUTING -j CUSTOMPOSTROUTING
-A POSTROUTING -j OVPNNAT
-A POSTROUTING -j IPSECNAT
-A POSTROUTING -j NAT_SOURCE
-A POSTROUTING -j NAT_DESTINATION_FIX
-A POSTROUTING -j REDNAT
-A BYPASS -d 52.0.0.0/8 -j ACCEPT
-A NAT_DESTINATION -s 192.168.60.0/24 -p tcp -m tcp --dport 53 -j REDIRECT
-A NAT_DESTINATION -s 192.168.60.0/24 -p udp -m udp --dport 53 -j REDIRECT
-A NAT_DESTINATION -s 192.168.65.0/24 -p tcp -m tcp --dport 53 -j REDIRECT
-A NAT_DESTINATION -s 192.168.65.0/24 -p udp -m udp --dport 53 -j REDIRECT
-A NAT_DESTINATION -s 192.168.60.0/24 -p udp -m udp --dport 123 -j REDIRECT
-A NAT_DESTINATION -s 192.168.65.0/24 -p udp -m udp --dport 123 -j REDIRECT
-A NAT_DESTINATION_FIX -m mark --mark 0x1000000/0xf000000 -j SNAT --to-source 192.168.60.1
-A NAT_DESTINATION_FIX -m mark --mark 0x2000000/0xf000000 -j SNAT --to-source 192.168.65.1
-A NAT_DESTINATION_FIX -m mark --mark 0x4000000/0xf000000 -j SNAT --to-source 10.7.4.1
-A REDNAT -o red0 -m policy --dir out --pol ipsec -j RETURN
-A REDNAT -o red0 -j MASQUERADE
-A SQUID -d 73.36.250.0/32 -i green0 -p tcp -m tcp --dport 80 -j RETURN
-A SQUID -i green0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
-A SQUID -d 73.36.250.0/32 -i blue0 -p tcp -m tcp --dport 80 -j RETURN
-A SQUID -i blue0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
[root@ipfire ~] #
But I get the exact same error in the squid access log.
Is there an iptables guru that can help me bypass the squid?
I changed this in the firewall.local file:
To this:
iptables -t nat -A CUSTOMPREROUTING -s 192.168.60.218/32 -p tcp -m tcp --dport 80 -j BYPASS
And I am getting less “issues”.
So now it is time time test!