Hi Oskar and others, Problem solved after made the following changes. Thanks for all help.
/sbin/iptables -t nat -A PREROUTING -p tcp -d $INET_IP --dport 80 -j DNAT --to $HTTP_IP /sbin/iptables -t nat -A POSTROUTING -p tcp -d $HTTP_IP --dport 80 -j SNAT --to $LAN_IP /sbin/iptables -t nat -A OUTPUT -p tcp -d $INET_IP --dport 80 -j DNAT --to $HTTP_IP -- Best regards, Kenneth mailto:[EMAIL PROTECTED] Wednesday, May 15, 2002, 7:02:22 PM, you wrote: OA> Hi Kenneth, OA> I don't know if this will help, but I've had quite a lot of people asking me about this problem recently so I've written up a small explanation of the problem. It should be released in a couple OA> of weeks or so with the iptables tutorial (currently) located at http://www.linux-sxs.org/iptables/. This will change rather soon, this is the "main site" only temporary because the real one went OA> down :(. OA> Anyways, this is in Docbook code, hence it may a bit hard to read but I hope it will be no problem. Also, I hope this really is in reply to your problems :). If it does not cover your problem, OA> disregard from it. OA> <para> Since <command>DNAT</command> requires quite a lot of work to OA> work properly, I have decided to add a larger explanation on how to work OA> with it. Let's take a brief example on how things would be done normally. OA> We want to publish our website via our internet connection. We only have OA> one IP address, and the <systemitem>HTTP server</systemitem> is located on OA> our internal network. Our firewall has the external IP address OA> <command>$INET_IP</command>, and our <systemitem>HTTP server</systemitem> OA> has the internal IP address <command>$HTTP_IP</command> and finally the OA> firewall has the internal IP address <command>$LAN_IP</command>. The first OA> thing to do is to add the following simple rule to the OA> <systemitem>PREROUTING</systemitem> chain in the nat table: OA> </para> OA> <literallayout> OA> <command> OA> iptables -t nat -A PREROUTING --dst $INET_IP --dport 80 -j DNAT --to-source $HTTP_IP OA> </command> OA> </literallayout> OA> <para> Now, all packets from the internet going to port 80 on our OA> firewall are redirected (or <command>DNAT</command>'ed) to our internal OA> <systemitem>HTTP</systemitem> server. If you test this from the internet, OA> everything should work just perfect. So, what happens if you try OA> connecting from a host on the same local network as the OA> <systemitem>HTTP</systemitem> server? It will simply not work. This is a OA> problem with routing really. We start out by dissect what happens in a OA> normal case. The external box has IP address <command>$EXT_BOX</command>, OA> to maintain readability. OA> </para> OA> <orderedlist> OA> <listitem> OA> Packet leaves the connecting host going to OA> <command>$INET_IP</command> and source <command>$EXT_BOX</command>. OA> </listitem> OA> <listitem> OA> Packet reaches the firewall. OA> </listitem> OA> <listitem> OA> Firewall <command>DNAT</command>'s the packet and run the packet OA> through all different chains etcetera. OA> </listitem> OA> <listitem> OA> Packet leaves the firewall and travels to the $HTTP_IP. OA> </listitem> OA> <listitem> OA> Packet reaches the <systemitem>HTTP</systemitem> server, and the OA> <systemitem>HTTP</systemitem> box replies back through the firewall, if OA> that is the box that the routing database has entered as the gateway for OA> <command>$EXT_BOX</command>. Normally, this would be the default gateway OA> of the <systemitem>HTTP</systemitem> server. OA> </listitem> OA> <listitem> OA> Firewall Un-<command>DNAT</command>'s the packet again, so the packet OA> looks as if it was replied to from the firewall itself. OA> </listitem> OA> <listitem> OA> Reply packet travels as usual back to the client OA> <command>$EXT_BOX</command>. OA> </listitem> OA> </orderedlist> OA> <para> Now, we will consider what happens if the packet was instead OA> generated by a client on the same network as the OA> <systemitem>HTTP</systemitem> server itself. The client has the IP address OA> <command>$LAN_BOX</command>, while the rest of the machines maintain the OA> same settings. OA> </para> OA> <orderedlist> OA> <listitem> OA> Packet leaves <command>$LAN_BOX</command>. OA> </listitem> OA> <listitem> OA> The packet reaches the firewall. OA> </listitem> OA> <listitem> OA> The packet gets <command>DNAT</command>'ed, and all other required OA> actions are taken, however, the packet is not <command>SNAT</command>'ed, OA> so the same source IP address is used on the packet. OA> </listitem> OA> <listitem> OA> The packet leaves the firewall and reaches the OA> <systemitem>HTTP</systemitem> server. OA> </listitem> OA> <listitem> OA> The <systemitem>HTTP</systemitem> server tries to respond to the OA> packet, and sees in the routing databases that the packet came from a OA> local box on the same network, and hence tries to send the packet directly OA> to the original <systemitem>source IP address</systemitem> (which now OA> becomes the <systemitem>destination IP address</systemitem>). OA> </listitem> OA> <listitem> OA> The packet reaches the client, and the client gets confused since the OA> return packet does not come from the host that it sent the original OA> request to. Hence, the client drops the reply packet, and waits for the OA> "real" reply. OA> </listitem> OA> </orderedlist> OA> <para> The simple solution to this problem is to OA> <command>SNAT</command> all packets entering the firewall and leaving for OA> a host or IP that we know we do <command>DNAT</command> to. For example, OA> consider the above rule. We <systemitem>SNAT</systemitem> the packets OA> entering our firewall that are destined for <command>$HTTP_IP</command> OA> port 80 so that they look as if they came from <command>$LAN_IP</command>. OA> This will force the <systemitem>HTTP</systemitem> server to send the OA> packets back to our firewall, which Un-<command>DNAT</command>'s the OA> packets and sends them on to the client. The rule would look something OA> like this: OA> </para> OA> <literallayout> OA> <command> OA> iptables -t nat -A POSTROUTING --dst $HTTP_IP --dport 80 -j SNAT --to-source $LAN_IP OA> </command> OA> </literallayout> OA> <para> Remember that the <systemitem>POSTROUTING</systemitem> chain is OA> processed last of the chains, and hence the packet will already be OA> <command>DNAT</command>'ed once it reaches that specific chain. This is OA> the reason that we match the packets based on the internal address. OA> </para> OA> <para> You think this should be enough by now, and it really is, OA> unless considering one final aspect to this whole scenario. What if the OA> firewall itself tries to access the <systemitem>HTTP</systemitem> server, OA> where will it go? As it looks now, it will unfortunately try to get to its OA> own <systemitem>HTTP</systemitem> server, and not the server residing on OA> <command>$HTTP_IP</command>. To get around this, we need to add a OA> <command>DNAT</command> rule in the <systemitem>OUTPUT</systemitem> chain OA> as well. Following the above example, this should look something like the OA> following: OA> </para> OA> <literallayout> OA> <command> OA> iptables -t nat -A OUTPUT --dst $INET_IP --dport 80 -j DNAT --to-destination $HTTP_IP OA> </command> OA> </literallayout> OA> <para> Adding this final rule should get everything up and running. OA> All separate networks that do not sit on the same net as the OA> <systemitem>HTTP</systemitem> server will run smoothly, all hosts on the OA> same network as the <systemitem>HTTP</systemitem> server will be able to OA> connect and finally, the firewall will be able to do proper connections as OA> well. Now everything works and no problems should arise. OA> </para> OA> Have a nice day, OA> Oskar Andreasson OA> http://www.boingworld.com OA> http://people.unix-fu.org/andreasson/ OA> mailto: [EMAIL PROTECTED] OA> ----- Original Message ----- OA> From: "Kenneth" <[EMAIL PROTECTED]> OA> To: <[EMAIL PROTECTED]> OA> Sent: Wednesday, May 15, 2002 9:06 AM OA> Subject: Newbie question >> Hi all, >> >> I'm new to the list and have a question here: >> >> eth0 has a public IP address >> eth1 has a private IP address >> >> Attached is my iptable script. This script enables internal machines >> communicate with public website and email. But it cannot give access >> to website in internal web server(192.168.1.200:80). >> >> /sbin/iptables -t nat -A PREROUTING -p tcp -i $INET_IFACE -d $INET_IP --dport 80 >-j DNAT --to 192.168.1.200:80 >> /sbin/iptables -A FORWARD -m state --state NEW -p tcp -i $INET_IFACE -d >192.168.1.200 --dport 80 -j ACCEPT >> >> Any help/idea is appreciated. >> >> -- >> Best regards, >> Kenneth mailto:[EMAIL PROTECTED]
