Proxy/Gateway - masquerading problems with two subnets

Hi folks,

we have a problem with a transparent Proxy (using Squid etc.) with different
subnets. Our Proxy is a replacement for a Watchguard box which died happy
last week.

This is the external part of the network:

Internet
|
(eth_dyn: ???.???.???.???)
ADSL-Router
(eth_lan: 192.168.99.9/24)
|
(eth_isp: 192.168.99.9/24)
additional Firewall/Proxy
(eth_lan: 172.16.250.11)
|
--------------------
| 2nd Building
Conware Router <- ISDNBOX 192.168.x.x <-- ISDNBOX 192.168.x.x <- Conware
| |
(172.16.0.0/16) (172.18.0.0/16)
Subnet 16 Subnet 18
| |
Example Box: Example Box:
172.16.250.2/16 172.18.200.28/16

Like you can see, different Buildings are connected via a fix ISDN
connection, probabely a few years old, this setup.

With the 172.16.0.0/16 subnet, everything works fine and works like
expected.

But with the other subnets, we have problems with masquerading I think.

For example: If someone makes a web-request from let's say 172.18.200.2,
we see the domain-request routed out correctly, but that's it:

IN=eth_lan OUT=eth_isp SRC=172.18.200.2 DST=sme.whr.out.tre LEN=72 TOS=0x00
PREC=0x00 TTL=125 ID=8718 PROTO=UDP SPT=1293 DPT=53 LEN=52


And let's say, our actual simplest debugging iptables script would look like
this:
8<-------------8<-------------8<-------------8<-------------8<-------------
$IPTABLES -P INPUT ACCEPT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P FORWARD ACCEPT

echo " * Accept estabished and related packets..."
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

echo " * Drop packets that do not match any valid state..."
$IPTABLES -N drop_invalid
$IPTABLES -A OUTPUT -m state --state INVALID -j drop_invalid
$IPTABLES -A INPUT -m state --state INVALID -j drop_invalid
$IPTABLES -A FORWARD -m state --state INVALID -j drop_invalid
$IPTABLES -A drop_invalid -j LOG --log-level debug --log-prefix "INVALID
state DENY: "
$IPTABLES -A drop_invalid -j DROP

echo " * Setting up PREROUTING - redirect HTTP for a transparent proxy"
$IPTABLES -t nat -A PREROUTING -i ${INTERNAL_INTERFACE} -p tcp --dport 80 -j
REDIRECT --to-port ${SQUID_DEFAULT_PORT}

echo " * Setting up POSTROUTING masquerading..."
$IPTABLES -t nat -A POSTROUTING -o ${EXTERNAL_INTERFACE} -j MASQUERADE

echo " * Telling the kernel that ip-forwarding is OK"
echo 1 > /proc/sys/net/ipv4/ip_forward

for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 1 > $f ; done
8<-------------8<-------------8<-------------8<-------------8<-------------

Unfortunately, it's not possible to change any IP-Addresses or netmasks
because the internal lan's setups are to complex to let you change
something without wide reaching consequences in the wole internal net.

But I'm sure this can be solved.

Unfortunately, I'm more a software and system developer than an networking
expert, so perhaps you may lend me a helping hand to get this setup going?
Ah, btw, yes, I already read the advanced routing howto but couldn't find a
solution.

If you have any hints or directly know how to solve this problem, I'd be
very glad. Maybe you could also name me one or two helpful
console-programs?

Many thanks in advance for every reply.
Yous Henri

Henri Schomäcker wrote:
> Hi folks,
....
> But with the other subnets, we have problems with masquerading I think.
>
> For example: If someone makes a web-request from let's say 172.18.200.2,
> we see the domain-request routed out correctly, but that's it:
>
> IN=eth_lan OUT=eth_isp SRC=172.18.200.2 DST=sme.whr.out.tre LEN=72 TOS=0x00
> PREC=0x00 TTL=125 ID=8718 PROTO=UDP SPT=1293 DPT=53 LEN=52

You mean that's all?
Does it work?:
- from 172.18.200.2: ping -c1 172.16.250.11
- from 172.18.200.2: ping -c1 www.google.com
- from 172.16.250.11: ping -c1 172.18.200.2

If not, check your route to 172.18.0.0/16 on 172.16.250.11.
If yes, and you could see www pages properly from 172.18.200.2
without squid - you can check it now by adding for a while:
$IPTABLES -t nat -I PREROUTING -i ${INTERNAL_INTERFACE} -s
172.18.0.0/16 -j ACCEPT
and removing after test:
$IPTABLES -t nat -D PREROUTING -i ${INTERNAL_INTERFACE} -s
172.18.0.0/16 -j ACCEPT

- than it's probably something with squid.conf

Jarek P.