Click to See Complete Forum and Search --> : a little help please...


drstrangelove
08-16-2001, 06:03 PM
I have set up iptables (finally) and tried to forward a couple of ports (21 & 80) but nothing works if I try to access them from outside the network.
iptables -L -t nat returns this:
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp -- anywhere adsl-65-66-126-134.dsl.rcsntx.swbell.nettcp dpt:http to:192.168.0.5:80
DNAT tcp -- anywhere adsl-65-66-126-134.dsl.rcsntx.swbell.nettcp dpt:ftp to:192.168.0.5:21
DNAT tcp -- anywhere adsl-65-66-126-134.dsl.rcsntx.swbell.nettcp dpt:ftp to:192.168.0.5:21

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 192.168.0.0/24 anywhere
MASQUERADE all -- 192.168.0.0/24 anywhere

[root@dnafw /root]# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp -- anywhere adsl-65-66-126-134.dsl.rcsntx.swbell.nettcp dpt:http to:192.168.0.5:80
DNAT tcp -- anywhere adsl-65-66-126-134.dsl.rcsntx.swbell.nettcp dpt:ftp to:192.168.0.5:21
DNAT tcp -- anywhere adsl-65-66-126-134.dsl.rcsntx.swbell.nettcp dpt:ftp to:192.168.0.5:21

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 192.168.0.0/24 anywhere
MASQUERADE all -- 192.168.0.0/24 anywhere
MASQUERADE all -- 192.168.0.0/24 anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

This looks like it is working, but I just don't know what else to do. I can post the complete output of iptables -L if that would help. I could also post the entire firewall script I am using if anyone needs to czech that out...
I thank you all in advance,
Dr. Strangelove

linlu
08-17-2001, 01:32 AM
Can you list the Forward chain? From what I recall of the diagram/how-to, anything not destined for the local machine must be taken care of by a forward chain entry.

From: http://www.sentry.net/~obsid/IPTables/rc.scripts.dir/current/rc.firewall.iptables.multi (http://www.sentry.net/~obsid/IPTables/rc.scripts.dir/current/rc.firewall.iptables.multi)
##================================================ ========================##
## Jump to our FORWARD chains.
##================================================ ===================##

## Jump to our (INTERFACE)_INPUT/OUTPUT Chains.
$IPTABLES -A FORWARD -i $EXTERNAL -j EXTERNAL_INPUT
$IPTABLES -A FORWARD -i $INTERNAL -j INTERNAL_INPUT
$IPTABLES -A FORWARD -i $DMZ_IF -j DMZ_INPUT
$IPTABLES -A FORWARD -o $EXTERNAL -j EXTERNAL_OUTPUT
$IPTABLES -A FORWARD -o $INTERNAL -j INTERNAL_OUTPUT
$IPTABLES -A FORWARD -o $DMZ_IF -j DMZ_OUTPUT
The script defines what is done in those chains. I think you need to add your hosted ports to the "ALLOW-PORTS" variable near the middle top. Also FTP requires 20 and 21.

- linlu
(not anywhere near a grasshopper by any stretch)

[ 17 August 2001: Message edited by: linlu ]

[ 17 August 2001: Message edited by: linlu ]

drstrangelove
08-17-2001, 09:29 AM
I am also using the script from the link above. I added the ports (20,21) to the "ALLOW_PORTS" I noticed though, in the comments to that section that

################################################## #############################
## Special Chain ALLOW_PORTS
## Rules to allow packets based on port number. This sort of thing is generally
## required only if you're running services on(!!!) the firewall or if you have a
## FORWARD policy of DROP(which we don't right now).

