Hmm, I had that line in there but not sure why it didn't show up. Ok, so here is the configuration items again. Hopefully, not mangled. Not sure if the list allows it but I've attempted to also attach the config file. Firewall (10.0.10.22 (eth0) on the inside, 10.1.10.1 (eth1) on the DMZ) *nat :PREROUTING ACCEPT [0:0] -A PREROUTING -i eth0 -d 10.0.10.22 -p tcp --dport 80 -j DNAT --to 10.1.10.7 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 -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A FORWARD -s 10.1.10.7 -p tcp --sport 80 -j ACCEPT -A FORWARD -d 10.1.10.7 -p tcp --sport 80 -j ACCEPT COMMIT Webserver (10.1.10.7 (eth1 - no other interfaces active) on the DMZ with its' gateway set to 10.1.10.1 - no DNS specified) *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 -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT COMMIT Client 10.0.10.85 trying to connect to http://10.0.10.22 merely gets a timeout. -----Original Message----- From: Pandu Poluan [mailto:pandu@xxxxxxxxxxx] Sent: February-23-11 1:18 AM To: Feasey, Nicholas; netfilter@xxxxxxxxxxxxxxx Subject: Re: DMZ issue - redirect works as expected but behaviour not desired Okay, the Gmail mobile client mangles your email, so I can't fully analyze your configuration. But one rule stood out: -A FORWARD -s 10.1.10.7 -p tcp --sport 80 -j ACCEPT That rule *only* allows replies from the webserver. You need another rule for packets to reach the webserver: -A FORWARD -d 10.1.10.7 -p tcp --dport 80 -j ACCEPT And if your webserver serves HTTPS, another pair of rules for port 443. Rgds, On 2011-02-23, Feasey, Nicholas <nfeasey@xxxxxxxxxxxxxxxxxxx> wrote: > My battle with iptables continuesâ > > It's probably staring me in the face however here is the run down... > > In order to perform my testing I started with the inside network > (10.0.10.0). > I have set up the server on it's own DMZ (10.1.10.0 subnet). > > The firewall is on the internal network as 10.0.10.22 and the DMZ as > 10.1.10.1. (It's ok that he firewall is on the same subnet - correct > or do ALL ports on the fiewall have to be on different subnets?). > > The webserver has one interface up and running, it's IP is set to > 10.1.10.7 and it's gateway set to 10.1.10.1. No DNS defined at all. > > The particulars: > > client ip: 10.0.10.85 > firewall ip: 10.0.10.22 (eth0) 10.1.10.1 (eth1) webserver ip: > 10.1.10.7 (eth1) > > Going to: http://10.0.10.22 (should see Welcome simple welcome page) > > No luck - just sits there. > > Below is the iptables for the firewall box: > > Firewall iptables > : > # Firewall configuration written by system-config-firewall # Manual > customization of this file is not recommended. > *nat > :PREROUTING ACCEPT [0:0] > #:POSTROUTING ACCEPT [0:0] > -A PREROUTING -i eth0 -d 10.0.10.22 -p tcp --dport 80 -j DNAT --to > 10.1.10.7 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 -m > state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A INPUT -m state > --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A INPUT -m state > --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A INPUT -j REJECT > --reject-with icmp-host-prohibited -A FORWARD -s 10.1.10.7 -p tcp > --sport 80 -j ACCEPT -A FORWARD -j REJECT --reject-with > icmp-host-prohibited COMMIT > > iptables -L -t nat on firewall: > > target prot opt source destination > DNAT tcp -- anywhere zeus-n.utpress.utoronto.ca tcp > dpt:http to:10.1.10.7 > > Chain POSTROUTING (policy ACCEPT) > target prot opt source destination > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > > iptables -L -t filter on firewall: > > Chain INPUT (policy ACCEPT) > target prot opt source destination > ACCEPT all -- anywhere anywhere state > RELATED,ESTABLISHED > ACCEPT icmp -- anywhere anywhere > ACCEPT all -- anywhere anywhere > ACCEPT tcp -- anywhere anywhere state NEW tcp > dpt:ssh > ACCEPT tcp -- anywhere anywhere state NEW tcp > dpt:http > ACCEPT tcp -- anywhere anywhere state NEW tcp > dpt:https > REJECT all -- anywhere anywhere reject-with > icmp-host-prohibited > > Chain FORWARD (policy ACCEPT) > target prot opt source destination > ACCEPT tcp -- 10.1.10.7 anywhere tcp spt:http > REJECT all -- anywhere anywhere reject-with > icmp-host-prohibited > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > > > Webserver iptables: > > # Firewall configuration written by system-config-firewall # Manual > customization of this file is not recommended. > *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 -m state --state NEW > -m tcp -p tcp --dport 22 -j ACCEPT -A INPUT -m state --state NEW -m > tcp -p tcp --dport 80 -j ACCEPT -A INPUT -m state --state NEW -m tcp > -p tcp --dport 443 -j ACCEPT -A INPUT -j REJECT --reject-with > icmp-host-prohibited -A FORWARD -j REJECT --reject-with > icmp-host-prohibited COMMIT > > Webserver iptables -L -t filter > > Chain INPUT (policy ACCEPT) > target prot opt source destination > ACCEPT all -- anywhere anywhere state > RELATED,ESTABLISHED > ACCEPT icmp -- anywhere anywhere > ACCEPT all -- anywhere anywhere > ACCEPT tcp -- anywhere anywhere state NEW tcp > dpt:ssh > ACCEPT tcp -- anywhere anywhere state NEW tcp > dpt:http > ACCEPT tcp -- anywhere anywhere state NEW tcp > dpt:https > REJECT all -- anywhere anywhere reject-with > icmp-host-prohibited > > Chain FORWARD (policy ACCEPT) > target prot opt source destination > REJECT all -- anywhere anywhere reject-with > icmp-host-prohibited > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > > I just don't see what is wrong here so I'm sure it's something silly. > > Nicholas > > On 2011-02-20, at 9:37 AM, Pandu Poluan wrote: > >> 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/ >> >> > > -- -- Pandu E Poluan - IT Optimizer My website: http://pandu.poluan.info/
Firewall (10.0.10.22 (eth0) on the inside, 10.1.10.1 (eth1) on the DMZ) *nat :PREROUTING ACCEPT [0:0] -A PREROUTING -i eth0 -d 10.0.10.22 -p tcp --dport 80 -j DNAT --to 10.1.10.7 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 -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A FORWARD -s 10.1.10.7 -p tcp --sport 80 -j ACCEPT -A FORWARD -d 10.1.10.7 -p tcp --sport 80 -j ACCEPT COMMIT Webserver (10.1.10.7 (eth1 - no other interfaces active) on the DMZ with its' gateway set to 10.1.10.1 - no DNS specified) *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 -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT COMMIT Client 10.0.10.85 trying to connect to http://10.0.10.22 merely gets a timeout.
