I was asked to find out how to spare an engineer the trip to his customer abroad only to do a five minute's upload job to a device that was talking TCP/IP. The device was on a subnet that had a VPN site-to-site connection to his office, however, the device did not have a routing entry making it aware of the subnet on the other side of the VPN tunnel.
Because of limitations to the device, configuring the needed routing entry into the device was not an option, even if we were able to telnet into the device from a Remote Desktop session on a Windows computer on the same subnet.
Solution: The solution was to create a simple PPTP VPN dial-in access on that Windows computer, so that the engineer's computer could receive an IP from the same IP pool as the device he wanted to control. Yes, it meant creating a PPTP VPN tunnel back through the established site-to-site VPN tunnel, but it would work.
Caveat: Only trouble was, it didn't. Setting up a simple Routing and Remote Access server in Windows Server 2003 is a simple task, still, it just did not work. What I found after scratching my head pretty sore was that the firewall in the site-to-site VPN device on my side (the one responsible for the "outer" tunnel) was blocking all traffic that did not originate from my subnet. The PPTP GRE protocol packets from the remote site did not look like they were talking to established traffic from my side, and hence was blocked, effectively blocking the creation of the PPTP tunnel within the site-to-site tunnel. To make it work, I had to open the firewall on the site-to-site device to allow full traffic flow while running the PPTP tunnel.
After that it worked, but was quite slow, probably due to the double encrypted, double tunneled packets.
Thursday, October 11, 2007
Slow Windows login (Gone in 60 seconds)
I decided that today was going to be the day I solved why my Windows XP always takes excactly 1 minute to "think" after clicking the login button and until it shows my Windows desktop and starts to load traybar applications etc..
First try was to minimize the profile size. If I were using a roaming profile this would certainly have helped, because the size of my profile folders were around 800 megs. I moved out the Thunderbird mail profile and sqeezed some more unnecessary bits out of it and came down to around 150 megs. Still a bit much, but the change in login speed should be noticeable. Result: Nada. Still took a minute to think it all over before letting me in.
The solution was right under my nose the whole time - actually letting me know upon each login that "some network drives could not reconnect". Of course not - I use my laptop on different places and I am not always connected to those network drives. I just find it convenient to have them all ready for use in explorer. No longer. I disconnected them and did a login, and the whole minute's wait was gone.
The login was no longer "Gone in 60 seconds" - the 60 seconds were gone. :)
I just wonder where I can find the time to fetch my coffee now...
First try was to minimize the profile size. If I were using a roaming profile this would certainly have helped, because the size of my profile folders were around 800 megs. I moved out the Thunderbird mail profile and sqeezed some more unnecessary bits out of it and came down to around 150 megs. Still a bit much, but the change in login speed should be noticeable. Result: Nada. Still took a minute to think it all over before letting me in.
The solution was right under my nose the whole time - actually letting me know upon each login that "some network drives could not reconnect". Of course not - I use my laptop on different places and I am not always connected to those network drives. I just find it convenient to have them all ready for use in explorer. No longer. I disconnected them and did a login, and the whole minute's wait was gone.
The login was no longer "Gone in 60 seconds" - the 60 seconds were gone. :)
I just wonder where I can find the time to fetch my coffee now...
Friday, September 7, 2007
Narrow-masked site-to-site VPN caveats on a Checkpoint device
I consider myself to be relatively experienced in setting up site-to-site (LAN to LAN) VPN tunnels, and to pinpoint what is wrong if the tunnel does not come up, but working today with a technician on the other side of the Atlantic to set up such a link turned out to be a challenge.
We had agreed on all cryptographic parameters, on what private subnet to be used on each side of the tunnel and of course the preshared key. The guy in the other end seemed experienced enough, but going over and in a structural manner fiddling each parameter to try to find a match did not give the break. The scenario was quite funny:
Scenario: Tunnel clears phase 1 of the negotiation, meaning that the preshared key and the IKE parameters are a match on both sides. In phase two, some discrepancy makes a "no proposal chosen" message appear in the logs on the Checkpoint.
Strange: Even though the tunnel did not come up on the Checkpoint side, it did on mine. I was able to ping devices on his side, but he was not able to ping my side.
Solution: After having tested virtually everything, the guy on the other side mentions that his device has defined a class B private network on the interface. The tunnel definition, however, was to be for a much narrower range, a 29 bits mask (255.255.255.248). Although it would be shooting sparrows with a cannon, we broadened the tunnel definition to match his device's network interface, and voilla, it worked! It seems to be a limitation of the Checkpoint device this guy was using (or a limitation of knowledge on how to configure this device correctly) - I have without trouble set up dozens of other links with a narrower tunnel IP range than what the device is running on its network interface.
Caution: If someone else experiencing a similar problem is reading this, my advice would be first to check any firewall that might be blocking traffic (it was my first guess). If you can temporarily isolate vulnerable parts of your network while testing your new tunnel, I would first bring up the tunnel with the firewall completely off.
We had agreed on all cryptographic parameters, on what private subnet to be used on each side of the tunnel and of course the preshared key. The guy in the other end seemed experienced enough, but going over and in a structural manner fiddling each parameter to try to find a match did not give the break. The scenario was quite funny:
Scenario: Tunnel clears phase 1 of the negotiation, meaning that the preshared key and the IKE parameters are a match on both sides. In phase two, some discrepancy makes a "no proposal chosen" message appear in the logs on the Checkpoint.
Strange: Even though the tunnel did not come up on the Checkpoint side, it did on mine. I was able to ping devices on his side, but he was not able to ping my side.
Solution: After having tested virtually everything, the guy on the other side mentions that his device has defined a class B private network on the interface. The tunnel definition, however, was to be for a much narrower range, a 29 bits mask (255.255.255.248). Although it would be shooting sparrows with a cannon, we broadened the tunnel definition to match his device's network interface, and voilla, it worked! It seems to be a limitation of the Checkpoint device this guy was using (or a limitation of knowledge on how to configure this device correctly) - I have without trouble set up dozens of other links with a narrower tunnel IP range than what the device is running on its network interface.
Caution: If someone else experiencing a similar problem is reading this, my advice would be first to check any firewall that might be blocking traffic (it was my first guess). If you can temporarily isolate vulnerable parts of your network while testing your new tunnel, I would first bring up the tunnel with the firewall completely off.
Subscribe to:
Posts (Atom)