> -----Original Message-----
> From: Hanasaki JiJi [mailto:[EMAIL PROTECTED]
> Sent: Thursday, 5 June 2003 2:42 PM
> To: List - Debian Security
> Subject: question squid + firewall + http server inside firewall
> 
> 
> I have the below rules in my firewall.  the http server is inside the 
> firewall on  192.168.1.2:80
>       people can hit it fine from the outside
>       squid is running on the firewall
>       inside can browser ouside via squid just fine
>       inside cannot browse the outside address
> 
> Any thought/input would be appreciated.
> 
> # http server
> $PROG -t nat -A PREROUTING -i $NIC_EXTERNAL -p tcp \
>          -s 0/0 --dport http \
>          -j DNAT --to-destination 192.168.1.2:80
> $PROG -t mangle -A FORWARD -i $NIC_EXTERNAL -s 0/0 \
>          -o $NIC_INTERNAL -d 192.168.1.2 -p tcp --dport http \
>          -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

I've experienced a similar problem getting NAT'd external IPs to work 
internally. 

The problem arose because whilst the destination address of a packet is being 
translated through DNAT the source address still remains untranslated as the 
internal adddess. This means that the returning packet was being sent to the 
internal address directly without passing through the firewall, thus to the 
internal machine it appears to originate from the internal IP and will be 
discarded because it isn't part of the TCP connection.

To remedy this you need a iptables rule to translate the source address of 
internal packets destined for the external address of the internal server to be 
the firewall machine's IP.

For example add a rule like:

    iptables -t nat -A POSTROUTING -o $NIC_INTERNAL -p tcp \
                -s 192.168.1.0/24 -d 192.168.1.2 --dport http \
                -j SNAT --to-source $FIREWALL_IP

This way the internal http server will be sending it's responses to the 
firewall and NAT will be able to translate the addresses to correctly respond 
to the original packet.

I hope this helps; it's been a while since I had this problem and this is all 
from memory.

Regards,

Michael

-- 
Michael Sharman
Dytech Solutions
(03) 6224 4116
[EMAIL PROTECTED]



                

Reply via email to