I want to open 177 port of remote server for mypc.com.

I wrote this at iptables, but I could not connect mypc.com with remote server.

Kindly let me know what I am wrong?

I think part of the problem may be the -m state portion of your iptables line in that you don't allow established connections to pass through. I would suggest for starters removing the state portion and focus on the protocol, destination and source.

Also, do you have an application listening on port 177? You can confirm that the program is listening on the port and protocol using netstat, eg: 'netstat -ntp | grep 177' and you should see the application.

Next, you can use nmap against your (external) ip address to see if the connection is open through to the application.

1 members found this post helpful.

Thanks Noway2,

According to your suggestion, sould I change iptalbes like this?

"-A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 177 -s mypc.com -j ACCEPT"

About "netstat -ntp | grep 177", there is nothing.

Am a newbie too, but may be you want to check the default INPUT chain for any rules that may be blocking the port.

And also as Noway2 mentioned you can ignore the state portion.

i.e
This should do the trick.

And as I mentioned, please check the default INPUT chain, you can flush it if you are using the RH-Firewall-1-INPUT for all the rules.

1 members found this post helpful.

Vinodvb is correct, drop the --state portion because it will cause to drop established connections, which is what they become after they pass through the new state.

Re the netstat command returning nothing, this indicates that there is no process behind the firewall listening on this port. Without an application opening a port in the firewall is meaningless. The reason I asked this question is because 177 seemed like an odd choice of port number. Do you plan on using a particular application for these connections?

1 members found this post helpful.

Noway2/

Yes, I want to connect my local pc to remote connect through xmanager. But I have a big problem.

The manager at IDC installed iptables on my remote server for security.
As you can understand I am not an exprt of Linux. So I tried to connect remote server for 4 months.

I added this codes to remote server's iptables, but I received an error message.

error message

I am pretty certain that IP tables is built into the Linux kernel itself rather than being an application that is installed. Consequently, it is always there. It can however, be disabled, at least temporarily. In a Linux environment, this is even relatively safe to do because unlike Windows, unless an application is running and listening on a port, it is closed. This means that a firewall acts more as a second layer of protection to keep you from inadvertently opening a port unintentionally rather than a primary layer that is required to keep you from become infected with Malware.

In order to test whether or not iptables is the problem, you can issue the command iptables -F (-F for flush) which will clear all the rules and should cause it to accept all connections. I recommend this as a test to verify whether or not the iptables rules are causing your problems, not as a permanent fix.

The error message you received in response to your command was caused by you running the command as 'root' as seen by root@remote_server, which is not a safe practice. When you execute a program it assumes the permissions of the user's account that started it. If the account was root, that application will have unfettered access to do almost anything to the system. Some programs must run with this level of privilege when started by non root users and this is accomplished by the setuid permission bit, which is the other reference in your error message.

I have never used xmanager before, but it looks like an interesting application. I would first recommend that you try running your application as a regular user. If you need help with getting that running, LQ can help with that.

As far as your iptables commands go, I see two problems. First, I suggest you remove the '-m state --state NEW' portions. The rules will allow connections from mypc.com on the ports specified without it, which is what you want. Second, when you write iptables rules, think of them as a waterfall. If a rule 'matches' it will stop and execute that rule and no rules below will be looked at. Therefore, your -j REJECT looks like it will cause all rules below it to be ignored, in which case you may not be opening port 177 in your firewall for xmanager to connect. I would put that rule at the very bottom of the list. That command MAY work only on ICMP traffic, in which case my last sentence is a non issue - again one way to test is to temporarily flush your iptables.

1 members found this post helpful.

Noway2/

Thanks for your kind explanation.

According to your instruction, I changed my iptables as follows;

About "iptables -F", after entering this command my ssh connection of putty was disconnected and I could not connect again. Also I could not open web from remote server.

About the user of xmanager, I have changed my id of remote server. But still I could not connect my remote server.

Looking forward to your further attention.

It looks like your default policy is set to DROP rather than accept. With this setting, flushing the firewall must have closed all the connections rather than clearing them. My apologies, I should have mentioned to check / change that before issuing the flush command. You can achieve a similar effect by placing a catch all drop statement at the end of the list and setting the policy to ACCEPT so that flushing clears everything instead of closing the ports.

From what I can tell your latest set of rules looks pretty good. You are accepting DNS traffic, accepting new connections on telnet and ssh from a specified address, accepting established connections, and various ports from your 'mypc' for Xmanager.

Some other hints to keep in mind as you work on this: you can also use namp on your system to verify which ports are open and you can use netstat to see if a program is listening on the port. Sometimes looking at the output of ps (and grepping for the program name) can be useful if you don't see a process listening / open port that you expect. If you don't see the program running via ps, often times syslog will contain an entry that helps point to the problem. An error in a configuration file, for example, can keep programs from starting.