Hi John, first of all thx for your reply. Well, there's nothing wrong with my rules. Except your remarks on stateful inspection. I do need the seperate NAT rule for outbound traffic otherwise it would be natted to eth0 which then would cause errors on senders firewall (packets are sent to "eth1" (DMZ) address but response will come through "eth0" (FW) address). As expected that's all a "nice hidden security feature" of IIS ;-) No, just kidding. IIS is set up to look for "index.asp" pages if a directory is requested, e.g. "http://our.host:50003/directory". It works for requests on port 80 but not for requests on any other port. Having a detailed look at the packets I saw that suddenly requests are "mangled" to port 80. And these requests are not allowed. So if we put "http://our.host:50003/directory/index.asp" it works as expected. Don't ask me why, I don't mind. I search support.microsoft.com but found nothing mentioned concerning this treatment. I know why I like Apache so much, but that's off topic :-) Have fun, Oliver
-----Ursprüngliche Nachricht----- Von: John Trickey [mailto:lists@g4rev.supanet.com] Gesendet: Dienstag, 4. März 2003 12:59 An: suse-security@suse.com Betreff: Re: [suse-security] Port forwarding problem
Hi Oliver,
I have a firewall problem I have resigned on. I hope there's someone out there who can help me and explain what's wrong.
I do not see much wrong with this.
iptables -A PREROUTING -t nat -p tcp -s 0.0.0.0/0 -d IP_DMZHOST --dport PORTFW -j DNAT --to-destination IP_LAN:80
I have used almost identical rules. I do not bother with -s "any" as its assumed if omitted and I use --to just because its shorter :-). So functionally, there is no difference.
There are 2 areas that may be causing you grief.
1) Have you set up the forward table? You will need iptables -A FORWARD -i eth0 -o eth2 -p tcp -d IP_LAN --dport 80 -j ACCEPT and also its inverse.
Personally I prefer connection tracking so you can do iptables -A FORWARD -i eth0 -o eth2 -p tcp -d IP_LAN --dport 80 \ -m state --state NEW -j ACCEPT with a global iptables -A FORWARD -i eth2 -o eth0 -m state --state ESTABLISHED -j ACCEPT for the return.
2) Have you prevented the return packets from being masqueraded? If not they will be leaving your firewall with a source IP of IP_eth0. You need something like: iptables -t nat -A POSTROUTING -o eth0 -s IP_DMZ -j ACCEPT iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
"firewalled" or "proxied" connections. Therefore I put the following rule in place which should SNAT the specific traffic coming from IIS.
iptables -I POSTROUTING -t nat -s IP_LAN -d ! 10.0.0.0/8 -j SNAT --to-source IP_DMZHOST
I need "-d ! 10.0.0.0/8" option because of our IPSec VPN. But after applying this rule nothing works.
I'm not surprised. By adding this rule you would be creating a separate NAT entry for the outbound traffic.
In my opinion there must be a general "design" mistake I have made. But I don't know which
I think its only an omission. If you're still stuck, come back to me on the list. Don't use direct mail as this address is a spam trap which throws non list mail straight into /dev/null.
John
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here