TravelingPacket – A blog of network musings

Vyatta offers a few remote access options – L2TP, OpenVPN SSL, PPTP. L2TP offers much more security features than PPTP. L2TP is encrypted using the IPSec Protocol, and can use 3des or AES for both authentication and data encryption, compared to PPTPs PPP encryption. Because L2TP is encapsulated within IPSEC it can be a little slower and more CPU is needed to encrypt/decrypt than PPTP.

All versions of Windows since 2000, IPHONE/Android and MAC since 10.3 support L2TP, this makes it a great option for secure remote access.

It is very simple to configure and get going within Vyatta. You can use local usernames/passwords or authenticate against radius in just a few minutes. Below is the needed settings to get it going.

l2tp {
     remote-access {
         authentication {
             mode radius
             radius-server Radius-IP {
                 key “*”
             }
         }
         client-ip-pool {
             start 192.168.200.10
             stop 192.168.200.150
         }
         ipsec-settings {
             authentication {
                 mode pre-shared-secret
                 pre-shared-secret Password
             }
         }
         outside-address “Outside address of vyatta”
         outside-nexthop “default gateway of vyatta”
     }
 }

That is the vyatta config — to actually get those commands entered in you the ones below

set vpn l2tp remote-access authentication mode ‘radius’
set vpn l2tp remote-access authentication radius-server 192.168.1.* key ‘Radius Preshared key’
set vpn l2tp remote-access client-ip-pool start ‘192.168.200.10’
set vpn l2tp remote-access client-ip-pool stop ‘192.168.200.250’
set vpn l2tp remote-access dns-servers server-1 ‘8.8.8.8’
set vpn l2tp remote-access ipsec-settings authentication mode ‘pre-shared-secret’
set vpn l2tp remote-access ipsec-settings authentication pre-shared-secret ‘Pre-Shared-key’
set vpn l2tp remote-access ipsec-settings ike-lifetime ‘3600’
set vpn l2tp remote-access outside-address ‘Ouside-interface IP’
set vpn l2tp remote-access outside-nexthop ‘Vyatta default route’

Those are the only configurations needed to configure L2TP but, IPSEC is also needed. so we have to add those commands to allow nat-t, specify our IPSEC interface (if not already done), and allow our Nat-networks. One thing to note is I added 0.0.0.0/0 for the nat allowed networks. I did this since I have people connecting from 4g hotspots , I have no clue what their internal IP will be. If you know your clients will be connecting from a RFC 1918 address, add those networks instead.

set vpn ipsec ipsec-interfaces interface ‘eth0’
set vpn ipsec nat-networks allowed-network ‘0.0.0.0/0’
set vpn ipsec nat-traversal ‘enable’

Troubleshooting:

I ran in to a few problems. I thought I would share the error messages just in case it helps.

Jan 27 12:12:48 vyatta pluto[8366]: packet from remote-ip:1011: ignoring Vendor ID payload [Vid-Initial-Contact]
Jan 27 12:12:48 vyatta pluto[8366]: packet from remote-ip:1011: ignoring Vendor ID payload [IKE CGA version 1]
Jan 27 12:12:48 vyatta pluto[8366]: packet from remote-ip:1011: initial Main Mode message received on *:500 but no connection has been authorized with policy=PSK

I could not figure out what the last message meant. After searching through my config the problem was that the outside-address configured in the L2TP config was not correct. I had mistyped on of the numbers.

I also had a problem that in the logs showed up as :
Jan 27 12:51:41 vyatta pluto[4583]: “remote-access-mac-zzz”[6] *:64916 #4: sending encrypted notification INVALID_MESSAGE_ID to *:64916
Jan 27 12:51:44 vyatta pluto[4583]: “remote-access-mac-zzz”[6] *:64916 #4: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x01000000 (perhaps this is a duplicated packet)
Jan 27 12:51:44 vyatta pluto[4583]: “remote-access-mac-zzz”[6] *:64916 #4: sending encrypted notification INVALID_MESSAGE_ID to *:64916
Jan 27 12:51:51 vyatta pluto[4583]: “remote-access-mac-zzz”[6] *:64916 #4: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x01000000 (perhaps this is a duplicated packet)
Jan 27 12:51:51 vyatta pluto[4583]: “remote-access-mac-zzz”[6] *:64916 #4: sending encrypted notification INVALID_MESSAGE_ID to*:64916

The issue was I did not have all of my remote subnets in the IPSEC nat-allowed policy. This fixed the issue. OpenVPN is supported by almost every platform now, is very secure and easy to setup. OpenVPN is the preferred method for Remote access on Vyatta.

BUG

Also, there is  a bug in version 6.6 that only allows one user to log in at a time. This can be resolved by downgrading to 6.4 and 6.5 — Hopefully Brocade fixes this issue.