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