> > > > 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/0xffffffff [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,