Hey Guys,

Posting this up again. Trying to simply do port forwarding on a RH7.3 box and the bloody thing wont work. I am using the rc.firewall-2.4-stronger script from the IPMasquerading HOWTO from LDP. When I use the rc.firewall-2.4 script which is less strict, I get port forwarding to work but the funny thing is none of my LAN (masqueraded computers) can access any of the services like FTP, SMTP, DNS from the external interface even though suppossedly the kernel 2.4 should work with that.

I just want to know has anyone gotten this to work with Redhat 7.3? Here is my exact script:

rc.firewall-2.4-stronger script

Can anyone tell me where I am going wrong. And yes i did my homework, disabled IPchains completely, made sure i set /proc/sys/net/ipv4/ip_forward to 1 as well as set the FORWARD_IPV4 value in /etc/sysconfig/network to 1. Why RH puts both of them there is beyond me.

Someone please save me, i am going crazy with this simple thing.

Thanks

You did the tests described in the howto? *What* servers can't they reach, local or remote? Example? What does the log say for that example? grep logfile -e "DENY" | grep "(src IP)" | grep "(dest IP)".
Tried logging everything and then try accessing again?

/proc gets values from scripts usually by echoing values to the appropriate key or using sysctl.

They cant access any of the servers like FTP, WWW, DNS, SMTP on the external Interface.

Basically from a LAN machine I can reach any of these 4 servers only by their private IP address such as 192.168.1.2 for the DNS server and 192.168.1.4 for the WWW server.

I want to be able to get to them from the one external IP address I have hence why I am using port forwarding. The non-strict rc.firewall-2.4 script seems to work with the port forwarding but only if you are coming in from the internet not from the LAN. The stronger script does not forward at all.

When you say log file do you mean /var/log/messages ? I looked in there and there doesnt seem to be any deny entries.

And yes, I did the tests in the HOWTO.. but all the tests seem to be for masquerading which works great but I didnt see any test for the port forwarding.

Thanks for the response. Any thing else II need to do. i am going to try your suggesstion and out the grep statement in there to do some logging.

Will keep you posted. If ya think of anything else, let me know.

Thanks a bunch!

Having logging rules that logs *everything* is good for troubleshooting. That way you can figure out yourself what get's blocked and why. I wish everyone would enable such things during testing.

You mean you would like LAN clients for instance to access your public SMTP server by it's public IP address? Do you have a rule on the input chain allowing access where the dst and src IP are both that of your public address? Cuz that's what you're basically doing, right (translate LAN IP to public IP and then access same public IP)? Wasn't there an example for httpd in the script?

(someone correct me if I'm whorrabwy wonk.)

Yep, you are right. Exactly! Trying to access SMTP from LAN computers by the public IP.

I am still trying to figure out all what that script is doing cuz I think my problem lies in there somewhere. Did you get a chance to look at it?

Evil Script.. cusing me headaches!!!

Wit regards to logging, do you know any example I can cut and paste to see whats going on? I am going back to the drawing board to read and understand what each line in that script is doing. Thanks for your help, and again if you think of anything let me know.

Thanks!!!

I haven't looked at the script but I can tell you how it should work.

This is how the connection will work when inside the lan and trying to port forward from the firewall real ip.

192.168.0.10 -------> firewall internet address -------> port forward --> 192.168.0.20

192.168.0.10 waiting for firewall to reply to SYN with SYN ACK.
192.168.0.20 reply's to 192.168.0.10 directly, packet dropped cause 192.168.0.10 is expecting it from firewall not LAN.

Change your postrouting rules so the lan 192.168.0.20 talks back to the firewall, which then connection tracks it back the other system completing the TCP 3 way connection correctly.

Mr Iptables.

There are a lot of variables in that firewall.stronger script..
We could have a lot of questions about which modifications you made...
So,
Please do a "service iptables save", rename the /etc/sysconfig/iptables file to say iptables.lq and post it here, (removing your own ip address)
and note which interfaces you are using for LAN and internet please.

It will be much easier to see the end result compared to the original and go from there.
When is the script activated?

Regards,
Peter

Thanks guys for all the help. Peter_robb, per your suggestion,

here is the result of the "service iptables save:

service iptables save . Also listed that my eth0 is my external IP interface and eth1 is the LAN interface.

The script is activated right after the network cards are enabled. I followed the HOWTO to make sure its the first thing that gets run after the interfaces are brought up.

Thanks a bunch and let me know if you see anything that might fix this. Again, the masquerading part works great. It just wont do port forwarding and neither will you let u access services from the external interface which makes sense if forwarding is not working to begin with.

Let me know.

A much grateful bloke.

Ok,
2 things...

The FORWARD rules are referring to -o interfaces by ip numbers, which don't exist on the firewall...
Usual default behaviour will then be to drop packets because nothing will match them...

And, there isn't a -p udp rule to match dns. Dns will only use tcp if the packets are BIG.

So, I recommend you change those rules first, get something working and then we can fill you in on all the other rules which are missing, eg INPUT policy and protection, Masquerading vs SNAT, /proc/sys/net/ipv4/conf/.../rp_filter etc

Please make a note of which changes/decisions you made in the original script, eg interfaces, dynamic/static numbers, services etc.

Regards,
Peter