Letters to the Editor - 29 Aug 2001

Readers share their thoughts on ports for VPN and life without NetBIOS.

Readers

August 28, 2001

3 Min Read
ITPro Today logo in a gray background | ITPro Today

Ports for VPN
Unless I missed something in the context, I think the answer in Sean Daily's Tricks & Traps: "Daily Answers" (June 2001) to the question about VPNs and firewalls might work only under certain circumstances. Sean says that for Layer 2 Tunneling Protocol (L2TP) VPN connections, you need to open UDP port 500 for Internet Key Exchange (IKE) traffic and UDP port 1701 for L2TP traffic. If you're using IKE, presumably you're negotiating some sort of IP Security (IPSec) encapsulation, meaning that you'll need to open IP 50 (Encapsulating Security Payload—ESP) or IP 51 (Authentication Header—AH) unless you're not implementing any IPSec, in which case you don't need to pass IKE. If you're using IPSec, then the L2TP package is hidden within the IPSec package, so you don't really need to open UDP 1701. We open only UDP 500 and IP 50, for example.

—Jeffrey Basista
[email protected]

You're right: My answer applies only in specific situations—when the RRAS VPN server is in front of, rather than behind, the firewall. When you use IPSec for encryption, the L2TP UDP port traffic is encrypted as an IPSec ESP payload, so the firewall in this case (the VPN server is behind the firewall) needs to be opened only for UDP port 500 (IKE) and IP Protocol ID 50 (ESP), as you mentioned. My original answer was correct for situations in which the VPN server is outside the firewall and you're implementing a firewall by configuring packet filters on the RRAS server (i.e., dropping all traffic except that necessary for L2TP connections). In that case, you need to open for L2TP over IPSec only UDP port 500 and UDP port 1701. Allowing IP Protocol ID 50 (ESP) won't be necessary because the RRAS filters are applied after the IPSec module of TCP/IP removes the ESP header.

—Sean Daily

Life Without NetBIOS
Mark Minasi's Inside Out: "Life Without NetBIOS" (August 2001) was a fascinating column, but in the end the author fails to deliver some important information. What services depend on NetBIOS? I would love to kill NetBIOS on my whole network, but I don't know what will quit working as a consequence. Some Windows 9x machine somewhere in my organization will always need access to the network. How can I get basic network functionality for those machines? Last, Mark says, "You can use DHCP to disable NetBT on a system, but that process requires a fairly lengthy explanation, so I'll leave it for another day." No fair—give up the goods. This was an excellent column except that it needed to be about a page longer.

—David H. Lynch Jr.
[email protected]

In general, any service written for Windows NT 4.0 uses NetBIOS. Figure that anything built before 2000 needs NetBIOS except for basic Internet services such as SMTP, HTTP, FTP, and so on. As for getting basic network functionality for Win9x machines, unless you want to make all your file servers FTP servers, I don't see how an NT, Windows Me, or Win9x box would be able to access a file share on a non—NetBIOS over TCP/IP (NetBT) box.

And now I'll address using DHCP to disable NetBT. In DHCP, the trick is to use advanced scope options with user and vendor class extensions. From the Start menu, select Programs, Administrative Tools, Computer Management. Expand the Services and Applications item. Expand DHCP. Expand the scope you want to configure and select Scope Options. From the Action menu, select Configure Options. Select the Advanced tab. Set Vendor class to Microsoft Options or Microsoft Windows 2000 Options. Set user class to Default User Class. Choose Microsoft Disable NetBIOS Option. Set this option's numerical value to 2.

—Mark Minasi

OOPS
In Ctrl+Alt+Del: "We're Watching You" (July 2001), Figure 3 shows a screen shot that Windows 2000 Magazine attributed to Tools4ever's SpaceGuard. Representatives of Tools4ever claim that this screen shot didn't come from SpaceGuard, and we have been unable to reach the reader who submitted this item to verify the screen shot. We regret any inconvenience that this error might have caused.

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like