While testing  the new Vyatta Software Router I came up with the wish to use it's routing and VPN functionality and build myself a defined gateway into BlackVPNs Service. Default configurations failed for numerous reasons.

While configuring the devices I figured out that some stuff isn't that easy as I thought. Mainly, there are two issues:

1. Vyatta doesn't support the --auth-user-pass mechanism of OpenVPN and required me to configure a TLS certificate and key for authentication. Unfortunately BlackVPN doesn't use certificates for authentication, just plain username / password.
2. There is a bug in the currently used version of OpenVPN on the Vyatta (OpenVPN 2.1_rc21, Vyatta Code Version: 6.1) which prevents OpenVPN to get information about the default gateway if it's not a plain Ethernet interface, i.e. a PPPoE, 3G, or similar. Therefore it can't change the default Gateway to the VPN once it's up. Basically this is what I want (i.e. Split Tunneling), but it breaks the whole communication. See here for more information about this bug.

OK, so here is a guide on how to configure what I (and maybe you as well) want.

Enable --auth-user-pass

As mentioned, the Vyatta code requires you to configure a TLS certificate and key for authentication, but BlackVPN is using Username / Password. The problem is that if you don't configure it, the "Code-Checking" is moaning about an invalid config and doesn't let you commit your configuration.

In order to get around this you need to make some changes to the Vyatta code itself (call it hacking, but it's really harmless, as it's just code checking)

You need to edit the file /opt/vyatta/share/perl5/Vyatta/OpenVPN/Config.pm and comment out the lines 478 to 488 in order to get rid of the Vyatta TLS certificate and key checking. Make it look like this:

# return (undef, 'Must specify "tls cert-file"')
#  if (!defined($self->{_tls_cert}));
# return (undef, "Specified cert-file \"$self->{_tls_cert}\" is not valid")
# if (! -r $self->{_tls_cert});
# $cmd .= " --cert $self->{_tls_cert}";
   
# return (undef, 'Must specify "tls key-file"')
# if (!defined($self->{_tls_key}));
# return (undef, "Specified key-file \"$self->{_tls_key}\" is not valid")
# if (! -r $self->{_tls_key});
# $cmd .= " --key $self->{_tls_key}"; 

Configuring the OpenVPN Part

As said, officially Vyatta doesn't support --auth-user-pass but luckily they do support openvpn-options which allows us to handover some required options to openvpn. After fiddling around a couple of days, I finally found the right stuff.

interfaces {
openvpn vtun0 {
        mode client
        openvpn-option "--auth-user-pass /home/vyatta/pw.txt --comp-lzo --persist-key --persist-tun --nobind --pull --cipher AES-256-CBC --verb 3 --tls-auth /home/vyatta/black_ta.key 1 --auth-retry nointeract --script-security 2 --ns-cert-type server --ca /home/vyatta/black_ca.crt --tls-remote server"
        remote-host vpn.blackvpn.com
        remote-port 1194
        replace-default-route {
        }
        tls {
            ca-cert-file /home/vyatta/black_ca.crt
        }

A couple of notes here:

• the Option --auth-user-pass /home/vyatta/pw.txt  enables the Username / Password authentication. Specifying a textfile with username and password makes sure the VPN is setup all the times without requiering you to enter Username / Password. Just create that file and put your username in the first and your password in the second line.
• The files for --tls-auth and --ca must be copied to the vyatta box in advance (you can use scp to do that. In case you have used PPTP with openVPN so far or don't know, where these files are on your box, you can download them here. Don't worry that the downloaded file is referring to Mac OS X, you just want the files in the "ssl" directory.
• Very important: the option replace-default-route. Even though it doesn't replace the default route (see above, it's a bug in OpenVPN), if it's missing you get the tunnel up bot no traffic though.

If you think you're done here ..... sorry, you're not.

Setting the routes

As said above, I don't want to route every traffic through the tunnel, instead I want just the defined traffic to go through the tunnel, the rest should enter the Internet locally. In order to do that you need to set some routing entries. in the following example I route the complete /24 Network where the Pandora Server are in through the tunnel

protocols {
    static {
        interface-route 208.85.40.0/24 {
            next-hop-interface vtun0 {
            }
        }

Keep in mind that the config we applied for the OpenVPN vtun0 Interface should redirect everything but doesn't because of the bug. I have currently no idea what happens when this bug is solved, you might need to work with static floating routes then, but we'll see.

If you think you're done now .... sorry mate, still not.

Configuring the NAT

you'll probably have some masquerade Nat'ing in place. As this is DNAT, it takes place before the routing. With your standard config the VPN engine is therefore unable to make the descission whether traffic should flow though the tunnel or not. So, you need to expand your NAT rules like this:

nat {
        rule 8 {
            destination {
                address 208.85.40.0/24
            }
            outbound-interface vtun0
            source {
                address 192.168.100.0/24
            }
            type masquerade
        }
        rule 10 {
            outbound-interface pppoe1
            protocol all
            source {
                address 192.168.100.0/24
            }
            type masquerade
        }

Rule 8 does the NAT for the traffic we want to go through the tunnel, rule 10 (keep in mind, the rule processing is from the top to the bottom, so rule numbers do matter) does the default NAT for Traffic leaving your network locally.

You think you're done now ..... Yes you are, it should work fine now.

Not all of this came out of my own head. Credits should go to Cartman from the Vyatta.org forum and krzie out of the Vyatta IRC Channel.