Hi,

I've followed the natd(8) to configure my ipfw/natd on a FreeBSD
machine. The machine itself has two NICs and I'm trying to let
computers on my private network connect to Internet via a single
allocated IP address. Although the ip sharing actually works, I
observe my private ip addresses are leaked out to the external network
(I saw an arp request to bind my private ip by my external NIC). I
also receive the following error messages from my network
administrator.

Could somebody tell me what I did wrong?

thanks


Problem 2: erroneous responses to IP broadcast traffic
One of your devices is currently responding incorrectly to IP
broadcast traffic. The traffic is from hardware address:
00:48:54:5d:51:91. This hardware address is registered in the Host
Database as: nhwang.student (Ethernet address) When this device
receives an IP broadcast packet from the campus and it decides that it
is not interested in the packet (or that something is in fact wrong
with the packet), the device responds by sending an ICMP error
message. This is not correct behavior; no device should ever send an
ICMP error message in response to broadcast or multicast traffic.
That's because when many devices behave in this erroneous fashion, it
creates very large traffic spikes on the network,
degrading network service for everyone. On large networks, such as
many that compose the campus network, this is a real danger. (In
certain situations, such behavior can even result in self-sustaining
broadcast storms that keep the network unusable.)
This sort of behavior can be caused by a bug in the device's IP stack,
requiring a bug fix from the vendor of the device. (In some unusual
situations, it may also be possible for a device to exhibit this
behavior as a result of incorrect configuration, but this is
uncommon.)
(We have seen this pattern before, and it has usually been due to the
use of NAT hardware or NAT software with a defective IP
implementation.)
As a result network access has been blocked. This device must be
disconnected from the campus network.

Problem 3: The device is improperly forwarding some kinds of UDP broadcast
The device behaves incorrectly when it sees some UDP/IP traffic
destined to a non-local IP destination. Here is an actual packet
capture taken on the campus network showing the problem as a sequence
of two packets:
22:05:36.666102 00:00:00:01:02:03 > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 60: IP (tos 0x0, ttl 64, id 1, offset 0, flags
[none], length: 29) 192.168.72.56.138 > 192.168.72.255.138: [udp sum
ok] NBT UDP PACKET(138)
22:05:36.666601 00:48:54:5d:51:91 > 00:09:12:a3:77:fc, ethertype IPv4
(0x0800), length 60: IP (tos 0x0, ttl 63, id 1, offset 0, flags
[none], length: 29) 140.180.153.96.138 > 192.168.72.255.138: [udp sum
ok] NBT UDP PACKET(138)

The first packet above is from hardware source address 0:0:0:1:2:3,
and is destined to the broadcast address. The IP source address is
192.168.72.56 (UDP port 138), and is destined to 192.168.72.255 (UDP
port 138).
Since your device is not assigned IP address 192.168.72.255, one would
normally not expect it to respond to this packet. However, the
customer's device retransmits the packet to 0:9:12:a3:77:fc. (That
destination is the hardware address of the OIT IP router for the
network to which the customer's device is attached.) Your device also
modifies
the packet, changing the IP source address to be 140.180.153.96 (the
IP address assigned to the customer's device). The fact that your
device also decrements the IP TTL from 64 to 63 as it forwards the
packet strongly suggests it is doing IP routing. (Clearly the routing
it is attempting is also broken, because an IP router should not
rewrite
the IP source address of packets it forwards.) The device should not
be acting this way. It should instead ignore this traffic. (I.e. it
should not be trying to route the traffic at all.) By transmitting
this erroneous traffic, it contributes to traffic storms on the campus
network.

Problem 4: Improper ICMP Errors in response to broadcast traffic

When the device sees any link-layer broadcast frames destined IP
address 140.180.191.255, the device responds by sending an ICMP
Redirect error message to the sender. It instructs the sender that the
proper route to 140.180.191.255 is via router 140.180.191.255. (Yes,
this is an nonsensical as it appears.) It's currently sending these
messages to the thousands of Dormnet hosts now online. This is wrong.
No device should ever respond to a broadcast frame by sending an IMCP
Error message.
Doing so results in broadcast storms.