Deploying Vyatta VPN server on dynamic IP.

Yes, I’m really fond of using Vyatta these days. Easy command line, not a resource-hungry system, runs in a VM,… Loving it. I do have to point out that my success with it is mostly from online tutorials and a lot of trail-and-error, as I find the official documentation is unclear about a lot of details. But ‘basic’ network stuff, like setting up a VPN server, works fine. Too bad I haven’t quite figured out yet how to use Vyatta (or any other software) as an IPv6 VPN server, so the following tutorial covers IPv4 only.

First thing to check when deploying a client-server VPN is making sure there’s no subnet overlap. Earlier experiments with VPN and a remote connection behind NAT, both in the same subnet, did not work. For this reason I migrated my own network to the 192.168.168.0/24 subnet a month ago.

Second thing is making sure a remote VPN connection is possible. I’m behind a NAT device so port forwarding is needed. I’m setting up a standard Windows PPTP VPN, which uses TCP port 1723 for control, and a GRE tunnel for the actual transport. In this case, forwarding port 1723 usually is sufficient.

Once this is done, the actual configuration of the VPN server on the Vyatta:

reggle@vyatta# set vpn pptp
[edit]
reggle@vyatta# set vpn pptp remote-access authentication mode local
[edit]
reggle@vyatta# set vpn pptp remote-access authentication local-users username reggle password 123
[edit]
reggle@vyatta# set vpn pptp remote-access client-ip-pool start 192.168.168.10
[edit]
reggle@vyatta# set vpn pptp remote-access client-ip-pool stop 192.168.168.29
[edit]
reggle@vyatta# commit

This is the minimum configuration. It configures the VPN server and allows one user to log in. You can add as many users as you like by repeating the command with the username and password, or you can configure a remote RADIUS server:

reggle@vyatta# set vpn pptp remote-access authentication mode radius
[edit]
reggle@vyatta# set vpn pptp remote-access authentication radius-server 192.168.168.5 key 456
[edit]

Also, you can define a DNS server with ‘set vpn pptp remote-access dns-servers server-1 192.168.168.2’. Don’t forget to exclude the addresses used for VPN on your network’s DHCP server to avoid duplicate IPs.

To set up a Windows 7 client computer, go to ‘Network and Sharing Center’, next ‘Set up a new connection’, and enter the details asked (type VPN, IP, username, password). Sometimes, this does not work. If this is the case, go to the VPN properties in the ‘Network Connections’ page, and under the tab ‘Security’ choose PPTP instead of Automatic for the Type of VPN.

One thing to keep in mind now is that, when dialing in from a Windows computer, by default all traffic including internet access, will flow through the VPN. You can change this on the client only: go to the VPN properties, tab ‘Networking’, select ‘Internet Protocol Version 4’ and choose ‘Properties’ again, next ‘Advanced…’, and there should be a check box ‘Use default gateway on remote network’. Unchecking it makes sure the local internet connection is used.

That enables proper VPN connectivity, but if you don’t have a business-grade internet connection like me, you’ll most likely have a dynamic IP that changes from time to time. It’s possible to bind that dynamic IP to a DNS record using a public free dynamic DNS service. I used dnsdynamic.org and registered a free subdomain of dnsdynamic.com. You can always log in on the website to change the IP to your current IP, or install an automatic updating tool. This way, you don’t have to write down your IP every time you want remote access to your home network.

How to set up an IPv6 tunnel.

In an effort to promote IPv6 a bit more, I’m going to discuss three methods to set up an IPv6 tunnel today.

But first: what is an IPv6 tunnel and why would you need it? An IPv6 tunnel is a tunnel that transports IPv6 packets over an IPv4-only network, which is useful if you, like me, have an ISP that doesn’t use IPv6 addresses yet. By setting up the tunnel you can connect your local IPv6 network with the rest of the IPv6 internet. After configuring it, you should be able to surf to the Google IPv6 site.

Before you can begin configuring, you’ll first need an IPv6 provider. I used Hurricane Electric, others prefer Sixxs. Both are free. After registering on the site, you’ll receive a /64 subnet which is yours to use, as well as some details about setting up the connection. Yes, this means you get more IPv6 addresses for free to use in your living room than there are IPv4 addresses in the entire world.

After you have received your prefix we can begin configuration. Note that you’ll also receive a tunnel prefix which is used to configure the tunnel endpoints, as well as an IPv6 DNS server (which will require a DHCPv6 server to run on the network, annoying, I know). To make things consistent over the three configurations I’ll list example values that will be used:
Local IPv6 subnet:  2001:0:0:1234::/64
Tunnel subnet: 2001:0:0:1235::/64, with ::2 on our side and ::1 on the other endpoint side.
IPv6 DNS: 2000::2000
Device IPv4 address: 192.168.0.10
Tunnel endpoint: 50.60.70.80
Gateway to ISP: 192.168.0.1

