Bug 815313 - Manual entry for IP tables is not working
Manual entry for IP tables is not working
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: iptables (Show other bugs)
6.2
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Thomas Woerner
qe-baseos-daemons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-23 06:42 EDT by Sebastian
Modified: 2012-11-06 08:47 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-06 08:47:19 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sebastian 2012-04-23 06:42:43 EDT
Description of problem:

Hi,

I'm not sure if there is some issue but when I enter IP tables rule manually it's not working. By manually I mean two methods:

1. by editing /etc/sysconfig/iptables file and then iptables-restore /etc/sysconifg/iptables

2. via command line:

iptables -I INPUT 5 -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT

When I configure firewall with tui tool (system-config-firewall-tui) everything works fine.

I can see incoming packets on the firewall:

#####
iptables -nL -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
81 5641 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
3 180 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:21
10 816 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 99 packets, 9396 bytes)
pkts bytes target prot opt in out source destination
#####

Nmap scan from remote machine shows that the port is open:

#####
nmap -PN -p 21 192.168.1.25

Starting Nmap 5.21 ( http://nmap.org ) at 2012-04-21 09:07 BST
Nmap scan report for 192.168.1.25
Host is up (0.00051s latency).
PORT STATE SERVICE
21/tcp open ftp

Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds
#####

Message from lftp client:

#####
lftp 192.168.1.25:/> debug
lftp 192.168.1.25:/> ls
---- Connecting to 192.168.1.25 (192.168.1.25) port 21
<--- 220 (vsFTPd 2.2.2)
---> FEAT
<--- 211-Features:
<--- EPRT
<--- EPSV
<--- MDTM
<--- PASV
<--- REST STREAM
<--- SIZE
<--- TVFS
<--- UTF8
<--- 211 End
---> OPTS UTF8 ON
<--- 200 Always in UTF8 mode.
---> USER anonymous
<--- 331 Please specify the password.
---> PASS lftp@
<--- 230 Login successful.
---> PASV
<--- 227 Entering Passive Mode (192,168,1,25,59,68).
---- Connecting data socket to (192.168.1.25) port 15172
**** Socket error (No route to host) - reconnecting
#####

When I update the rule from the system config tool I can access FTP server.

I compared both files (manual entry and from the system config tool) and there is not difference.


System Info:

- minimal GNOME Desktop installation

- Red Hat Enterprise Linux Server release 6.2 (Santiago)

- Linux localhost.localdomain 2.6.32-220.el6.x86_64 #1 SMP Wed Nov 9 08:03:13 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

- SELinux enabled in enforcing mode

- default VSFTPD install

Version-Release number of selected component (if applicable):

- Red Hat Enterprise Linux Server release 6.2 (Santiago)

Regards
Comment 2 Thomas Woerner 2012-09-04 09:55:41 EDT
Are you enabling the ftp trusted service in the config tool or are you adding the port 21/tcp only?

If you are enabling the trusted service ftp, not only the port will be opened, but also the conntrack helper for ftp will be loaded. This enabled the use of ftp and ftp-data connections.

Note You need to log in before you can comment on or make changes to this bug.