Your welcome :) After the NAT is successful, don't forget to harden your iptables. And while doing that, don't forget to ACCEPT packets that need to be forwarded, e.g.: -t filter -A FORWARD -s $WEBSERVER -p tcp --sport 80 -j ACCEPT Good luck! Rgds, On 2011-02-20, Feasey, Nicholas <nfeasey@xxxxxxxxxxxxxxxxxxx> wrote: > As I suspected I was doing myself in thinking that I could touch such a > thing on just one interface. I have two interfaces and will now do it the > correct way. > > Thank you very much for your making it very clear for me and for your > assistance! > > Nicholas > On 2011-02-20, at 12:24 AM, Pandu Poluan wrote: > >> That won't work if the firewall, the webserver, and the client are all >> in the same subnet. >> >> Let's assume: >> * Client is 192.168.40.22 >> * Firewall is 192.168.40.10 >> * Webserver is 192.168.40.15 >> >> Now client tries to access the faux-webserver: >> >> From: 192.168.40.22 >> To: 192.168.40.10 >> >> The packet gets DNATed >> >> From: 192.168.40.22 >> To: 192.168.40.15 >> >> See what happened? Because the source is the same subnet, the >> webserver replies directly to the client. >> >> From: 192.168.40.15 >> To: 192.168.40.22 >> >> The Linux firewall never sees the returning packet. And the client >> sees a 'strange' packet, as the client's opened connection is with .10 >> not .15. This results in the client dropping the 'strange' packet. >> >> Now, the usual scenario is like this: >> >> Firewall Box has 2 interfaces: >> * WAN: 202.72.112.5 (default gateway to ISP's router) >> * DMZ: 192.168.40.1 >> >> Webserver: 192.168.40.8 (default gateway is 192.168.40.1) >> >> Assume client is: 65.12.212.47 >> >> Client opens a connection to the firewall: >> >> [1] From: 65.12.212.47 >> To: 202.72.112.5 >> >> Firewall does a DNAT: >> >> From: 65.12.212.47 >> To: 192.168.40.8 >> >> Webserver handles the request, and replies: >> >> From: 192.168.40.8 >> To: 65.12.212.47 >> >> Since the destination is on a different subnet, the webserver hands >> the packet to the firewall, which performs an 'un-DNAT': >> >> From: 202.72.112.5 >> To: 65.12.212.47 >> >> The packet gets sent via the intertubes to the client, and the client >> sees that the packet *is* a reply to its connection (see [1]; the >> from: and to: addresses are properly swapped). >> >> So, if you want to test, you'll need to configure your network so that: >> * 2 interfaces on the Linux box >> * the client and the webserver are *not* on the same subnet >> >> Rgds, >> >> >> On 2011-02-20, Feasey, Nicholas <nfeasey@xxxxxxxxxxxxxxxxxxx> wrote: >>> On 2011-02-19, at 8:28 PM, Pandu Poluan wrote: >>> >>>> (sorry for top posting; Gmail mobile client can only top-post) >>>> >>>> I've been doing what (I think) you're planning to do, i.e., mapping an >>>> external IP:port into DMZ (which uses private addressing) >>>> >>>> IMO, to do this, you really don't need more than 2 rules: >>>> -t nat -A PREROUTING -i $WAN_IFACE -d $WAN_IP -p tcp --dport 80 -j >>>> DNAT --to $WEBSERVER >>>> >>>> -A FORWARD -d $WEBSERVER -j ACCEPT >>>> >>>> With the above pair of rules, only the destination of incoming packets >>>> get changed; the webserver would still see the original source >>>> address. As long as the Linux firewall sees *both* incoming and >>>> outgoing traffic from the webserver, netfilter will automatically >>>> perform the inverse NAT. >>>> >>>> Of course you would want some -t raw -A PREROUTING rules to prevent >>>> spoofing (esp. smurf attacks). But that's not strictly necessary for >>>> NAT-ing. >>>> >>>> CMIIW. >>>> >>>> Rgds, >>>> >>>> >>>> On 2011-02-20, Feasey, Nicholas <nfeasey@xxxxxxxxxxxxxxxxxxx> wrote: >>>>> Thank you for your response and explanation of the difference between >>>>> MASQUERADE and SNAT. >>>>> >>>>> I really do not want to use MASQUERADE for exactly the reason that you >>>>> state. >>>>> >>>>> My explanation is confusing because I was using the same ethernet port >>>>> just >>>>> for testing. >>>>> >>>>> In the real world I'm trying to achieve a box that acts as a firewall >>>>> and >>>>> depending on the service requested routes to an internal machine lying >>>>> on >>>>> a >>>>> DMZ. >>>>> >>>>> So, I'd be using multiple ethernet ports as you would expect. >>>>> >>>>> To be clear (I hope) users would enter http://somesite.somewhere.com >>>>> and >>>>> it >>>>> would resolve to an IP address on the firewall box. >>>>> They hit the outside interface (port 80 or 443) and it would forward >>>>> this >>>>> to >>>>> a machine on the DMZ. That's all I'm trying to achieve here. >>>>> >>>>> Is this just achieved via a series of FORWARD commands like any other? >>>>> >>>>> >>>>> On 2011-02-19, at 6:10 PM, Pascal Hambourg wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> Feasey, Nicholas a Ãcrit : >>>>>>> I'm setting up a box that will be the only device on the Internet and >>>>>>> will forward requested services to other servers sitting on a DMZ. >>>>>>> >>>>>>> As a test I started with redirecting a web server. >>>>>>> >>>>>>> To test my arrangement I first merely set up a simple masquerade >>>>>>> (just >>>>>>> on my internal network) in my iptables like so: >>>>>>> >>>>>>> *nat >>>>>>> :PREROUTING ACCEPT [0:0] >>>>>>> :POSTROUTING ACCEPT [0:0] >>>>>>> -A PREROUTING -p tcp -i eth0 --dport 80 -j DNAT --to 192.168.40.15 >>>>>>> -A POSTROUTING -j MASQUERADE >>>>>> >>>>>> Be aware that using MASQUERADE on all interfaces may not do what you >>>>>> want. Usually, it is used only on the public internet side. >>>>>> >>>>>>> *filter >>>>>>> ...normal filtering lines follow. >>>>>>> >>>>>>> This POSTROUTING entry works as well: >>>>>>> >>>>>>> -A POSTROUTING -o eth0 -j SNAT --to-source 192.168.40.15 >>>>>>> >>>>>>> I think this is because the above line is doing the same as the >>>>>>> shortcut >>>>>>> MASQUERADE. >>>>>> >>>>>> Not exactly. This rule replaces the source address of any connection >>>>>> going out eth0 with 192.168.40.15 whereas the above MASQUERADE rule >>>>>> replaces the source address of any connection going out any interface >>>>>> with the address of the interface. >>>>>> >>>>>> By the way, it is weird that you use the address of a remote host (the >>>>>> server in the DMZ). >>>>>> >>>>>>> When I check the httpd access_log it shows that the connection came >>>>>>> from >>>>>>> 192.168.40.15 as expected. It works. >>>>>> >>>>>> I'm puzzled. A connection cannot match both the DNAT and SNAT rules as >>>>>> they have the same input and output interface eth0. Even if it did >>>>>> (the >>>>>> connection goes out the interface it came in), this connection would >>>>>> end >>>>>> up having the same address as source and destination 192.168.40.15. >>>>>> -- >>>>>> To unsubscribe from this list: send the line "unsubscribe netfilter" >>>>>> in >>>>>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>>>> >>> >>> Thank you for your reply. >>> >>> I just know that it's my inexperience that's getting me all messed up >>> here. >>> I've tried your advise but it's just not happening for me. >>> Thought I'd post my test iptables configuration in the hopes that my >>> issue >>> can be identified. I've made the configuration basic so that nothing >>> else >>> get's in my way. >>> >>> Here goes... >>> >>> So, assuming >>> $WAN_IFACE = eth0 >>> $WAN_IP = 192.168.40.10 >>> $WEBSERVER = 192.168.40.15 >>> >>> Based on your recommendation of... >>> >>>> -t nat -A PREROUTING -i $WAN_IFACE -d $WAN_IP -p tcp --dport 80 -j >>>> DNAT --to $WEBSERVER >>>> >>>> -A FORWARD -d $WEBSERVER -j ACCEPT >>> >>> *nat >>> :PREROUTING ACCEPT [0:0] >>> -A PREROUTING -i eth0 -d 192.168.40.10 -p tcp --dport 80 -j DNAT --to >>> 192.168.40.15 >>> COMMIT >>> *filter >>> :INPUT ACCEPT [0:0] >>> :FORWARD ACCEPT [0:0] >>> :OUTPUT ACCEPT [0:0] >>> -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT >>> -A INPUT -p icmp -j ACCEPT >>> -A INPUT -i lo -j ACCEPT >>> -A INPUT -i eth0 -j ACCEPT >>> -A FORWARD -d 192.168.40.15 -j ACCEPT >>> COMMIT >>> >>> I know they are on the same interface but again I assume this should work >>> for testing purposes even though this would never be done in a real >>> environment. >>> I've assumed that the -A FORWARD goes in the *filter table and not the >>> *nat >>> table? Second assumption is that I don't need any rules per say in the >>> $WEBSERVER >>> iptables file as you explained. >>> >>> I beg your indulgence with my inexperience while I try to wrap my head >>> around this and I might have taken out too many lines (or two few) to get >>> this to go. >>> >>> Bottom line is that with this in place I never get to the $WEBSERVER like >>> I"ve done with just my simple MASQUERADE test. >>> >>> I'm obviously missing something here and I can't begin to tell you my >>> frustration in my ability to get what I believe should be relatively >>> simple >>> to work. :) >>> >>> Nicholas >>> >>> >>> >>> >> >> >> -- >> -- >> Pandu E Poluan - IT Optimizer >> My website: http://pandu.poluan.info/ >> >> > > -- -- Pandu E Poluan - IT Optimizer My website: http://pandu.poluan.info/ -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
