How to open a port in ipchains

[Vernon Brown_4]

I need to open port 1494 for input and output so that I can use the county land survey database.

I tried putting in ipchains the following:

-A input -s 0/0 -d 0/0 1494 -p tcp -y -j ACCEPT
-A output -s 0/0 -d 0/0 1494 -p tcp -y -j ACCEPT

I can't connect; the county tech says my firewall is blocking port 1494. Can anyone find my error in the ipchains entry ????


Vern

[Stuart Browne]

It depends on what the rest of your firewall looks like, but here's my guess.

IPChains makes all incoming packets go through the 'forward' chain first, then the 'input' chain (for packets destined for the local host).

I'm picking port 1494 is not being allowed through the forward chain.

Try adding the same rule on your forward chain, as you've added on your input chain.

[Vernon Brown_4]

Thanks for your response Stuart; below is my
/etc/sysconfig/ipchains. I have two other ipchains entries in rc.local to MASQ my LAN onto the internet.

Looking at Altoona LUG Annotated IPChains Examples, it seems the first input below should be DENY. When I set it to DENY the server blocks everything. It seems to ignore the ACCEPT lines that follow. I'll try your suggestion.

Vern

:input ACCEPT
:forward ACCEPT
:output ACCEPT
-A input -s 0/0 -d 0/0 -p 1 -j ACCEPT
-A input -s 0/0 -d 0/0 1494 -p 0 -y -j ACCEPT
-A output -s 0/0 -d 0/0 1494 -p 0 -y -j ACCEPT
-A input -s 0/0 -d 0/0 53 -p tcp -y -j ACCEPT
-A input -s 0/0 -d 0/0 110 -p tcp -y -j ACCEPT
-A input -s 0/0 -d 0/0 25 -p tcp -y -j ACCEPT
-A input -s 0/0 -d 0/0 80 -p tcp -y -j ACCEPT
-A input -s 0/0 -d 0/0 21 -p tcp -y -j ACCEPT
-A input -s 0/0 -d 0/0 23 -p tcp -y -j ACCEPT
-A input -s 0/0 67:68 -d 0/0 67:68 -p udp -i eth0 -j ACCEPT
-A input -s 0/0 67:68 -d 0/0 67:68 -p udp -i eth1 -j ACCEPT
-A input -s 0/0 -d 0/0 -i lo -j ACCEPT
-A input -p tcp -s 0/0 -d 0/0 0:1023 -y -j REJECT
-A input -p tcp -s 0/0 -d 0/0 2049 -y -j REJECT
-A input -p udp -s 0/0 -d 0/0 0:1023 -j REJECT
-A input -p udp -s 0/0 -d 0/0 2049 -j REJECT
-A input -p tcp -s 0/0 -d 0/0 6000:6009 -y -j REJECT
-A input -p tcp -s 0/0 -d 0/0 7100 -y -j REJECT
"ipchains" 25L, 1126C

[Stuart Browne]

What you've shown us here is missing a few lines.

Can I get you to issue:

ipchains -nvL

And send the results of that.

Changing the default policy for the input chain to 'DENY' will break things.

It's currently configured as a SYN firewall. Basically, it's dropping packets (the REJECT lines) if they are new connections. That's about as good as you can get with IPChains.

My thoughts as to the forward chain are incorrect based upon what you've shown thus far however.

Need more info I'm afraid ;)

[Steven E. Protter]

I think we could get a little more by turning on enhanced loggging.

Then you can look at the logs and figure things out.

Simple tactic.

Turn the firewall off

service ipchains stop

Try the transaction then. If it still doesn't work its not the firewall blocking it. If it does work at least you are sure of the suspect.

I did an ipchains to iptables conversion on my old 7.3 Server(just upraded sunday, i miss it sniff*). I'd be happy to help with that conversion.

It might be easier to make this all work in iptables.

SEP

[Vernon Brown_4]

Following is result of the ipchains -nvl:

[root@linda /root]# ipchains -nvl
ipchains: no command specified
Try `ipchains -h' or 'ipchains --help' for more information.

Thanks Stuart; must be missing something in the command :o) The Linux is RedHat 7.1; I need to upgrade, I know.

Thanks SEP; I'll try your suggestion; only thing; I'm using IP MASQ. Might break my internet access when I stop ipchanins.

Vern

[Vernon Brown_4]

Oops; upper case L in -nvL

output is:

Chain input (policy ACCEPT: 1085 packets, 449583 bytes):
pkts bytes target prot opt tosa tosx ifname mark outsize source destination ports
0 0 ACCEPT udp ------ 0xFF 0x00 * 64.91.3.46 0.0.0.0/0 53 -> *
0 0 ACCEPT udp ------ 0xFF 0x00 * 208.34.220.20 0.0.0.0/0 53 -> *
32 4466 ACCEPT udp ------ 0xFF 0x00 * 127.0.0.1 0.0.0.0/0 53 -> *
0 0 ACCEPT icmp ------ 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 * -> *
Chain forward (policy DENY: 0 packets, 0 bytes):
pkts bytes target prot opt tosa tosx ifname mark outsize source destination ports
0 0 MASQ all ------ 0xFF 0x00 eth0 0.0.0.0/0 0.0.0.0/0 n/a
Chain output (policy ACCEPT: 1080 packets, 451779 bytes):

service ipchains stop

Turned off the service successfully; tried the connection; still wouldn't connect to the service but other internet connections went as usual.

Now I'm wondering about my Apache Proxy. Also wondering if I need the ipchains MASQ. I think I needed MASQ to get POP 3 working.

Thanks for any thoughts; I paid the county for the service; sure would like to use it. I'll also check with the service tech again.

[Vernon Brown_1]

I tried some more things with the tech for the system I'm trying to access:

Tried telnet to the IP with 1492 as port. Times out when trying to connect with anything on my LAN; connects Ok from the server console itself. Also connects Ok from the server with IPChains enabled.

Also connects when I telnet to my server then telnet from there to the remote IP port 1492.

Puzzle !!

[Vernon Brown_1]

I meant port 1494 -- :o(

[Vernon Brown_4]

After spending the day working on this problem I just realized I can't ping or telnet to anything on the internet from inside my LAN. Mail and http both work. Here's my network layout:




|
Internet
|
eth0
|
Firewall RedHat 7.1 Apache (HP 8500)
IPChains MASQ
|
eth1
|
------------LAN------------
| | |
eth0 eth0 eth0
Windows SuSE 9.0 Windows
httpd dns

The SuSE server is a development box to replace the Apache 7.1 eventually.

I'm about ready for IPTables. My fear is that I might break by internet access completely.

Vern

[Vernon Brown_4]

In case anyone is still following this thread:

I found one big error; last time I reformatted and re-installed RedHat 7.1 Linux I forgot that I have to apply the ipchains MASQ to ppp0, not eth0.

I now can telnet from inside my firewall to the remote service's port 1494.

[Vernon Brown_1]

SUCCESS !!

It's now working; the problem all along was masqurading the wrong device. Didn't need an ipchains entry except for the MASQ.

Thanks for your help; kept me going.

Vern