Here is an excerpt (with with changes to reflect my setup (Note that where it says 20:22, I have also tried (without the quotes "20 21 22") with no success:



-------------------------------------------

$IPTABLES -N ALLOW_PORTS
$IPTABLES -F ALLOW_PORTS

##------------------------------------------------------------------------##
## ACCEPT TCP traffic based on port number. (Examples)

# TCP_PORTS="ssh domain"
TCP_PORTS="20:22"

for PORT in $TCP_PORTS; do
$IPTABLES -A ALLOW_PORTS -m state --state NEW -p tcp \
--dport $PORT -j ACCEPT
done
##------------------------------------------------------------------------##
## ACCEPT UDP traffic based on port number.

# UDP_PORTS="domain"
UDP_PORTS="20:22"

for PORT in $UDP_PORTS; do
$IPTABLES -A ALLOW_PORTS -m state --state NEW -p udp \
--dport $PORT -j ACCEPT
done

##------------------------------------------------------------------------##

-------------------------------------------

Here is a copy of my forward rules:

$IPTABLES -P FORWARD ACCEPT

Then a little later...:

## Jump to our (INTERFACE)_INPUT/OUTPUT Chains.

$IPTABLES -A FORWARD -i $EXTERNAL -j EXTERNAL_INPUT
$IPTABLES -A FORWARD -i $INTERNAL -j INTERNAL_INPUT
$IPTABLES -A FORWARD -o $EXTERNAL -j EXTERNAL_OUTPUT
$IPTABLES -A FORWARD -o $INTERNAL -j INTERNAL_OUTPUT


If if would help I can post the entire script here for any of you gurus to peruse. I sort of understand what is going on but I can't figure out why this won't work...
I have a much weaker set of rules in a different script and port-forwarding works in it (with the EXACT same lines of code (actually I pasted it from this one--go figure...))
Any help is greatly appreciated...
Thanks in advance...
Dr. Strangelove

drstrangelove
08-17-2001, 09:52 AM
Hey I just check the links listed in the firewall script. I checked out the documentation link at: http://www.sentry.net/~obsid/IPTables/rc.scripts.dir/current/DOCUMENTATION

Here is what I found...

ALLOW_PORTS
The ALLOW_PORTS chain simply ACCEPTs packets based on port number. If you have
a default FORWARD policy of DROP, then you would need to utilize a chain like
this if you are DNATing/routing connections behind the firewall or perhaps
running services on(!!!) the firewall.


Does this mean I should make my default FORWARD policy DENY? I don't understand, I am running sshd on the firewall so I can access it from work, and the default policy is ACCEPT. Now I think I am utterly confused...

drstrangelove
08-17-2001, 10:08 AM
something else I've noticed since using this new firewall script....
whenever I go to an ftp site from a machine on the internal network, I can login, and cd to different directories, but I can't ls or dir... I get this error message:

230 Anonymous access granted, restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
500 Illegal PORT command.
ftp: bind: Address already in use
ftp>

AAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHH!!!!!!!! !!!!!!!!!!!!!
I tell you what people, I just don't know what is going on!!!
With this new firewall I've also noticed that portsentry has nothing in it's logs (probably because of the stronger firewall rules (which I guess is a good thing (although I did like the idea that portsentry added their IP to /etc/hosts.deny))). I suppose I could go back to the older firewall script and let portsentry do it's thing...
/me sits in the corner and pouts....
:(

[ 17 August 2001: Message edited by: drstrangelove ]

drstrangelove
08-19-2001, 11:55 AM
Bump

linlu
08-19-2001, 02:53 PM
Hello, I was wondering, is your SNAT address line using this address? 192.168.0.0/24

I ask because it appears that you're masking your FTP server again on the DNAT line.

Doesn't the SNAT network masq also do the work for the DNAT line in your example? I would think that by NATing at the network address then again attempting to NAT a specific host within your already NATd network would cause problems. I'm a real newbie, so this could be a wrong understanding of you DNAT and SNAT work in the same script.

I have a similar 'problem' in my ipchains script I'm trying to get working for a new server - where we previously were just surfing. I happen to have two internal IPs and two external IPs I can play with. I also have a second internal firewall that MASQ/SNAT all my surfing traffic onto one IP address. So in my rework script, I am MASQing a host IP (not a network ip) for our internal surfers, and I am portfw/DNAT my server traffic on a different pair of IPs.

- linlu
a confused listener: http://www.linuxnewbie.org/cgi-bin/ubbcgi/ultimatebb.cgi?ubb=get_topic&f=13&t=004970
http://www.linuxnewbie.org/cgi-bin/ubbcgi/ultimatebb.cgi?ubb=get_topic&f=13&t=004988

jumpedintothefire
08-19-2001, 11:50 PM
From Rusty's guides for IPtables:

Inside the netfilter distribution, there are currently modules for ftp: ip_conntrack_ftp.o and ip_nat_ftp.o. If you insmod these into your kernel (or you compile them in permanently), then doing any kind of NAT on ftp connections should work. If you don't, then you can only use passive ftp, and even that might not work reliably if you're doing more than simple Source NAT.

Do a lsmod and see if the modules are loaded.


There is a same type of module for outbound connections with ipchains

If these are not loaded you will have problems....

Also make sure that that the your server on the private is using the firewall as a default gateway. (that one through me for a loop once...) :rolleyes:

Mail me the script, I'll have a look.

>linlu, Did you get yours going?

linlu
08-20-2001, 03:15 PM
>linlu, Did you get yours going?
Still working on it. I'm rewriting the old script that my comrade/compatriot wrote. I'm also adding bits and pieces from other sources like http://www.sentry.net/~obsid/IPTables/rc.scripts.dir/current/rc.firewall.iptables.multi
but I'm adapting it for ipchains.
I would like to use iptables, but I'm such a newbie, that I'm still building that box. I'm only able to devote about 1-2 hours per day. To put into context how much of a newbie I am, picture this:
CDROM pulled from computer case with label of "BAD CDROM"

When you pick yourself off the floor, yes I finally figured out there was an UMOUNT command. I wish I could post pictures - we'd need a whole new subject area for that - "newbie DOH!s"

- linlu :rolleyes:

drstrangelove
08-22-2001, 05:39 PM
I have figured it out...
I added a bunch of "echo" statements to know if and when an error occurred. I knew I did this for a reason :rolleyes: . I looked at the messages produced by the firewall script and I have concluded (I think) that there was a small error early on in the script.
My explanation might be convoluted, oh well here goes:
In the beginning of the script I had:
EXT_IP=`ifconfig $EXTERNAL | grep inet | cut -b 21-34` ## IP address of External Interface
This was supposed to give me the IP of the external device. Sometimes it did. However, since I am getting dynamic IP's from my ISP, this didn't always work. For example, if my ISP gave me 66.66.208.86 and I ran that command to get the IP it would return:
66.66.208.86 P
I couldn't always determine how many digits would be in the IP. If I had piped it to cut -b 21-33, I could be missing digits from the IP addy, whereas if I piped it to 21-35 I could get alpha characters in the IP addy.
Are you with me? I hope so.
Here's what I did to rectify that:
EXT_IP=`ifconfig $EXTERNAL | grep inet | cut -d : -f 2 | cut -d \ -f 1`

Everything else seems to work now.
HOORAY!!!!
I do have another problem now that isn't (I think, but who knows :confused: ?) firewall related. One one of the internal machines I have Win2k running, with Bearshare to get *stuff*. However, I have noticed that recently whenever Bearshare is running the ADSL disconnects, reconnects, disconnects, reconnects, ad nauseum... I have looked at the logs and there are weird messages that show up. This only happens when I launch bearshare and stops when I quit bearshare. I can post some of the weird errors from the logs if anyone would like to czech them out. I have had bearshare running on that machine for months now and have had no problem up until last friday. I have not changed the version of bearshare or anything. I cannot think of what would cause this problem. It is mainly upsetting me because I cannot keep a connection up for 15 min at a time, and that makes it difficult for me to ssh in from work.
Oh well, if anyone wants to see the excerpts from the logs, let me know.
Thanks for all the help and suggestions,
Dr. Strangelove