Bug 47376 - ip masquerading showing internal hosts ips (seawolf)
ip masquerading showing internal hosts ips (seawolf)
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: ipchains (Show other bugs)
7.1
i386 Linux
low Severity high
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-07-04 23:26 EDT by Need Real Name
Modified: 2005-10-31 17:00 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-07-07 16:04:16 EDT
Type: ---
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 Need Real Name 2001-07-04 23:26:34 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)

Description of problem:
Funny situation here, running redhat 7.1 full install.
Gateway/firewall is the redhat server all internal machines microsloth 
(microsof~1) windows based.

While using a gui ftp,irc or similar program the internal network is 
transmitted to the remote host, during dcc for irc and ftp for normal 
connections on port 21.  
non standard ftp ports appear to work fine. as does the dos based version 
of ftp.

The windows systems have had no new software installed, the only thing 
that was replaced was the redhat machine from version 7.0 to 7.1

I can put the 7.0 machine back and everything works fine again.

internal network is on the 10. segment there are also no ipchains rules 
being deployed other than.

ipchains -A forward -i eth0 -j MASQ
system is wide open from that point.

How reproducible:
Always

Steps to Reproduce:
1.no chains rules on gateway, replace eth0 with your own device
2.add ipchains -A forward -i eth0 -j MASQ
3.internal network with microsloth (microsof~1)os on 10. network
3.try to do a ftp with a gui program or dcc chat on irc from the 
microsloth (microsof~1) machines.
	

Actual Results:  Snippit from a ftp connection to ftp.kando.hu, all other 
do the same

350 Restarting at 0. Send STORE or RETRIEVE to initiate transfer.
PWD
257 "/" is current directory.
PORT 10,24,50,4,4,99
500 Illegal PORT range rejected.
LIST
425 Can't build data connection: Connection refused.

Expected Results:  350 Restarting at 100. Send STORE or RETRIEVE to 
initiate transfer.
REST 0
350 Restarting at 0. Send STORE or RETRIEVE to initiate transfer.
PWD
257 "/" is current directory.
PASV
227 Entering Passive Mode (209,199,216,69,113,154)

Additional info:

the expected results were from a non standard ftp port. Locally on the 
redhat machine everything works fine.
Comment 1 Michael Schwendt 2001-07-05 00:18:27 EDT
What's this report about? That the ipchains compatibility code in the
2.4.2/2.4.3 Kernel of Red Hat Linux 7.1 does NOT provide any protocol-specific
IP masquerading (ftp, irc, icq, etc.)? If you want that kind of masquerading
back, convert to iptables or downgrade to the 2.2.19 kernel (e.g. Red Hat Linux
7.0's).
Comment 2 Need Real Name 2001-07-05 09:59:55 EDT
Thank you for your input, as I was not the only person having this issue, and 
not being able to find any specific information about it. It looks like its 
time to convert to iptables sooner then we wanted to.
Comment 3 Need Real Name 2001-07-05 11:54:40 EDT
new update on this, as I have just disbaled ipchains and moved to ip tables

iptables -t nat -A POSTROUTING -o <device> -j MASQUERADE

no other rules running, NAT for web irc etc work but dedicated extra port 
required operations fail.   gui ftp  gui dcc chat etc, all still reporting 
internal network information.
Comment 4 Michael Schwendt 2001-07-05 12:30:06 EDT
What does "lsmod" give?
Comment 5 Need Real Name 2001-07-07 14:08:20 EDT
Sorry for the delay, I decided to re-install just to see if something got 
messed up, no go

All patches have been applied with the new kernels aswell.

output of uname -r -p

2.4.3-12 unknown

heres the output of lsmod

Module                  Size  Used by
iptable_filter          1696   0  (autoclean) (unused)
ipt_MASQUERADE          1136   2  (autoclean)
iptable_nat            11888   0  (autoclean) [ipt_MASQUERADE]
ip_conntrack           11824   1  (autoclean) [ipt_MASQUERADE iptable_nat]
ip_tables              10272   5  [iptable_filter ipt_MASQUERADE iptable_nat]
autofs                  8992   1  (autoclean)
ppp_deflate            39072   0  (autoclean)
bsd_comp                3872   0  (autoclean)
ppp_async               6256   1  (autoclean)
ppp_generic            16976   3  (autoclean) [ppp_deflate bsd_comp ppp_async]
3c59x                  23264   1  (autoclean)
usb-uhci               19472   0  (unused)
usbcore                46656   1  [usb-uhci]
ncr53c8xx              49232   0  (unused)
sd_mod                 11104   0  (unused)
scsi_mod               84416   2  [ncr53c8xx sd_mod]

same symptoms as previously encountered, before the re-install
Comment 6 Michael Schwendt 2001-07-07 16:04:13 EDT
Still the same behaviour after you have run

modprobe ip_conntrack_ftp
modprobe ip_conntrack_irc
modprobe ip_nat_ftp
modprobe ip_nat_irc

?
Comment 7 Need Real Name 2001-07-08 02:56:21 EDT
You are the man, worked like a charm, all ACTIVE flagged connections now 
properly masq'd

I'm going to close this ticket, thank you kindly I'm one step closer to being 
glad I paid for 7.1 :)

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