I’m going to give the configuration for three types of device/operating system: a (virtualized) Vyatta 6.1, a (virtualized) Windows Server 2008 R2, and a Cisco 2691 router in GNS3. It is also possible to configure the tunnel on other devices (even an Apple Airport), but I have not tested those. Also, the tunnel used is an ipv6ip tunnel which uses IP Protocol 41. Since I’ll be passing through a NAT device (the ISP gateway), one of the tunnel endpoints will be a private address, which will be translated by the NAT device. You may need to put the IP in DMZ to forward the tunnel properly, or in my case, to forward the ICMP keepalives properly. And finally: the tunnel endpoint does not necessarily have two ethernet interfaces: the tunnel can be send out of the interface the IPv6 subnet is on.

Vyatta
Using the Vyatta as an IPv6 endpoint works stable and throughput is good. The basic version is free and it barely uses CPU, even when virtualized and under load, which makes for a nice endpoint without the need for a dedicated device. The configuration in the Vyatta is as following:

vyatta@vyatta:~$ configure
vyatta@vyatta# edit interfaces tunnel tun0
vyatta@vyatta# set encapsulation sit
vyatta@vyatta# set local-ip 192.168.0.10
vyatta@vyatta# set remote-ip 50.60.70.80
vyatta@vyatta# set address 2001:0:0:1235::2/64
vyatta@vyatta# set description “IPv6 Tunnel”
vyatta@vyatta# exit
vyatta@vyatta# set protocols static interface-route6 ::/0 next-hop-interface tun0
vyatta@vyatta# edit interfaces ethernet eth0
vyatta@vyatta# set address 192.168.0.10/24
vyatta@vyatta# set address 2001:0:0:1234::1/64
vyatta@vyatta# set ipv6 router-advert prefix 2001:0:0:1234::/64
vyatta@vyatta# exit
vyatta@vyatta# set system gateway-address 192.168.0.1
vyatta@vyatta# commit

Unfortunately, Vyatta currently does not properly support DHCPv6, so you can’t advertise the IPv6 DNS server to hosts in the subnet. In a dual stack environment this doesn’t break anything as the hosts will query the known IPv4 DNS servers, and those respond with IPv6 addresses in their payload if needed.

Cisco IOS
I can’t configure IPv6 on my 2611 routers, apparently they don’t have enough flash memory to store the right IOS version. The 3560 I have does support it with the Advanced IP Services IOS, but I don’t have that one, so I’m really out of luck here.
Update September 18, 2011: the 3560 has IPv6 support with the IP Services IOS as the Advanced IP Services is no longer used for a 3560, but there’s no support for tunneling as it can only be done in software and puts a heavy load on the CPU.

I resort to GNS3, where I set up a router and connect it to the physical network. The configuration of the tunnel is as following:

Router#configure terminal
Router(config)#ipv6 unicast-routing
Router(config)#interface Tunnel0
Router(config-if)#description IPv6 Tunnel
Router(config-if)#no ip address
Router(config-if)#ipv6 address 2001:0:0:1235::2/64
Router(config-if)#tunnel source 192.168.0.10
Router(config-if)#tunnel destination 50.60.70.80
Router(config-if)#tunnel mode ipv6ip
Router(config-if)#exit
Router(config)#ipv6 route ::/0 Tunnel0
Router(config)#interface FastEthernet0/0
Router(config-if)#ipv6 address 2001:0:0:1234::/64 eui-64
Router(config-if)#ipv6 nd prefix 2001:0:0:1234::/64
Router(config-if)#exit
Router(config)#ip default-gateway 192.168.0.1
Router(config)#end
Router#write

Note that, just like with the Vyatta, you have to tell the router which prefix to advertise over the subnet. I was unable to properly configure DHCPv6 so all hosts could get an IPv6 DNS server, despite best efforts. Either a command is not working as expected or I am doing it wrong, so for now, it will work just like the Vyatta, with hosts querying DNS by IPv4.

Windows Server 2008 R2
Despite that this is the only one of the three devices that has a GUI, most configuration on the Windows Server will be done through the command line as well. The netsh command allows you to manipulate the IP stack in detail, as shown in the following configuration:

C:\>netsh interface teredo set state disabled
C:\>netsh interface ipv6 add v6v4tunnel IPv6Tunnel 192.168.0.10 50.60.70.80
C:\>netsh interface ipv6 add address IPv6Tunnel 2001:0:0:1235::2
C:\>netsh interface ipv6 add route ::/0 IPv6Tunnel 2001:0:0:1235::1

The first command disables the build-in Teredo in Windows, which automatically tries to create an IPv6 tunnel in case such traffic is needed. If you care about security, I would recommend this command on all your Windows 7 computers.

Next, creating a gateway for the subnet. If you go to the Network & Sharing Center, choose Change Adapter Settings, you can give the network card facing the subnet a static IPv6 address, in this case 2001:0:0:1234::1/64. The gateway should be ::, DNS server 2000::2000.

