HELP - Airport Extreme Causing "IP Spoof" log on my Sonicwall....

Well, I'm glad I'm not alone. I have almost the exact same set up (except I'm on the 10.0.0.x subnet) with the same results:

"03/21/2007 12:23:35.368 IP spoof dropped 169.254.26.112, 138, LAN 169.254.255.255, 138, OPT MAC address: 00:16:cb:c2:ef:e0"

In fact, I have two Airport Extremes -- installed last night -- and they are both doing this every 24 minutes:

"03/21/2007 12:20:58.016 IP spoof dropped 169.254.39.251, 138, LAN 169.254.255.255, 138, OPT MAC address: 00:16:cb:c2:f0:4f"

The SonicWall manual defines an "IP Spoof" as follows:

An IP Spoof is an intrusion attempt in which a hacker attempts to send TCP/IP packets using the address of another computer. This can be used to access a protected network by using an IP address of a machine on the protected network. The SonicWALL recognizes this as an intrusion attempt and drops these packets. An IP spoof alert on the log often indicates a SonicWALL misconfiguration; if you see an IP spoof alert, make sure that all IP addresses on the LAN, WAN, and OPT are correct. This can also occur if an IP address on the LAN does not fall within the LAN subnet.

I've rechecked and updated the entries on the SonicWall and all seems correct. What I'm trying to figure out is why are the AEBS units broadcasting on the 169 subnet on the NETBIOS Datagram Service (see http://www.iana.org/assignments/port-numbers)? I assume I'm reading this correctly? I do have "Advertise configuration globally using Bonjour set" so I'm wondering if that has something to do with it.

Any ideas? j.donahue, did you resolve your problem?

Thanks,
Chip

iMac G5 and MacBook Pro Mac OS X (10.4.9) .Mac, Plaxo and PocketMac (for BlackBerry)

OK, I'm continuing to research this issue and turning offf the bonjour advertisement had no effect. However, I did discover that the 169.254/16 addresses are part of something called APIPA (Automatic Private IP Addressing):

http://www.webopedia.com/TERM/A/APIPA.html

It is supposedly a feature on windows operating systems but I now explicitly Windows machines (unless my SnapServer or SonicWall are running windows which I doubt). The MAC address points that these addresses are coming from the AEBS units, anyway.

To quote Webopedia: When a DHCP client boots up, it first looks for a DHCP server in order to obtain an IP address and subnet mask. If the client is unable to find the information, it uses APIPA to automatically configure itself with an IP address from a range that has been reserved especially for Microsoft. The IP address range is 169.254.0.1 through 169.254.255.254.

Now, my AEBS are set up with their Ethernet interfaces configured manually:

IP: 10.0.0.10 and 10.0.0.11
Subnet: 255.255.255.0
Router: 10.0.0.1

So, the question I have is why is the AEBS supposedly using APIPA looking for a DHCP server?

Thanks,
Chip


iMac G5 and MacBook Pro Mac OS X (10.4.9) .Mac, Plaxo and PocketMac (for BlackBerry)

Hopefully readers of this thread won't mind but I'm going to document my trials and what I learn as I debug this issue.

First, since I have static DNS entries on the Sonic Wall for the AEBS, I switched from manual to DHCP addressing on the WAN port of the AEBS units -- they didn't need to be manual, anyway. However, I'm still getting the 169.254/16 address spoofs.

As far as I can tell, this may be related to the Apple's ZeroConf Bonjour service which uses APIPA:

http://en.wikipedia.org/wiki/Zeroconf
http://en.wikipedia.org/wiki/Bonjour_%28software%29

Still, if the AEBS has received (and is showing via Airport Utility) a valid IP address (e.g. 10.0.0.10), then why is it sending out broadcast packets as if it is 169.254.26.112, for example? Is it looking to see if there are any other ZeroConf/Bonjour clients out there needing help? If so, it seems like there should be a way to turn this off since I think it would be reasonable to assume with a DHCP server running that service is not needed. I just don't know if this line of thought is on target or not.

FWIW, I have configured both AEBS for ethernet bridging since I want my SonicWall's DNS server to resolve all addresses to the 10.0.0.x network. The network is small enough that it make sense, to me at least.

Chip


iMac G5 and MacBook Pro Mac OS X (10.4.9) .Mac, Plaxo and PocketMac (for BlackBerry)

OK, I've been able to stop the annoying IP Spoof alerts (though not the underlying messages causing the alerts) but I still don't understand the underlying issue.

I decided to see if I could get the SonicWall TZ170 to stop complaining about IP Spoofs coming from my AEBS units. One thing that was evident was the netbios (port 138) requests were coming from the LAN interface to the OPT interface. Now, I'm not sure if it's the LAN side or the OPT side that is complaining but I decided to assume it was the OPT (DMZ) interface.

From the SonicWall Administration pages, under Firewall -> Advanced the option "Windows Networking (NetBIOS) Broadcast Pass Through From LAN to DMZ" had been selected. I don't think i really need that since I have no windows machines and nothing on my OPT port. I experimented with turning that off and Voila! SUCCESS, of sorts. Now that the NetBIOS packets aren't being forwarded to the OPT/DMZ port, the alerts have stopped.

Of course, that doesn't mean the packets have stopped being broadcast on my LAN; it just means the SonicWall has stopped complaining. Given the frequency is just 1 packet every 24 minutes per AEBS, I can put this on the back burner, but I'd love to understand why these AEBS unites are sending out packets on the LAN (via their WAN interface) with source addresses different from the ones assigned to their WAN ethernet interface.

Chip


iMac G5 and MacBook Pro Mac OS X (10.4.9) .Mac, Plaxo and PocketMac (for BlackBerry)

Just a couple of things you should note.

1. The SonicWALL itself does not have an internal DNS server. Any resolution you are receiving within the network is due to NetBIOS, not the SonicWALL or the Airport Extreme.

2. You are probably using SonicOS Standard, and you most likely do not have the OPT port configured. Configure the OPT to have an IP in a subnet other than the one used on your LAN, and IP Spoofs can no longer occur since the SonicWALL will not see the Airport Extreme (or PCs/Macs behind it) on a subnet that is based on another interface within the device. The OPT port sometimes acts a bit strange when it has not been configured, and there are options configured to make use of it. You may want to upgrade your firmware on the device as well.

3. This does not occur with an Airport Express working in a similar manner as the Airport Extreme. For what it's worth, maybe that can help you.

Just a couple of things you should note.

1. The SonicWALL itself does not have an internal DNS
server. Any resolution you are receiving within the
network is due to NetBIOS, not the SonicWALL or the
Airport Extreme.

Erg, sorry, I mis-typed. I know the SonicWall doesn't have a DNS server. I was referring to the static DHCP server entries. Sorry for the confusion.

2. You are probably using SonicOS Standard, and you
most likely do not have the OPT port configured.
Configure the OPT to have an IP in a subnet other
than the one used on your LAN, and IP Spoofs can no
longer occur since the SonicWALL will not see the
Airport Extreme (or PCs/Macs behind it) on a subnet
that is based on another interface within the device.
The OPT port sometimes acts a bit strange when it has
not been configured, and there are options configured
to make use of it. You may want to upgrade your
firmware on the device as well.

Yes, I am running the Standard version and I do not have the OPT port configured. You suggestion is interesting and I will look into doing it; however, just turning off forwarding of Netbios packets as described above basically fixed that problem. I have upgraded the firmware on the device to the latest version thanks to the DST change.

3. This does not occur with an Airport Express
working in a similar manner as the Airport Extreme.
For what it's worth, maybe that can help you.

It does help but I'd still like to understand why the AEBS are advertising on the 169.254/16 subnet.

Chip

It sounds to me like packet capture is in order. Its your best bet of finding out what the Airport is doing. Check out http://ethereal.com/download.html. Under the Other Platforms section you will see links to OSX ports of Ethereal.

They aren't the most fun to read, and certainly printing them out for bed time reading will land you with a headache 😉

Good luck.

Jaime,

Thanks for the suggestion and I'm pursuing that option. However, I thought I'd share that ethereal is has been superseded by wireshark:

http://www.wireshark.org/

After some trial and error, I found the following which is getting me to a working version of wireshark:

http://www.methnen.com/icould_be_brave/entry/installing_wireshark_on_osx/

Cheers,
Chip


iMac G5 and MacBook Pro Mac OS X (10.4.9) .Mac, Plaxo and PocketMac (for BlackBerry)

OK, I put my MacBook running Wireshark on the same ethernet segment as one of the AEBS and captured a few of the packets in question. In fact, I saw packets from both AEBS and Wireshark is confirming (via the MAC addr) the packets are coming from the new 802.11n AEBS.

Summary wise, they are coming about every 720 seconds from 169.254.39.251 and 169.254.26.112 though they are offset from one another as previously reported. The destination is a broadcase address of 169.254.255.255 and the protocol is "BROWSER." Info is listed as "Host Announcment xxx-OFFICE, Workstation, Server" where "xxx" is either "CHIPS" or "TERRIS" identifying the name of the two AEBS.

The UDP packet is a netbios-dgm (138), for example,
Source name: TERRIS-OFFICE<20> (Service Service)
Destination name: WORKGROUP<1d> (Local Master Browser)

I then see sections on "SMB (Server Message Block Protocol)" -> SMB Command: "Trans Request (0x25)" -> Transaction Name: "\MAILSLOT\BROWSE".

The next segment is "SMB MailSlot Protocol" -> Opcode: "Write Mail Slot (1)", Size: "50", Mailslot Name: "\MAILSLOT\BROWSE".

And the last segment is "Microsoft Windows Browser Protocol" -> Command: "Host Annoucement", Host Name -> "TERRIS-OFFICE", OS Major Version: "4", OS Minor Version: "30", Server Type = "Workstation" + "Server".

So, it looks like I need to look into the SMB Mailslot Protocol and the Microsoft Windows Browser Protocol but I'm starting to wonder if this has something to do with the AEBS now being able to host a disk drive.

Chip


iMac G5 and MacBook Pro Mac OS X (10.4.9) .Mac, Plaxo and PocketMac (for BlackBerry)

Apparently, this is a bug and it has been reported to Apple:

http://discussions.apple.com/thread.jspa?messageID=4104556&#4104556

BTW, where does one report a bug and/or check on the status of or look for workarounds for a bug with the AEBS?

Chip

I don't know of any official location for submitting bugs. I have never looked into it. I assume Apple reviews the forums to find hot issues once in a while, but I may be wrong. Maybe signing up as a Developer would get you that ability if it isn't available to just anyone.

Just downloaded this update:

The AirPort Base Station Update 2007-001 includes general fixes, compatibility updates, and security improvements for the following applications:
- AirPort Utility
- AirPort Admin Utility for Graphite and Snow Base Stations
- AirPort Disk Utility
- AirPort Disk Agent

We'll see if this fixes the problem.

Chip


iMac G5 and MacBook Pro Mac OS X (10.4.9) .Mac, Plaxo and PocketMac (for BlackBerry)

Well, there was no new basestation firmware in that upgrade so the answer is "no". I guess I should have taken the description at it's word.

Chip