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/ -- 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
