'unregistered_only' in natd does not work?
BigBrother-{BigB3}
bigbrother at bigb3.homeftp.net
Fri Jul 7 08:07:59 UTC 2006
Summary: NATD translates source addresses even though it should not because
unregistered_only is set and the IPs do not belong to RFC 1918 (like
192.168....)
Hi List,
I have a very strange problem in my
FreeBSD bigb3 6.1-STABLE FreeBSD 6.1-STABLE #0: Tue Jun 6
I am using the ftpd with inetd.
I have specified via sysctl IP_PORTRANGE_DEFAULT and IP_PORTRANGE_HIGH
net.inet.ip.portrange.first: 49152
net.inet.ip.portrange.last: 65535
net.inet.ip.portrange.hifirst: 49152
net.inet.ip.portrange.hilast: 65535
and I have opened my ipfw firewall for these ranges.
In natd.conf I am using:
same_ports yes
unregistered_only yes
use_sockets yes
log_denied yes
interface vr0
and I am using ipfw with
$fwcmd add 15000 divert natd all from any to any via $oif
***** T H E P R O B L E M ******
I have trouble making a passive ftp connection to work, because
every time natd changed source port even though it should not. Sometimes it
changes within the IP_PORTRANGE_DEFAULT but sometimes it changes it to
something completely irrelevant like 30000
The verbose log of natd shows this:
Out {default} [TCP] 193.92.?????:55211 -> 193.92.????:3866 aliased to
[TCP] 193.92.??????:37962 -> 193.92.?????:3866
Thus it shows that the outside IP and port (55211) in the source field was
changed to another source port (37962), even though this is not required.
My IPFW denies ports lowers than 49152 and thus it drops this and logs
that this packets was denied.
Can you help me please of how to either
1) instruct natd NOT to translate ports if it is not required
(unregistered_only seems that it does not work)
or,
2) instruct natd to translate ports which belong to either
IP_PORTRANGE_DEFAULT or another defined portrange?
Thank you very very much in advance,
Best Regards,
BB
p.s. After searching the freebsd bugs database I found
Problem Report bin/77089 : /sbin/natd: natd ignores -u with passive FTP
http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/77089, which seems similar.
Any clues except re-arranging the firewall rules, as the author of the
previous post suggests?
---
Dixi et animan levavi
More information about the freebsd-questions
mailing list