Re: [squid-users] Re: transparent proxy on remote box issue
On 2/11/2013 7:24 p.m., WorkingMan wrote: There is a very specific order of packet flow required to get these things working. And an equally specific order of configuration and testing needed to ensure that it is all working. I have taken the liberty of re-arranging the details you posted to follow the order of configuration necessary to show working testing at every step. IFF (and only if) you have advanced networking skills can you do these stages out of order. Start reading the below text and comments *in-order* and ensure each machine is showing the expected behaviour before moving on to the next one. If any one of these stages fails to show the expected behaviour please stop and ask for more help before continuing or experimenting further (Im not perfect, but lets not have to re-do/undo anything complex if I make a mistake writing this up in advane of the test results). ] It's very simple I want this flow to happen. client (10.100.0.0/16) -port 500/4500- VPN server (10.0.0.170) VPN server (10.0.0.170) - port 80- SQUID (10.0.0.117) -- Default Gateway (10.0.0.1) VPN server (10.0.0.170) - ! port 80- Default Gateway (10.0.0.1) So the Squid machine is the only one supposed to have direct contact to Internet for this traffic. We start there, ensuring that it works properly before setting up anything to depend on it. ** ensure the 10.0.0.1 has NAT setup to convert any 10.0.0.0/24 or 10.100.0.0/16 to public IP as is the duty of a gateway. ** ensure that 10.0.0.170 and 10.0.0.117 *both* have default gateway of 10.0.0.1 TEST .. at this point you should: 1) be able to make any communication directly from 10.0.0.117 to any public Internet machine. 2) be able to make any communication directly from 10.0.0.170 to any public Internet machine. 3) tcpdump on 10.0.0.117 does NOT show any traffic from 10.0.0.170 during test (2) VPN Server - Web Site (SQUID's mac), ** ensure the 10.0.0.117 machine has these configured: (/etc/sysctl.conf) net.ipv4.conf.default.rp_filter=0 net.ipv4.conf.all.rp_filter=0 net.ipv4.ip_forward=1 ** also configure the policy based routing to ensure packets leaving 10.0.0.170 destintion port 80 are routed to 10.0.0.117. TEST .. at this point by generating test traffic from 10.0.0.170 you should see in tcpdump: 1) port-80 packets 10.0.0.170 being delivered to the 10.0.0.117 machine (visible in 10.0.0.170 tcdumps) 2) port-80 packets arriving into the 10.0.0.117 machine (visible on 10.0.0.117 tcpdumps) 3) other traffic working fine, if you want to check that it is NOT visible on the 10.0.0.117 machine you can also do that. IMPORTANT: if any one of the tests above fails to have the expected result we will need to dig deeper into what is going on there between them. VPN Client - VPN Server ** on the client 10.100.0.0/16 configure the default gateway to be 10.0.0.170 (or whatever the client-end of the VPN is set to). ** ensure that the routing done by 10.0.0.170 and 10.0.0.117 is able to route 10.100.0.0/16 traffic. NOTICE how there is no mention of NAT between 10.100.0.0/16 and 10.0.0.0/24. All the routing table entries for 10.0.0.0/24 machines need to be able to handle packets with IP addresses in 10.100.0.0/16 NOTE: things will get quite complicated if you want other WAN connections from the client device. Leave that complication out of the system for now. TEST ... at this point what you should see when generating traffic from the client machine 10.100.0.0/16: 1) all client packets being delivered to 10.0.0.170 (visible on the client machine) 2) all client packets are visible arriving on the 10.0.0.170 (visible on 10.0.0.170). 3) client port-80 packets being delivered to 10.0.0.117 (visible on 10.0.0.170). 4) from client viewpoint everything should be working fine. IF and only if the above tests are all passed sucesfully are you ready to start the Squid and interception parts of the configuration. They take place on the Squid box and consists only of the LinuxDnat / LinuxRedirect configuration examples in the Squid wiki. Can you just tell me what I need to do to make this work? It seems we are back to square one. It would go faster if you tell me everything in one reply instead of feeding each other with bits of information then change direction with each new information that comes along. We have indeed gone down several different network topology configurations and ended back at step 1. It would have helped if we had started with the intended network diagram below. It's very simple I want this flow to happen. client (10.100.0.0/16) -port 500/4500- VPN server (10.0.0.170) VPN server (10.0.0.170) - port 80- SQUID (10.0.0.117) -- Default Gateway (10.0.0.1) VPN server (10.0.0.170) - ! port 80- Default Gateway (10.0.0.1) I am not sure if http response goes directly to original client or goes back from the route where it came from so It could be incorrectly drawn above. It SHOULD be going back via the Squid box. The above is good.
Re: [squid-users] Re: transparent proxy on remote box issue
On 2/11/2013 9:17 p.m., WorkingMan wrote: One hint I had was that the traffic are not marked correctly. This line if added (I got it from somewhere online) will change the mac address of the web site to be the one of SQUID: iptables -t mangle -A OUTPUT -o eth0 -p tcp --dport 80 -j MARK --set-mark 2 With that rule: 06:13:38.327212 0a:a5:82:f8:2e:93 (VPN's mac) 0a:3c:e1:08:45:b7 (SQUID's mac), IPv4, length 74: 10.0.0.170.57525 157.166.248.10.80 (web site): tcp 0 Without that rule: 06:01:59.823267 0a:a5:82:f8:2e:93 (VPN's mac) 0a:ee:81:f6:13:ef (SQUID's mac), IPv4, length 66: 10.0.0.170.43154 157.166.249.11.80 (web site): tcp 0 This diagram explains the flow of PRE/POSTROUTING/OUTPUT/FORWARD: http://users.ecs.soton.ac.uk/ajf101/kptd.pdf It is very simplified, but yes. For a better view use this diagram as written by the netfilter xtables author: http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg So OUTPUT rule makes a different because I am testing from a local process (ie: curl on VPN server). Sorry my fault here, I made a mistake in crafting the tests. You are right about OUTPUT being needed or _they_ fail. But that is only for the curl tests and traffic generated on the VPN server itself. You *also* need identical iptables rules in the mangle PREROUTING tables for the clients traffic we are intending to route. We are trying to use the MARK to influence the arrows leaving routing decision box on left and side of the diagram for client 10.100.0.0/16 traffic and either the routing decision or the reroute check on the right hand side for curl tests. I then tried from VPN client (inbound traffic) and POSTROUTING makes a difference here (putting SQUID's mac). Here some notes: #marking inbound traffic: iptables -t mangle -A PREROUTING -i eth0 -p tcp --dport 80 -j MARK --set- mark 2 #marking outbound traffic (ie: locally generated traffic): iptables -t mangle -A OUTPUT -o eth0 -p tcp --dport 80 -j MARK --set-mark 2 Anyhow that doesn't explain to me why market traffic is not going to SQUID. Did you also have the special routing table created for the marked packets? If you have that setup. You could try without the -i / -o parameters and see if the interface/outerface is correct. Amos
Re: [squid-users] Re: transparent proxy on remote box issue
On 2/11/2013 9:46 p.m., WorkingMan wrote: I have confidence that we can get to the bottom of this with this level of details. I am currently stuck at this step: VPN Server - Web Site (SQUID's mac) This was also where I was stuck before. At this point I am simply issuing a curl www.cnn.com from VPN server (VPN client/SQUID not involved) If I follow: http://www.tldp.org/HOWTO/TransparentProxy-6.html What happens is that it says use DNAT/SNAT + policy routing and that in the end didn't do any policy routing since MAC address to the web site didn't point to SQUID's mac address. Okay please drop that how-to. It is for a completely different network topology than your diagram showed. If I follow http://wiki.squid- cache.org/ConfigExamples/Intercept/IptablesPolicyRoute. Mac address of web site is SQUID's mac address but somewhere I get packet loss because it just keeps retransmitting the same http request. I had to add one extra rule to arrive to this behavior (see below). There are several use-case configurations in that page. You need the one under When Squid is in a DMZ between the router and Internet. There is no traffic going to SQUID other than ARP (for getting mac address). One hint I had was that the traffic are not marked correctly. This line if added (I got it from somewhere online) will change the mac address of the web site to be the one of SQUID: iptables -t mangle -A OUTPUT -o eth0 -p tcp --dport 80 -j MARK --set- mark 2 OUTPUT ??? none of the routing tutorials you have been looking at mention doing anything in OUTPUT. *PREROUTING* table (as in the before routing table of rules) is the one you should be altering on the VPN server. - Reset the VPN server config from these changes, - go back to http://wiki.squid-cache.org/ConfigExamples/Intercept/IptablesPolicyRoute. - follow the section When Squid is in a DMZ between the router and Internet - follow the section Routing Setup - then re-run the 4 tests I outlined for this stage of configuration. With that rule: 06:13:38.327212 0a:a5:82:f8:2e:93 (VPN's mac) 0a:3c:e1:08:45:b7 (SQUID's mac), IPv4, length 74: 10.0.0.170.57525 157.166.248.10.80 (web site): tcp 0 Without that rule: 06:01:59.823267 0a:a5:82:f8:2e:93 (VPN's mac) 0a:ee:81:f6:13:ef (SQUID's mac), IPv4, length 66: 10.0.0.170.43154 157.166.249.11.80 (web site): tcp 0 Easily explained. MARK are not set on the packet, they are flags in the kernel metadata about a connection. I'm doubt if they show up in a tcpdump, but they definitely will not leave the machine they are used on. On SQUID I followed this: http://wiki.squid- cache.org/ConfigExamples/Intercept/LinuxRedirect There is no traffic going to SQUID according to tshark (unless there is just not showing up) so we can ignore this for now. Rewind. That is steaming on way ahead of where things are broken. Amos I followed DMZ + policy routing and it still same result (tested with VPN client). *mangle :PREROUTING ACCEPT [383:47877] :INPUT ACCEPT [311:32547] :FORWARD ACCEPT [149:20258] :OUTPUT ACCEPT [302:67329] :POSTROUTING ACCEPT [451:87587] [77:4928] -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j MARK --set-xmark 0x2/0x [77:4928] -A PREROUTING -m mark --mark 0x2 -j ACCEPT COMMIT # Completed on Sat Nov 2 08:30:56 2013 # Generated by iptables-save v1.4.18 on Sat Nov 2 08:30:56 2013 *nat :PREROUTING ACCEPT [13:864] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [5:354] :POSTROUTING ACCEPT [0:0] [18:1218] -A POSTROUTING -o eth0 -j MASQUERADE Source-NATing the outbound traffic. I take it this is intended to happen on the traffic back to the client network? If so, try adding the parameter: -d 10.100.0.0/16 so only that client reply traffic is NAT'ed. COMMIT # Completed on Sat Nov 2 08:30:56 2013 # Generated by iptables-save v1.4.18 on Sat Nov 2 08:30:56 2013 *filter :INPUT ACCEPT [311:32547] :FORWARD ACCEPT [149:20258] :OUTPUT ACCEPT [313:68601] COMMIT ip route list table http default via 10.0.0.117 dev eth0 ip rule show 0: from all lookup local 219:from all fwmark 0x2 lookup http 220:from all lookup 220 32766: from all lookup main 32767: from all lookup default ip route default via 10.0.0.1 dev eth0 10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.170 Can you make this work on your end? My wireless POP have a wifi link where yours has a VPN link. But otherwise the same as what you seem to be trying to setup. There is a subtle difference in your 10.0.0.0/24 being in a cloud though. Mine are physical Ethernet between CPE. Amos
Re: [squid-users] Re: transparent proxy on remote box issue
Hey there, Man you need to understand something. Your basic routing doesn't help in any way. In your case you should have a network which is a simple thing... I do not rembebr the machine settings but once you have a strickt default via IP the packets should flow throw this host. try to make sure first that ICMP packet flows from one machine to the other. Then and only then try to make the packet flow from let say: VPN-MAIN-GW then try to access the internet and see what happens on both GW and VPN machines. you do have 10.0.0.1/24 as a Default GW so try to reach from 10.0.0.170 using 10.0.0.1 to the internet let say to google or yahoo or even my site.. ngtech.co.il. this basic network setup should work if configured properly and if the network infrastructure supports it. If even one of all the above is not met you will not succed and then you we will be back to routing which we can try to help but it means you have a way ahead before making squid work. can you by any chance remove all these mark setting and go back to routing just to make the basic setup work as it suppose to? And also the OUTPUT is another step after all the traffic to and from the internet back to this host is working.. Eliezer On 11/02/2013 10:46 AM, WorkingMan wrote: I followed DMZ + policy routing and it still same result (tested with VPN client). *mangle :PREROUTING ACCEPT [383:47877] :INPUT ACCEPT [311:32547] :FORWARD ACCEPT [149:20258] :OUTPUT ACCEPT [302:67329] :POSTROUTING ACCEPT [451:87587] [77:4928] -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j MARK --set-xmark 0x2/0x [77:4928] -A PREROUTING -m mark --mark 0x2 -j ACCEPT COMMIT # Completed on Sat Nov 2 08:30:56 2013 # Generated by iptables-save v1.4.18 on Sat Nov 2 08:30:56 2013 *nat :PREROUTING ACCEPT [13:864] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [5:354] :POSTROUTING ACCEPT [0:0] [18:1218] -A POSTROUTING -o eth0 -j MASQUERADE COMMIT # Completed on Sat Nov 2 08:30:56 2013 # Generated by iptables-save v1.4.18 on Sat Nov 2 08:30:56 2013 *filter :INPUT ACCEPT [311:32547] :FORWARD ACCEPT [149:20258] :OUTPUT ACCEPT [313:68601] COMMIT ip route list table http default via 10.0.0.117 dev eth0 ip rule show 0: from all lookup local 219:from all fwmark 0x2 lookup http 220:from all lookup 220 32766: from all lookup main 32767: from all lookup default ip route default via 10.0.0.1 dev eth0 10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.170 Can you make this work on your end? Thanks,
Re: [squid-users] Re: transparent proxy on remote box issue
Just to make sure I understood: How many boxes do you have? what is VPN and what is SQUID? You do understand that there is no way to run TPROXY on amaozn safely?? So leave TPROXY out of sight for now. If you have two machines it's another story. if you do have one machine then what is the: ip route iptables-save and ip addr output for this machine? Eliezer On 10/31/2013 10:52 PM, WorkingMan wrote: I am suspecting something is going on but I am just not seen it in the logs. tshark is not catching anything either by host IP or port 3130 on either VPN/SQUID. Does the TPROXY way work for SQUID on a remote server because I was going to try that next? ping, dns lookup all seems normal except for port 80 (all apps not using port 80 works). with clean.rules set using your suggested rules I see this (client can browse but doesn't look like it went to SQUID server at all) Src: 10.100.0.1 (10.100.0.1, VPN client), Dst: 176.32.98.168 (amazon) Src: 10.0.0.170 (10.0.0.170, VPN), Dst: 176.32.98.168 (176.32.98.168) Src: 176.32.98.168 (176.32.98.168), Dst: 10.0.0.170 (10.0.0.170) Let's just say things look normal. With proxy.rules (policy based routing), I see alot of TCP retransmission from VPN client/server to the web server. 10.0.0.170 - 157.166.248.10 TCP 78 60440 http [SYN] Seq=0 Win=65535 Len=0 MSS=1240 WS=16 TSval=230783310 TSecr=0 SACK_PERM=1 10.0.0.170 - 157.166.248.11 TCP 78 [TCP Retransmission] 60437 http [SYN] Seq=0 Win=65535 Len=0 MSS=1240 WS=16 TSval=230783793 TSecr=0 SACK_PERM=1 10.100.0.1 - 157.166.249.10 TCP 78 [TCP Retransmission] 60438 http [SYN] Seq=0 Win=65535 Len=0 MSS=1240 WS=16 TSval=230783995 TSecr=0 SACK_PERM=1 it does this until it gives up. I hope that rings a bell. I could be debugging this wrong and not seen the obvious. There is no trace on SQUID server or its log so I assume traffic didn't made it over. On VPN server when I do a query to a web site it works which is weird because I thought it should also get routed since all tcp on eth0 ared marked (also no log in access.log on squid side so it's not routed). Thanks, Update. Found this, https://forums.gentoo.org/viewtopic-t-932554-start- 0.html, that helped me look at the mac address of the src/dst. With proxy.rules now with above info I see mac address of the web site is the mac address of SQUID server. Again I only see one direction traffic going to the web site. At least we know it's doing something that looks correct. With clean.rules, web site's mac address is the gateway/DNS (in my case is the same mac). I see bidirectional traffic between web site and VPN server. On SQUID server I have applied 4 rules from this SQUID guide: http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxRedirect There is no traffic to SQUID using tshark. Nothing in SQUID logs or syslog. Nothing in VPN's syslog. Thanks,
Re: [squid-users] Re: transparent proxy on remote box issue
On 11/01/2013 10:30 AM, WorkingMan wrote: I am not using TPROXY. VPN/SQUID are two different servers. OK now you mangled everything!! try to start from scratch which means design. Put the VPN on the same squid server or retry to design the network in a way it will work. Once you will prepare the network from scratch to work in a basic way we can try to dive in into squid and proxy land. Regards, Eliezer
Re: [squid-users] Re: transparent proxy on remote box issue
On 2/11/2013 9:42 a.m., WorkingMan wrote: Eliezer Croitoru eliezer at ngtech.co.il writes: On 11/01/2013 10:30 AM, WorkingMan wrote: I am not using TPROXY. VPN/SQUID are two different servers. OK now you mangled everything!! try to start from scratch which means design. Put the VPN on the same squid server or retry to design the network in a way it will work. Once you will prepare the network from scratch to work in a basic way we can try to dive in into squid and proxy land. Regards, Eliezer Are you saying it's not possible to redirect traffic from a VPN server to a remote SQUID server box with policy based routing without an actual router (from the wiki it wasn't clear if that's the case or not: http://wiki.squid-cache.org/ConfigExamples/Intercept/IptablesPolicyRoute)? You assume there is such as thing as actual router. Any machine with routing configuration enabled is a router. Even desktop machines and smartphones can be routers if configured to do so. I don't like the idea of running SQUID on the VPN server because it won't scale. If I need to add more SQUID servers how will I route the traffic (so back to the original problem). It can be done either way. However; 1) each relay/router machine the traffic goes through adds another location where you need to setup the special routing. 2) each location may require *different* form of policy based routing or static routing. 3) If you miss any one of the relay/routers out you will see traffic lost/dropped and hung client connections. Currently I have this when policy based routing is applied (see full topology below): [ There is a very specific order of packet flow required to get these things working. And an equally specific order of configuration and testing needed to ensure that it is all working. I have taken the liberty of re-arranging the details you posted to follow the order of configuration necessary to show working testing at every step. IFF (and only if) you have advanced networking skills can you do these stages out of order. Start reading the below text and comments *in-order* and ensure each machine is showing the expected behaviour before moving on to the next one. If any one of these stages fails to show the expected behaviour please stop and ask for more help before continuing or experimenting further (Im not perfect, but lets not have to re-do/undo anything complex if I make a mistake writing this up in advane of the test results). ] It's very simple I want this flow to happen. client (10.100.0.0/16) -port 500/4500- VPN server (10.0.0.170) VPN server (10.0.0.170) - port 80- SQUID (10.0.0.117) -- Default Gateway (10.0.0.1) VPN server (10.0.0.170) - ! port 80- Default Gateway (10.0.0.1) So the Squid machine is the only one supposed to have direct contact to Internet for this traffic. We start there, ensuring that it works properly before setting up anything to depend on it. ** ensure the 10.0.0.1 has NAT setup to convert any 10.0.0.0/24 or 10.100.0.0/16 to public IP as is the duty of a gateway. ** ensure that 10.0.0.170 and 10.0.0.117 *both* have default gateway of 10.0.0.1 TEST .. at this point you should: 1) be able to make any communication directly from 10.0.0.117 to any public Internet machine. 2) be able to make any communication directly from 10.0.0.170 to any public Internet machine. 3) tcpdump on 10.0.0.117 does NOT show any traffic from 10.0.0.170 during test (2) VPN Server - Web Site (SQUID's mac), ** ensure the 10.0.0.117 machine has these configured: (/etc/sysctl.conf) net.ipv4.conf.default.rp_filter=0 net.ipv4.conf.all.rp_filter=0 net.ipv4.ip_forward=1 ** also configure the policy based routing to ensure packets leaving 10.0.0.170 destintion port 80 are routed to 10.0.0.117. TEST .. at this point by generating test traffic from 10.0.0.170 you should see in tcpdump: 1) port-80 packets 10.0.0.170 being delivered to the 10.0.0.117 machine (visible in 10.0.0.170 tcdumps) 2) port-80 packets arriving into the 10.0.0.117 machine (visible on 10.0.0.117 tcpdumps) 3) other traffic working fine, if you want to check that it is NOT visible on the 10.0.0.117 machine you can also do that. IMPORTANT: if any one of the tests above fails to have the expected result we will need to dig deeper into what is going on there between them. VPN Client - VPN Server ** on the client 10.100.0.0/16 configure the default gateway to be 10.0.0.170 (or whatever the client-end of the VPN is set to). ** ensure that the routing done by 10.0.0.170 and 10.0.0.117 is able to route 10.100.0.0/16 traffic. NOTICE how there is no mention of NAT between 10.100.0.0/16 and 10.0.0.0/24. All the routing table entries for 10.0.0.0/24 machines need to be able to handle packets with IP addresses in 10.100.0.0/16 NOTE: things will get quite complicated if you want other WAN connections from the client device. Leave that complication out of the system for now.
Re: [squid-users] Re: transparent proxy on remote box issue
On 31/10/2013 7:38 a.m., WorkingMan wrote: I hope I can refocus this question to the real problem. I am currently have a working VPN setup but once I add my policy routing rules it breaks the client's port 80 connection (everything else still good, apps still work. I don't any traffic going to my SQUID server. First of all I don't use cache. I read http://wiki.squid-cache.org/ConfigExamples/Intercept/IptablesPolicyRoute but it says Please realize that this just gets the packets to the cache; you have to then configure interception on the cache itself to redirect traffic to the Squid TCP port!. Do I have to do that if I don't use cache (it didn't say what to do)? cache is still used in a lot of places to mean proxy. This was one of them. (I've updated the config wording now.) Steps taken: #policy routing kernel requirement - OK #grep CONFIG_IP_ADVANCED_ROUTER /boot/config-$(uname -r) #grep CONFIG_IP_MULTIPLE_TABLES /boot/config-$(uname -r) #CONFIG_IP_ROUTE_FWMARK is deprecated in option but enabled by default #they say rp_filer can mess up policy routing so disabled it - OK /etc/sysctl.conf net.ipv4.ip_forward=1 net.ipv4.conf.default.rp_filter=0 net.ipv4.conf.all.rp_filter=0 #executed following with my own IPs and table names - breaks connection iptables -t mangle -A PREROUTING -p tcp --dport 80 -s $SQUID -j ACCEPT iptables -t mangle -A PREROUTING -i eth0 -p tcp --dport 80 -j MARK --set-mark 2 iptables -t mangle -A PREROUTING -m mark --mark 2 -j ACCEPT iptables -t filter -A FORWARD -i eth0 -o eth0 -p tcp --dport 80 -j ACCEPT echo 201 http /etc/iproute2/rt_tables ip rule add fwmark 2 table http ip route add default via $SQUID table http ip route table list http (OK): default via $SQUID dev eth0 ip route (OK): default via 10.0.0.1 dev eth0 10.0.0.0/24 dev eth0 proto kernel scope link src $VPN route -n (OK): Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 10.0.0.10.0.0.0 UG0 00 eth0 10.0.0.00.0.0.0 255.255.255.0 U 0 00 eth0 ip rule (OK): 0: from all lookup local 219:from all fwmark 0x2 lookup http 220:from all lookup 220 32766: from all lookup main 32767: from all lookup default The short summary is that once I add iptables -t mangle -A PREROUTING -i eth0 -p tcp --dport 80 -j MARK --set-mark 2 VPN client's http traffic is broken. I am not able to determine where the traffic is lost/dropped/redirected to (nothing showing on SQUID server). Some questions that might lead you in a useful direction for solving this: * is eth0 the right interface to be operating with? does VPN have an interface of its own with better results? is there something special you have to add on top of all this to make it work over a VPN connection? (all the testing done so far has been on regular ethernet and wireless connections). * when the packets go from client to Squid to Internet they are still labeled by TPROXY as having come from the client IP. What path do they take back to the client? is Squid box with its TPROXY logics on that return path? Amos
Re: [squid-users] Re: transparent proxy on remote box issue
Hey, On 10/31/2013 09:58 AM, WorkingMan wrote: iptables -t nat -A POSTROUTING -j MASQUERADE try to flush all the iptables rules by: iptables -t nat -F iptables -t filter -F iptables -t mangle -F then add the next: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE sysctl -w net.ipv4.ip_forward=1 The above rules should make the client able to do any network thing he needs to if the vpn client and server are configured to route all the traffic to the VPN server. then use tcpdump: tcpdump -i eth0 -nn port 80 to see what traffic is being sent from the server to the web. then and only after these tests are made (note that the -F might need the POSTROUTING or any other name of a table after it) you can minimize the cause of the problem to the VPN level or to the iptables or any other level. can you by any chance run a ifconfig -a command and share the output? Eliezer
Re: [squid-users] Re: transparent proxy on remote box issue
On 10/29/2013 06:30 PM, WorkingMan wrote: The short answer is I need a transparent proxy (url rewrite and traffic inspection) behind VPN (going for the security not for speed; cache will not be used; proxy only). This is maybe squid area Amazon VPC - 10.0.0.0/16 (subnet goes under that CIDR) VPN client - ex: iphone (10.100.0.0/16 virtual pool) vpn - 10.0.1.2 squid - 10.0.1.3 (in practice it would go under 10.0.2.0/24 and use NAT to go to WAN but for making this simpler I use the same subnet) I am not very good with linux networking so I think most of the issue is with networking and routing. Not related to squid but a tiny leap to help with can happen. My first attempt using VPC with this setup ended up with VPN client not able to access anywhere. I suspect routing was not correct because I can see DNS request and answer and some traffic going to the web site but there is no response coming back to the client. Masquarade is what you are looking for.(iptables and MASQUARDE) I am using (similar steps in both guides): http://www.tldp.org/HOWTO/TransparentProxy-6.html http://lartc.org/howto/lartc.cookbook.squid.html I am in the process of re configuring from scratch. If you have sure way of making this work let me know. basically VPN setup is not an issue but routing traffic to remote SQUID server and back is something that I am not able to do successfully. Depends on the VPN client.. What VPN client have you used until now? Eliezer
Re: [squid-users] Re: transparent proxy on remote box issue
On 26/10/2013 8:46 a.m., WorkingMan wrote:
What I tried:
1)with clean.rules I can connect to VPN and access internet without any
issue
1b)On SQUID or VPN server curl -x http://localhost:3130 www.nba.com works
2) with proxy.rules VPN client get invalid URL (previously mentioned error).
proxy is not intercept or transparent
http_port 3130
http_access allow all
#used the first method
#http://www.tldp.org/HOWTO/TransparentProxy-6.html
There is part of your problem. The first method does not work. It has
never worked except as a side effect of a security vulnerability bug,
which has now been fixed.
export vpnclients=VPN client IP; ex: 10.10.0.0/24
export SQUID=SQUID IP
export SQUID_PORT=SQUID PORT
iptables -t nat -A PREROUTING -i eth0 ! -s ${SQUID} -p tcp --dport 80 -j
DNAT --to ${SQUID}:${SQUID_PORT}
iptables -t nat -A POSTROUTING -o eth0 -s ${vpnclients} -d ${SQUID} -j SNAT
--to ${SQUID}
iptables -A FORWARD -s ${vpnclients} -d ${SQUID} -i eth0 -o eth0 -p tcp --
dport ${SQUID_PORT} -j ACCEPT
It did mention that HTTP/1.0 will not work properly for some reason. It's
not possible to test the second method since EC2 classic doesn't allow me to
add a second network interface (I will probably have to try VPC later on)
Interfaces are relevant to this setup. Whats the problem?
I tried to understand the issue from the code but it wasn't 100% clear.
client_side.cc(2319) parseHttpRequest: HTTP Client local=SQUID IP:3130
remote=VPN server:65090 FD 10 flags=1
client_side.cc(2320) parseHttpRequest: HTTP Client REQUEST:
-
GET / HTTP/1.1
Host: www.nba.com
Accept-Encoding: gzip, deflate
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8^M
Cookie: s_fid=32FDC9FA0E2D94CE-297956A1143A207A; s_vi=
[CS]v1|28AFB9BC0501287A-61094003481F[CE]^M
Connection: keep-alive
Accept-Language: en-us
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 7_0_2 like Mac OS X)
AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11A501
Safari/9537.53
This looks good to me and works (test and works as a request) but then I see
this error message and then it went to show SQUID's error page. It doesn't
really tell me why it's not working.
That line above the headers is showing the problem:
HTTP Client local=SQUID IP:3130 remote=VPN server:65090 FD 10
flags=1
local= contains the details of www.nba.com server where the request is
being fetched original dst IP:port from the TCP packets.
remote= contains the client src IP:port from the TCP packets.
Your NAT is still being done at the client end of the connection before
it reaches the Squid box. This is THE problem. Move the NAT rules.
1) the client end of the VPN needs to contain the routing and MARK rules
from section 6.2 of that page.
2) the VPN tunnel needs to deliver those packets directly onto the Squid
box. Avoiding any problems ECN may cause with routing the packets.
2a) at this point you should still be able to browse the web without
problems. However your packets should be going over the VPN without any
browser or test tool mention of the Squid box IP.
3) the Squid box needs to contains the REDIRECT rule from section 6.2 on
that page, and probably the MASQUERADE rule from section 6.3. Squid
needs the intercept http_port option.
3a) at this point you should still be able to browse the web without
problems using *identical* tests to those made in (2a) when there was no
proxy used. However the traffic should be logged in Squid access.log.
skipping the rest of your Qs because the necessary info is already
logged in those lines above
Amos
Re: [squid-users] Re: transparent proxy on remote box issue
On 24/10/2013 3:45 p.m., WorkingMan wrote: 1) why intercept mode fails (do I need any special rule on my remote SQUID box?) with access denied for all requests Where is the NAT/TPROXY interception happening for (1)? It is required to be done directly on the Squid machine, with packets sent to that machine by *routing* or *tunnelling* (VPN) in such as way as the TCP packet IP:port details st by the client are completely untouched by the network before they hit the Squid machine. Typically in the past your type of setup has used NAT at the client end (it was easy), which actually erases the destination IP details and replaces them with the Squid machine IP:port. The problems this caused were hidden for a long time but recent security checks are preventing the Host header being used to determine the outbound connection when they occur. For now Squid preserves the behaviour the client would have seen by going to the TCP destination IP:port ... redirection is done from VPN server to SQUID server. I don't have special routing on SQUID's server the reason is that from VPN server I can query external web site if I use non-intercept port (I have one that has intercept and one without). So I assume routing is working fine. That means routing of packets out of Squid to Internet is fine. Routing of packets between the client and Squid on port 80 is a completely different story. You *need* to know what is going on there to be sure that Squid is even receiving the right packet details. The command I used is curl -x http://SQUID IP:PORT www.cnn.com What you need is this command to work and the packets to reach Squid with destination IP:port of www.cnn.com: curl www.cnn.com Let me know if I need to add additional iptables rule for this to work. If I enter the proxy info wrong curl just waits there (probably till timeout). If address/port are correct but SQUID was not running I will get connection refused. So it tells me routing from VPN to SQUID for port 80 seems to work but intercept is the reason I get access denied (I can't figure out why yet even with full log). Where in the full log can I know why I get access denied? The curl parameters -x http://SQUID IP:PORT tells curl to format an **HTTP proxy syntax request** and send it to that IP:port. Routing non-Squid IPs and interception are never involved. Sending such a request to an intercept port *will* always fail because the destination IP:port at the TCP level are SQUID IP:PORT... it will infinitely loop back to SQUID IP:PORT when leaving the proxy. Port 80 uses different syntax for requests and the IP:port delivered are the remote origin server IP:port. 2) in non-intercept mode why VPN client would have the missing hostname in the request. (2) is not clear what you mean. What do you see that is indicating a missing hostname ? When I say hostname is missing. It means I get (see my first post) NONE/400 3544 GET / instead of TCP_MISS/403 3544 GET www.cnn.com/ Ah. This is a port 80 syntax request: GET / HTTP/1.1 Host: www.cnn.com User-Agent: curl Accept: */* As you can see the http://www.cnn.com; part does not exist and must be figured out by the proxy from other data sources. Squid uses TCP packet destination IP:port details, or Host header but only if Host DNS records match the TCP packet IP:port. When the above request is delivered to Squid in packets with TCP destination IP of SQUID IP:PORT you get a loop, from client to Squid to Squid where its rejected the response goes back to Squid then client. I also use cache deny all (and http_access allow all, I assume that allows access to everything, see my first post for full config I have except these two) to use no cache not sure if that affect the out come? Not for these routing and TCP problems. This is about what data is given to Squid to figure out the real URL for outbound relaying. That is done very first thing on request arrival. I think you need to take a step back from both Squid and the intercept part. 1) Ensure that the Squid box is setup with *ony* the packet routing port 80 packets from the VPN to Internet and Internet responses back down VPN tunnel. 2) Ensure that a client request for any web URL gets routed down the VPN to the Squid box AND successfully connects directly to that domains servers. Note that Squid and NAT/TPROXY interception should both be turned off while all that is being setup and tested. I cannot stress enough that it MUST work without the proxy if the proxy is going to have any chance of working reliably when it is used. Only when both of the above are checked and found working can you start configuring interception and proxy on the Squid machine. Amos
Re: [squid-users] Re: transparent proxy on remote box issue
On 24/10/2013 9:45 a.m., WorkingMan wrote: It appears that one of the test I was doing is not correct so it can yield some hint to the problem. -k reconfigure didn't take effect when I made the change. So for the browser with direct proxy setting. I am able to browse correctly if not using intercept (ie: using SQUID server's public IP directly). Everything else is still the same as described above. So there are two issues that I can observe. 1) why intercept mode fails (do I need any special rule on my remote SQUID box?) with access denied for all requests Where is the NAT/TPROXY interception happening for (1)? It is required to be done directly on the Squid machine, with packets sent to that machine by *routing* or *tunnelling* (VPN) in such as way as the TCP packet IP:port details st by the client are completely untouched by the network before they hit the Squid machine. Typically in the past your type of setup has used NAT at the client end (it was easy), which actually erases the destination IP details and replaces them with the Squid machine IP:port. The problems this caused were hidden for a long time but recent security checks are preventing the Host header being used to determine the outbound connection when they occur. For now Squid preserves the behaviour the client would have seen by going to the TCP destination IP:port ... 2) in non-intercept mode why VPN client would have the missing hostname in the request. (2) is not clear what you mean. What do you see that is indicating a missing hostname ? Amos
