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