On 2014-02-27 02:51, Scott Mayo wrote:
I thought I would post this here also, even though I think it is more
of an IPTABLES question, but my Squid box is affecting the outcome. I
have it posted on netfilter.
My main Squid Filter has Private IP of 192.168.1.1 (eth1) and a public
IP of 1.1.1.1 (eth0). It also has a virtual public IP of 1.1.1.2
(eth0:0). I have a web server that sits behind the Squid box with
name EXAMPLE.ORG and a private IP of 192.168.1.2, which resolves to
the 1.1.1.2. Everything works fine outside the network when I go to
EXAMPLE.ORG. Everything works fine in the network if I go to
EXAMPLE.ORG without pointing my browser to the Squid proxy.
Which of the two domain IPs does it get resolved to for these internal
tests?
Which of the two domain IPs does it get resolved to for the Squid tests?
You have this rule:
$IPTABLES -t nat -A PREROUTING -d 1.1.1.2 -p tcp -j DNAT
--to-destination 192.168.0.2
Note that IP after NAT is *.0.2 instead of *.1.2
Once I
point my browser to the Squid proxy though and try to go to
EXAMPLE.ORG, it comes back to the webpage of 1.1.1.1 which is my Squid
box. Any idea why it would matter if I go through Squid or not?
What is the kernels idea of the "master IP" for the Squid box?
It sounds like it should be 1.1.1.1 but it may not be.
Squid outgoing traffic will use that IP as sender by default.
Do you have tcp_outgoing_address configured in squid.conf to change the
default sending IP to an explicit one?
I broke my IPTABLES down to almost nothing just to test. I'll post
them below in case anyone uses them and can tell me if I need to do
something different to make them work with Squid. I am about to give
up. I DO NOT have an internal DNS server so right now that is not an
option. I am getting ready to set one up, but wanted this working
first. I assume the internal DNS server will get rid of the problem,
I hope it does not matter at that point if I go though Squid or not.
Thanks for any suggestions.
Depends on the Squid version whether you need an internal DNS server or
not for local traffic (latest Squid support mDNS now
http://master.squid-cache.org/Versions/v3/3.4/RELEASENOTES.html#ss2.6).
Having one is a good idea though for external traffic to reduce the
overall latency.
Relying on an external DNS server, then yes all traffic will go through
the public IPs instead of the LAN ones. Which means all traffic goes to
your gateway firewall then back into the LAN. You may have something
like /etc/hosts settings avoiding that, but from the iptables settings
I'm doubting.
-------------------------------------------------------------
<snip>
$IPTABLES -t nat -A PREROUTING -d 1.1.1.2 -p tcp -j DNAT
--to-destination 192.168.0.2
** this is applied to the Squid outgoing traffic. Resulting in a TCP
connection:
1.1.1.1 -> 192.168.0.2
$IPTABLES -t nat -A POSTROUTING -d 192.168.0.2 -s 192.168.0.0/16 -j
SNAT --to-source 1.1.1.2
$IPTABLES -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 1.1.1.1
** squid should be using box master IP (-s 1.1.1.1) so the POSTROUTING
rules are not applied.
I do not see any MASQUERADE rule to undo the PREROUTING DNAT operation
for reply packets.
So this should be what Squid sees:
1.1.1.1 SYN -> 1.1.1.2
1.1.1.1 <-ACK 192.168.0.2
Amos
