faultbucket

Routing issue due to Wireless ISP network range

November 23, 2010November 23, 2010 Jeff Miles Leave a comment

Just solved a particularily troublesome issue that wasn’t obvious at first but makes sense now.

Intro

We have multiple Internet connections from multiple providers; this displays what they’re plugged into on our Sonicwall 4060:

The WiBand connection is from a wireless ISP, connecting to a basestation about 1.5KM away.

Problem

There is a client of ours across the street who is trying to access a website who’s DNS entry refers to the X3 interface provided by a Shaw IP address. They receive a strange “Oops, we could not reach that website” error page within Internet Explorer.

I did an nslookup to make sure the DNS A record for the site was still correct, which it was. I used our external dial-up line to ensure that the site was up and available, which it was.

Based on this, I suggested to my company contact dealing with the client that perhaps they are using a custom DNS provider who has an incorrect A record for our site, who is providing that custom error page. I then forget about the issue.

The next day I get a call from the client’s IT department that the problem still exists. We run through some DNS troubleshooting, and determine that site is getting the right IP, but still getting the custom error page.

I decide to check the error logs on my firewall, and the only thing of note is an “IP Spoof Detected” error. After asking what the source IP is from the problem site, it is confirmed that its the same IP as the ‘spoof’.

The client site has this IP address (close enough):

192.168.146.9/255.255.255.192

Alarm bells start going off as I realize this is very similar to our WiBand IP on X2. Our IP for that link is (changed for privacy):
192.168.146.26/255.255.255.192

Turns out the client across the street from us is also using WiBand for an ISP, and we’re connecting to the same basestation, in the same subnet.

The HTTP request is coming in on X3, but the response can’t leave X3 destined for the client IP, since that range is on X2. So our firewall drops the packet.

Solution

Our current work-around is a static route that forces the return traffic out the correct interface. It looks a little like this:

Source Destination Service Gateway Interface

Any Client IP HTTP(all) Shaw Gateway IP X3

I had the gateway on this route originally set to OUR Shaw IP, but this was incorrect.

I suppose next step is to find out why WiBand has us on the same subnet, and whether they could use VLAN’s or something else to segregate us. It’s a little disappointing that we will be the guinea pigs for this, as I would have thought an ISP would have resolved these type of issues by now.

IMF Archive Manager for Exchange 2003

November 19, 2010January 11, 2011 Jeff Miles Leave a comment

Using blacklists for spam protection in Exchange 2003 cuts down a lot of spam for my company. However, we decided to enable IMF to do even better. However, it is imperative these caught messages get monitored for false positives. We’re small enough that monitoring the IMF archive is reasonable, but it wasn’t immediately apparent how to do this.
Luckily I found this tool: http://imfam.codeplex.com/ (IMF Archive Manager)

Setup

To begin, you want to make sure the your IMF settings are set to Archive:

By default this archive location is:

%ExchangeInstallPath%\Exchsrvr\Mailroot\vsi 1\UceArchive

However, you can change that location by modifying this registry value:

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\ContentFilter\ArchiveDir

Once you’ve found or set your archive location, open IMF Manager on your client computer, and click Settings > Archive Folder:

Set this to your archive location, and you should see it populated with the IMF messages. This gives you a safe way to view the spam and identify false positives.

Dealing with False Positives

Identifying false positives isn’t very helpful if you can’t do anything with them. What I’ve done to solve this problem is created a Windows share of the IMF Archive folder, and then using IMF Archive Manager, delete all the spam leaving only false positives. I then open the shared folder, and copy the .eml files out:

Once you have an .eml file, you may need to re-configure Outlook 2003 or Outlook 2007 to natively open them.

Office 2003:

http://support.microsoft.com/kb/967346

Office 2007

http://support.microsoft.com/kb/956693

Office 2010 appears to open these files properly.

Recover Hard Deleted Items in Exchange 2003

November 19, 2010January 11, 2011 Jeff Miles Leave a comment

This information applies to at least Exchange 2003; I can’t verify any newer versions.

Sometimes an item in Exchange has been perminently deleted, and doesn’t show up in “recover deleted items”.

You can find these items through the OWA interface, if you have it enabled.

Paste this into IE, filling in the server name and user alias.

https://server_name/exchange/user_name/inbox/?cmd=showdeleted

This will show different results than what you would typically see using “Recover Deleted Items” from within Outlook.

Windows 7 Jumplist empty or slow to respond

November 15, 2010November 16, 2010 Jeff Miles 5 Comments

Another post that is slightly related to our Symantec Endpoint Protection (SEP) testing; on our Windows 7 machines, we’ve found that with SEP installed and enabled, the jumplists for all programs are drastically slower to appear.

As soon as the antivirus auto-protect is disabled, performance returns to immediate. This slowdown was most notable on Windows Explorer jumplists, however it also affected Microsoft Office and other programs.

I eventually found a solution, related to an obscure location for the jump list cache.

%AppData%\Microsoft\Windows\Recent\AutomaticDestinations

This folder contains a cache of the Jumplist entries. To fix the issue for Windows Explorer, find the entry that begins with:

1b4dd67f29cb1962

And delete it.

Then navigate here:

%AppData%\Microsoft\Windows\Recent\CustomDestinations

And do the same thing; delete the file that starts with:

1b4dd67f29cb1962

After this you will need to re-pin any items you previously had pinned for that application.

This will only resolve the problem for Windows Explorer; you may have to do some trial and error to find the appropriate cache to delete for any other programs.

Symantec Endpoint Protection & IE9

November 15, 2010November 16, 2010 Jeff Miles Leave a comment

We’re currently testing the latest release of Symantec Endpoint Protection (SEP) 11 MR6a, to replace the Symantec Corporate Antivirus 10.1 that we’re currently using. During this testing, we’ve found a bug that is only mentioned a few other places online.

If you have SEP11 installed on a computer with the Internet Explorer 9 beta, it will not receive definition updates from the management server. I haven’t heard of a solution to this problem yet.

The work-around that we’ve done is to create a new Location within the management server whose membership filter the computer name or IP of the IE9 beta participants. Then we assign a new LiveUpdate policy to that location, which forces those computers to use LiveUpdate for definitions, instead of the management server.

Hopefully this issue is fixed before IE9 hits release.