Friday, October 3, 2008

Tunnelling a subset of a routed subnet on a Juniper Netscreen

(This post assumes that you have a general knowledge of setting up a Juniper device for VPN tunnelling).

The following chain represents my setup:

(internet) --- [Internet router] --- [Juniper Netscreen] ---(LAN)--- [Router] ---(General 10.0.0.0/24 network segment)---

On the Juniper device*, this means that a route of 10.0.0.0/8 is pointing towards Router. In addition, a default route is pointing towards Internet router, allowing for comptuers on LAN (which has the Juniper device LAN IP set as their default gateway) to reach both the 10.x.x.x computers behind Router and to reach internet destinations.

Now I want to create a VPN tunnel over the internet to some other place, tunnelling to that place's internal network 10.10.10.0/24.

Problem: Because of the route of 10.0.0.0/8 is pointing towards [Router], even packets destined for 10.10.10.x-addresses are routed that way. Normally on a Netscreen device, having set up policies for the VPN traffic is enough to route through the tunnel, but routing entries seem to take presedence over policies.

Solution: Set a Metric higher than 1 (e.g. 10) for the 10.0.0.0/8 route. Then create a route of 10.10.10.0/24 pointing towards the [Internet router] IP address (this would be the same as your default gateway points to, of course a public IP address). The 10.10.10.0/24 route will by default receive a lower metric and therefore have priority over the 10.0.0.0/8 route.

Gotcha: Of course, this means that you will not be able to reach 10.10.10.x computers on the network behind Router. You literally can't have it both ways...

* I have done this on a Juniper Netscreen 5xp, but I would assume this would work on all Juniper devices, for instance the successor Juniper SSG.

Wednesday, June 11, 2008

DDE on XP/2003

Ever tried porting a DDE app to Windows XP/2003 that you know worked under Windows NT/9x? It just won't communicate. Having found the problem twice and then forgotten again, here's the note on what is (normally) wrong:

The NetDDE services (Control Panel-Administrative Tools-Services) need to be started. Set startup type to automatic (they are disabled by default), and to avoid rebooting the first time, start them as well.

Wednesday, June 4, 2008

VB.NET: Shell32 code compiled on Vista does not run on XP/2003

This was a tricky one, and I had a hard time finding a working solution. I finally found the solution by reading comments in differnt forum. I had to mix it together myself - here's the finished soup:

Situation: I had a VB.NET code that was based on VBscript code from "Hey, scripting guy" to programmatically pin shortcuts from the desktop onto the start menu. This line of code created a bit of a headache:

Dim oShell As Shell32.Shell = New Shell32.Shell
Dim oFolder As Shell32.Folder = oShell.NameSpace(0) '0 refers to user desktop

Problem: The code compiled and ran on my Vista computer, but once I moved the .exe file to a Server 2003 computer, it threw a runtime exception stating: Unable to cast COM object of type 'Shell32.ShellClass' to interface type 'Shell32.IShellDispatch5 and then the usual garble (actually, the garble did reveal the line of code in question)

Cause: The Shell32 library comes in a new version in Vista compared to XP/2003 - or that is my conception of what I could find on the subject. The problem is that under XP/2003, the Shell32.ShellClass is not casted to Shell32.IShellDispatch5, but to its predecessor, Shell32.IShellDispatch4. Now I knew the difference, but it meant that the program needs to reference the right one.

Solution: I found the two first lines of code below buried in a comment in a forum - when they replace the first line of code above, voilla: It works on all platforms (the term 'all' referring to XP, Server 2003 and Vista):

Dim ShellAppType As Type = Type.GetTypeFromProgID("Shell.Application")
Dim oShell As Object = Activator.CreateInstance(ShellAppType)
Dim oFolder As Shell32.Folder = oShell.NameSpace(0) '0 refers to user desktop

Nerds like me may be simple to please - it certainly made my day!

Wednesday, February 20, 2008

CheckPoint VPN keepalive kills the tunnel

I had the strangest experience when setting up a CheckPoint VPN device the other day. The tunnel built fine, but sometime between a few seconds and 1-2 minutes after coming up fine, it logged a "no proposal chosen" and went dead again. I researched every parameter with no luck, until I came to a checkbox on the last screen of the CheckPoint's VPN tunnel wizard stating something like "Keep this tunnel alive." Naturally I had wanted to keep the tunnel up, so I had checked it.

Funny thing, not until I cleared it again, the tunnel became rock stable. So, as long as you don't ask it to, it keeps your tunnel alive. I guess it just does not like being pushed around...

Monday, January 14, 2008

Windows Photo Gallery would not open a file on the desktop

Situation: I often use the desktop for temporary storage of images or documents I am going to throw away after a very short while. When I tried to open a JPG image on the desktop by doulbe-clicking it, there was no reaction however. Standard program for viewing images is the Vista native "Windows Photo Gallery."

Problem analysis:
  • Doubleclicking the image or rightclicking, selecting preview or open with - Windows Photo Gallery all produces the same result: Nothing
  • Doing the same on another file residing in any other folder works perfectly.
  • Moving the image file in question to any other folder makes it open like a dream. Moving it back restores the problem.
  • Rightclicking and selecting open with - also works.
  • Rightclicking and selecting open with - choose default program makes the file open in the other program you choose upon doubleclick or richtclick - preview.
Problem identification: Windows Photo Gallery has a problem opening image files residing on the desktop.

Clue: On a web forum I found a clue that it might be due to another file on the desktop being corrupt. He suggested moving all files except the image file(s) on the desktop to a folder on the desktop. Having done that, IT WORKED AGAIN! I had moved away a couple of PDFs and two internet shortcuts, that did the trick. By moving one and one file back, I was able to identify one of the internet shortcuts as being my problem:

Solution: An internet shortcut containing a very long URL (a direct pointer to an online shipment tracker) was a showstopper. Removing this shortcut from the desktop did the trick.

I figure it must be some kind of a buffer overflow issue or something.

Wednesday, January 2, 2008

Web browsing stops working; ping, skype, nslookup etc. still fine

I believe I have got another Vista hate item on my list: Every now and then, particularly after some time of heavy browsing, the web browser suddenly stops working. Ping, nslookup and Skype still works, but neither Firefox, Internet Explorer, Thunderbird or FTP (from CMD) work any longer.

Investigation: A net trace using Ethereal Wireshark reveals that using IE or Firefox, no packets are ever leaving the browsers when I try to make a request for a web page. Obviously, there's something wrong in the internal OS parts that prevent packets from ever being created. OS parts because the problem applies to both IE, Firefox, Thunderbird and FTP (and more?) - OS is what they all have in common.

Possible solution: There's a lot of rubbish advice out there on different forums and blogs that advice to reset routers, disabling firewalls etc., which does not address the problem at hand. My best clue yet is Microsoft KB937168, which describes a problem pertaining to those with ICS (internet connection sharing) enabled. I happen to have just that.

Microsoft has a rigorous process for downloading the needed update, however The Hotfix Share seems to provide what is needed (if you can afford the risk of downloading from another site than Microsoft itself).

I will update this post when I have some certainty as to whether the problem is really solved - i.e. after hours of successful browsing without any hickups.

UPDATE 14.1.08: Problem is still gone - I am terminating this as an "under research" topic, assuming that the solution is found.