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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
