Yes; it is the case.

Yes packets will have their internal ip in them as a destination ip(coz of PREROUTING rule); while going in towards webserver & source ip of lan-webserver while returning back. But this will be limited till the $INTDEV(lan environment). And further then; our $INTDEV will be replaced by $EXTDEV as the packet leaves from EXT INTERFACE.(without any POST-ROUTING rule)
(you can cross-check this example also. I've done it on numerous times.)

REASON: AFAIK; With NATing we never have to worry for the return path of any packet (which took part in NATing) until we have a firewall/gateway ahead of them. POSTROUTING rule comes into a need when we donot have our FIREWALL as the GATEWAY for our WEBSERVER. As in this case we got to convert the initial packet of : SOURCE/DESTINATION = INTERNET-CLIENT/$EXTDEV to $INTDEV/$WEBSERVER & hence a postrouting is also needed.

@ win32sux:

POSTROUTING is not a necessity for doing a purposefull SNAT; but it is requisted in a case when a packet is never able to reach back at a firewall on its own.

1st case :
WEBSERVER with firewall as gateway

Initial packet: (Rxd @ External interface)
client/$EXTDEV

Desired packet:
client/$WEBSERVER

On return; source ip(lan-based) will automatically be replaced by $EXTDEV ip.

2nd case :
WEBSERVER without firewall as its gateway/some other gateway/ No gateway

Initial packet:
client/$EXTDEV

Desired packet:
$INTDEV/$WEBSERVER

As you can see we are maintaining same classes at both of the state of packets; We got to do PREROUTING & POSTROUTING for this; as we do not have firewall acting as its gateway in this case. And hence with postrouting we are not creating any return path for any packet; we never ever do that.

In the case; when a FIREWALL is acting as a gateway;
WE never got clarified on this query because of the reason that whenever any POSTROUTING rule is added to a PREROUTING rule; IT will always work (though it is not a necessity) & that is the reason we never found any mistake to this as well.

You can get more at : http://amitsharma.linuxbloggers.com/portforwarding.htm

Hi Mr win32sux,

thanks for your help. In answering your query "BTW, i assumed these rules were running on a firewall/gateway in front of a web server on a LAN... let me know if that is not the case..."

Yes, you are right, the rules are running on a firewall in front of the webserver on a LAN.
thanks.

Thanks Mr amitsharma_26 for your help.

Connection attempts originating inside the LAN that are not DNATed. For example an internal webserver attempting to grab updates using YUM. You are correct that replies from the internal webserver (that belong to a DNATed connection) are automagically un-DNATed by the NAT-box.

Yes, that is true. We got to use DNAT for that purpose.
But i think we were talking about the case of the query placed by the thread owner only, i.e. internet clients are unable to browse a webserver hosted on a LAN with port forwarding.(on the lighter side)

@niceman : Are things working now @ your setup ?
And you got to decide at what are the purposes this webserver(with $EXTDEV-IP) it got to serve. Will there be any backup purposes to unfold/ Will there be LAN users be accesing through to same IP as well ?
You got to decide & judge them by yourself ; so that you can further finally create the iptable rules or can ask us for any guidance regarding the same.

Dear friends,

I am really thankful for all your help.
Yes, actually my problem now is that I couldnt allow external clients to access the internal webserver...

I am still trying to work out what went wrong...i have followed what was stated on http://amitsharma.linuxbloggers.com/portforwarding.htm

It looked so easy from there but i couldnt get it work...

Anyway, Thanks a lot to all of you Mr Captain Caveman, Amitsharma and win32sux!!

Could you post the full contents of the updated script, so that we know what you are working with. Make sure that the output of iptables -vnL and iptables -t nat -vnL corresponds with your script (if you aren't flushing the rules they could be piled on top of each other).

Also how are you verifying that the webserver is accessible from outside the LAN? Are you simply using a LAN client to access the external IP address of the firewall (66.88.77.55)? If so, you are likely experiencing the local DNAT problem.

Also verify that for each port that you forward using DNAT, there is a corresponding rule in the FORWARD chain (one of your earlier script versions DNATed 8080 but had a forwarding rule for port 80).

EDIT : Corrected the url.


Niceman,
You can pick any proxy ip from publicproxyservers.com & use it in your browser to access your webserver($EXTDEV-IP), We are just imitating the real environment with this.

Can you post your complete(updated) script & the details caveman has asked you to do ? Please.

Dear friends,

Great. I have got it working finally. But sadly i don't evne know where was the part that was wrong. I am wondering, when i write a rule in the script , say eg:

$IPT -A FORWARD -p tcp -i $EXTDEV -o $INTDEV -d xxx.xxx.xxx.xx -s yyy.yyy.yyy.yy --dport 80 -m state --state NEW -j ACCEPT

The above rule has so many arguments tcp, $EXTDEV, $INTDEV, xxx.xxx.xxx.xx, yyy.yyy.yyy.yy, 80, NEW
, if i have so many of these arguments in one rule, will it affect it from working?
I think i corrected the rule to put less argument somehoe made it work....


Anyway, Captain, we have two internet lines here, so i switch to the other internet IP to do testing.

thanks a million for all the help from all of you!

no... unless one of the matches you added doesn't, ummm, match the packet... this rule you've posted looks pretty straight-forward (no pun intended) so i don't see why you would go wrong... just make sure you are 100% sure about the "-s" (source IP) match...

The only issue with having many matches in a single iptables rule (aside from win32sux point) is that a few of the options require things to be in a specific order to work properly.

I'd recommend that you post all of your rules to make sure that you somehow didn't compromise the firewall integrity by "shortening" one of the rules. Doing iptables -I FORWARD -j ACCEPT will often fix alot of problems, but it also will completely open up your network to an attacker.

Dear all,


hmm...I think that is possibly the problem...

heres the full script that is finally working.


IPT=/sbin/iptables

EXTDEV=ppp0
#For static IP
#EXTIP=""
# For dailup streamyx account
EXTIP=`ifconfig ppp0 | grep "P-t-P" | cut -c 0-36 | sed -e s/[a-zA-Z:-]//g`
LOGOPT="--log-level=3 -m limit --limit 3/minute --limit-burst 3"

INTDEV=eth0
INTIP="192.168.0.1"
webserver IP = 192.168.0.100


#------------------------------------------------------------
#Clean the table rules
#------------------------------------------------------------
for table in mangle filter nat
do
$IPT -t $table -F
$IPT -t $table -X
$IPT -t $table -Z
done

$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP
$IPT -F
$IPT -X

#-------------------------------------------------------------
#Source NAT for external IP
#-------------------------------------------------------------
$IPT -t nat -A PREROUTING -p tcp -i $EXTDEV -d $EXTIP --dport 80 -j DNAT --to 192.168.0.100
$IPT -t nat -A POSTROUTING -p tcp -d 192.168.0.100 --dport 80 -j SNAT --to-source $INTIP

#------------------------------------------------------------
#For traffic (heading to) flow into firewall
#------------------------------------------------------------
$IPT -A INPUT -i lo -j ACCEPT # localhost
$IPT -A INPUT -p udp --dport 5060 -j ACCEPT
$IPT -A INPUT -p udp --dport 10001:65535 -j ACCEPT
$IPT -A INPUT -p udp --dport 53 -j ACCEPT # DNS
$IPT -A INPUT -p tcp --dport 389 -j ACCEPT
$IPT -A INPUT -p tcp --dport 80 -j ACCEPT
$IPT -A INPUT -p tcp --dport 22 -j ACCEPT # ssh
$IPT -A INPUT -p icmp -i $INTDEV -j ACCEPT # ping
$IPT -A INPUT -p tcp --dport 5900 -j ACCEPT
$IPT -A INPUT -p tcp --dport 5901 -j ACCEPT
$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -j DROP

#------------------------------------------------------------
#For traffic (leaving from) flow out from firewall
#------------------------------------------------------------
$IPT -A OUTPUT -o lo -j ACCEPT # localhost
$IPT -A OUTPUT -p udp --dport 5060 -j ACCEPT
$IPT -A OUTPUT -p udp --dport 10000:65535 -j ACCEPT
$IPT -A OUTPUT -p tcp --dport 389 -j ACCEPT
$IPT -A OUTPUT -p udp --dport 53 -j ACCEPT # DNS
$IPT -A OUTPUT -p tcp --dport 22 -j ACCEPT # ssh
$IPT -A OUTPUT -p tcp --dport 80 -j ACCEPT # Webmin
$IPT -A OUTPUT -p tcp --dport 443 -j ACCEPT # https
$IPT -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -j DROP


$IPT -A FORWARD -p tcp -i $EXTDEV -o $INTDEV -d 192.168.0.100 --dport 80 -m state --state NEW -j ACCEPT
$IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A FORWARD -j DROP



thanks a lot for helping all!

is there some reason in particular why you are using SNAT instead of MASQUERADE??

also, what's this about??:

Good to hear that you got it working... & yea as your default policy for INPUT, OUTPUT & FORWARD is already drop; you do not need the above HIGHLIGHTED rules in your script.

Dear friends,

Initially i had the MASQUERADE, but then i changed it to SNAT because i need the DNAT to the internal webserver.., if without that SNAT the DNAT didn't work, I followed amitsharma_26's tutorial at
http://amitsharma.linuxbloggers.com/portforwarding.htm for the second scenario.

As for that...i also can't remember what is it for, I supposed without this line everything will stil work as normal.

Thanks guys!

Regards
Y