Hi Readers, thanks you Oskar, so in simple words you are saying that IPTables can't do what I have in mind to accive with it. I'm really sorry about that but at least I know now that I need to rethink my server configuration ;). Many thanks Oskar for your kind help ;) Best regards, Auro B. 2011/6/22 Oskar Berggren <oskar.berggren@xxxxxxxxx>: > No packet will ever traverse more than one of INPUT, FORWARD and > OUTPUT. If you DNAT in PREROUTING to divert the traffic to an internal > server, it will pass through FORWARD, but not INPUT. Input is for > traffic that terminates at the same host. > > Your log shows the packet in FORWARD, with the modified destination as > per you DNAT. > > /Oskar > > > 2011/6/21 Auro Benas <ebay.omg@xxxxxxxxx>: >> Hi Readers, >> as first thank you Oskar for your fast reply. >> >> Maybe I wrote too much stuff on previouse message. >> >> As first I'll reply to questions you asked me. >> >>> Are you saying that xx1, xx2, etc. resolve to different IP that are >>> all present on interfaces of the FW itself? >>> Or are you saying that incoming connections that originate from the IP >>> corresponding to xx1 should reach one server, originating from xx2 >>> another server, etc.? >> >> The second one, each third level domain is correlated to a single and >> specific server inside the DMZ zone behind the FW, as example: >> xx1.domain.com ---> IPGServer 10.10.0.1 >> xx2.domain.com ---> IPGServer 10.10.0.2 >> xx1.domain.com ---> IPGServer 10.10.0.3 >> ---- >> x30.domain.com ---> 10.10.0.30 >> >> >> >>> If your FW public IP is 1.2.3.4, directing traffic to an internal >>> server is simply: >>> -t nat -A PREROUTING -j DNAT --to 10.10.0.1 >> >> Yep that is what I have accived right now. >> I need AT LEAST 2 layers of security before going on-line and that >> will be accived with the IPGServer AKA FW with IPTables ONLY installed >> as >> first layer od defence/restriction, after that all the WEB Servers >> behind the main FW will have IPTAbles installed to onborad with >> EXTREMLY >> restrictive rules even more than FW, that will be my second layer of >> defence/restrictions. >> The first point in all that is that I need as first to filter and LOG >> all what comes in from the Internet with FW and to DROP all the IPs >> that will dinamically be inserted in the black list rule in filter >> table in INPUT chain. >> The second point in all this is that WEB Servers behind FW will have >> their job to do with Apache/MySQL/PHP installed on board and I >> can't waste servers' performances for something that must be done by >> the FW that is there simply to execute that kind of work. >> >>> This handles connection, i.e. traffic in both directions. You do not >>> need a separate SNAT rule to handle response traffic for such >>> connections. For incoming traffic, the FILTER part and the web server >>> will see the original source IP. As long as the servers default >>> gateway point to your FW, return traffic will be handled properly >>> without hiding/translating the true source address. >>> >>> SNAT rules will be needed to make connections initiated from your >>> servers, (such as apt-get update), work. >> >> Well that is something that I haven't know before, I'm a rookie, thanks ;) >> >> >>> PREROUTING does not make traffic skip the FILTER chains. Note that you >>> also have the raw table to filter before connection tracking and nat >>> occurs. >> I'm sorry but I think that I don't understand that point. >> From what I see from my logs and what have I tried I see that the >> filter table and >> INPUT chanin restrictions even if setted aren't taken in consideration. >> I copy/paste you here my logs: >> ================================================= >> Jun 21 20:20:54 ggout001 GG-PREROUTING IN=eth0 OUT= >> MAC=00:0f:1f:f9:33:aa:00:09:41:42:b8:46:08:00 SRC=192.168.1.106 >> DST=192.168.1.90 LEN=64 TOS=00 PREC=0x00 TTL=128 ID=9509 DF PROTO=TCP >> SPT=3285 DPT=80 SEQ=2153389899 ACK=0 WINDOW=65535 SYN URGP=0 >> Jun 21 20:20:54 ggout001 GG-FORWARD IN=eth0 OUT=eth1 >> MAC=00:0f:1f:f9:33:aa:00:09:41:42:b8:46:08:00 SRC=192.168.1.106 >> DST=10.10.0.1 LEN=64 TOS=00 PREC=0x00 TTL=127 ID=9509 DF PROTO=TCP >> SPT=3285 DPT=80 SEQ=2153389899 ACK=0 WINDOW=65535 SYN URGP=0 >> Jun 21 20:20:54 ggout001 GG-POSTROUTIN IN= OUT=eth1 MAC= >> SRC=192.168.1.106 DST=10.10.0.1 LEN=64 TOS=00 PREC=0x00 TTL=127 >> ID=9509 DF PROTO=TCP SPT=3285 DPT=80 SEQ=2153389899 ACK=0 WINDOW=65535 >> SYN URGP=0 >> ================================================= >> >> >> I'll olso copy/pase my actual IPTables rules just to make easiear your >> eventual help ;) >> NOTE: >> I leaved the test rule that will DROP any connection entering in eth0, >> that was happend for >> my SSH connection, or SFTP connection that arent prerouted while the >> HTTP connections passes as no rule is setted on filter. >> ================================================= >> # Generated by iptables-save v1.4.4 on Tue Jun 21 20:37:57 2011 >> *filter >> :INPUT ACCEPT [300:34601] >> :FORWARD ACCEPT [5:320] >> :OUTPUT ACCEPT [3346:16521465] >> -A INPUT -j ULOG --ulog-prefix "GG-INPUT" >> -A INPUT -i eth0 -p tcp -j DROP >> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT >> -A FORWARD -j ULOG --ulog-prefix "GG-FORWARD" >> -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT >> -A FORWARD -i eth1 -o eth0 -j ACCEPT >> -A OUTPUT -j ULOG --ulog-prefix "GG-OUTPUT" >> COMMIT >> # Completed on Tue Jun 21 20:37:57 2011 >> # Generated by iptables-save v1.4.4 on Tue Jun 21 20:37:57 2011 >> *nat >> :PREROUTING ACCEPT [148:18297] >> :POSTROUTING ACCEPT [1:64] >> :OUTPUT ACCEPT [3:216] >> -A PREROUTING -j ULOG --ulog-prefix "GG-PREROUTING" >> -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT >> --to-destination 10.10.0.1 >> -A POSTROUTING -j ULOG --ulog-prefix "GG-POSTROUTIN" >> -A POSTROUTING -o eth0 -j MASQUERADE >> COMMIT >> # Completed on Tue Jun 21 20:37:57 2011 >> ================================================= >> >> NOTE: >> That's a working DMZ zone, but I need something more from this >> configuration and from the server that will host that configuration. >> Filter as first >> after filtering routing to the destinaion web server, that's all. >> >> I hope that you will understand what I need and you will point me in >> the right direction. >> >> Thank you in advanced for your kind help ;). >> >> Best regards, >> Auro B. >> >> >> >> >> 2011/6/21 Oskar Berggren <oskar.berggren@xxxxxxxxx>: >>> Are you saying that xx1, xx2, etc. resolve to different IP that are >>> all present on interfaces of the FW itself? >>> Or are you saying that incoming connections that originate from the IP >>> corresponding to xx1 should reach one server, originating from xx2 >>> another server, etc.? >>> >>> If your FW public IP is 1.2.3.4, directing traffic to an internal >>> server is simply: >>> -t nat -A PREROUTING -j DNAT --to 10.10.0.1 >>> >>> This handles connection, i.e. traffic in both directions. You do not >>> need a separate SNAT rule to handle response traffic for such >>> connections. For incoming traffic, the FILTER part and the web server >>> will see the original source IP. As long as the servers default >>> gateway point to your FW, return traffic will be handled properly >>> without hiding/translating the true source address. >>> >>> SNAT rules will be needed to make connections initiated from your >>> servers, (such as apt-get update), work. >>> >>> >>> PREROUTING does not make traffic skip the FILTER chains. Note that you >>> also have the raw table to filter before connection tracking and nat >>> occurs. >>> >>> /Oskar >> > -- 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
