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
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to