Last, we make sure all hosts receive the DNS address. This requires the DHCP role installed on the Windows Server. If present, go to Server Manager, DHCP, and configure an IPv6 scope 2001:0:0:1234::/64. Next, in the scope options, add option 23, and fill in 2000::2000. Windows accepts this and does not give any warning, but I couldn’t get this to work without rebooting after this.

So, these are three methods to get your IPv6 tunnel working. I hope it is all clear, greetings!

Update October 18, 2011: the Cisco IOS and Vyatta configuration had a missing command: you need to configure a default-gateway, otherwise it will not know where to send the tunnel! Commands updated.

Layer 2 device discovery methods.

Readers pursuing a CCNA (or higher) certification are most likely familiar with CDP: Cisco Discovery Protocol. CDP runs directly on layer 2 (without the use of IP addresses) in the network and will map neighbouring devices.

CDP works great on a Cisco-only network to find out the network topology, and makes negotiating links with Cisco IP Phones easy. Despite the name, it was never made proprietary. As such, tools exists for Linux (and if you insist on trying it, here‘s a nice guide) and several of Cisco’s competitors have IP Phones supporting CDP.

There are a lot of other vendor-implementations of the protocol, for example Extreme Discovery Protocol by Extreme Networks (of which I found something on the Wireshark wiki), but in a multi-vendor environment, the best solution is LLDP (802.1ab): Link-Layer Discovery Protocol, the vendor-neutral device discovery protocol. Cisco switches have CDP enabled by default, and LLDP disabled, but it is present. The commands for both are very similar:

Switch(config)#cdp run
Switch(config)#exit
Switch#show cdp neighbors

Switch(config)#lldp run
Switch(config)#exit
Switch#show lldp neighbors

Naturally for LLDP there are also some Linux deamons, a list of which can be found here (thanks to Wikipedia for the link). But what about Windows? That seems to be a different story: while software does exist, it’s quite simple and a full version is not free. For CDP, the best thing to use is Tallsoft’s CDP client. The free version gives the company’s website as the device name in CDP, but it’s the only version of CDP software I got to work on Windows.

For LLDP, the only software I got to work eventually was the haneWIN LLDP client. It’s a 30 day trial but works nicely, as illustrated below.

Note that I’m connected by Ethernet here, not wireless. Though my wireless gateway did forward CDP frames (as do all CDP unaware devices), it did not do so for LLDP frames, despite not advertising LLDP itself. Since the wireless gateway is provided by my ISP, I have no further control over it.

Finally, there’s one more protocol that’s commonly used to map devices on layer 2: LLTD or Link Layer Topology Discovery, a Windows proprietary protocol. It’s activated by default on Windows Vista and Windows 7, and it’s responsible for giving the visual representation in the Windows Network & Sharing Center in the Control Panel. But since it’s only available on those two Windows versions, the image will not display any Linux or Apple computers, as well as older Windows version like Windows XP. Also, it has no idea how the rest of the network looks like, so it makes assumptions based on what it believes the network should normally look like. In my case, my 3560 switch is nowhere to be found, but another switch is listed connected to a wireless access point, which is not there (though I suspect it is simply a separate representation of the build-in switchports in my wireless gateway).

So conclusion: a layer 2 device discovery protocol that works on all devices exist. I was able to get CDP running on all devices, but LLDP is a better choice given the broader support in network devices. Not surprising since this is why LLDP was created. What is surprising though, is the generally poor support for these protocols in Windows. Just one piece of software per protocol, a small monopolistic market. It seems like there never was a need for large-scale deployments of these protocols, so the market never fully developed.

Hidden feature in Windows 7: Spanning Tree!

Today I activated Wireshark on my computer’s network card. Next, I bridged my computer’s loopback adapter with my network card, to test out VRRP on virtual routers from different vendors. I never got to that, however, because I suddenly noticed STP frames being captured in Wireshark.

Since my computer is currently hooked up to a Cisco 3560 switch with all ports set to Portfast, my initial thought was that I misconfigured something on the switch, or I simply misinterpreted the whole Portfast concept. But then I noticed these frames originated from my computer’s MAC address. After checking the spanning-tree status on my switch I noticed it did no longer consider himself the root, but the computer!

The conclusion was simple: Windows participates in STP when a bridge is made between network connections. I did some Google searches but it seems that it’s something that isn’t really known as I found no useful results. The only relevant reference to this feature I found was in the Microsoft MSDN Library, and even there it’s just a line explaining the registry key to toggle the setting.

I find it positive that this is included in Windows, as it may prevent bridging loops from forming (in rare cases), but I’m left with questions. Since what version is it supported, and in which editions? I’m using Windows 7 Professional. My first guess is that it’s something new to either Vista or Windows 7, as people would have noticed this in Windows XP by now. I’m also not sure which Windows Server versions support this, but a calculated guess is that the 2008 version does. I may perform more tests later.

Either way, here you have it. I thought I’d share this information, might be useful to someone someday.

Greetings!