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.
Ruckus does an amazing job finding traffic to be QoS’d, and using a suite of tools to make sure that traffic is delivered as quickly and reliably as possible. They do this with what they call Smartcast. Smart cast is a group of features:
We were marking our VOIP/Video packets with DSCP values ef and af41 respectively. Ruckus looks at the ToS value instead of DSCP. I logged into the ZD through CLI and could see what was manually being added to the software queues. See below:
From here you can see the ToS classifications in Hex, and the Heuristics used to detect voice/video/data. I wanted to make 100% sure that my video was in the video queue. So I changed from DSCP af41 Decimal 34 to hex 0x88. To add this I just checked to see what the video was already marked for, and added 0x88 (My DSCP value).
As you can see after adding the 0x88 value to the queue all classifications show up. You could also modify your Heuristic interval from here as well.
Ruckus has lots of documentation on all their greatness and features including some great youtube videos.
More info on Smartcast:
In 5.0 Fortinet offers the option of using DDNS to register a DNS name if you have a dynamic address. This is great for remote offices who might need a IPSEC site-to-site tunnel to a corporate office. No static IPs! Its very easy to configure and free if you use Fortinets own service. You can configure this under System – Network – DNS.
Notice that this is set to only port15. What if you had two dynamic interfaces from two separate ISPs and wanted to create redundancy for your VPN? From the GUI you cannot. CLI to the rescue! Fortinet has a lot more options for this in CLI. You can create other DDNS interfaces and use more services then just fortiddns. For instance I use dyndns and could actually use my account with dnsalias.com.
Check out these options:
So from here you can select any interface to monitor or use any of those ddns-servers – crazy this is not in the GUI!
One thing to note is that when multiple DDNS entries are created only one shows up in the GUI.
Within the Cisco ASA you can capture packets within the CLI or ASDM. Here I will be demonstrating the CLI Method. You can find the ASDM method under – wizards – packet capture
The other day I had a botnet on a internal client that would start communicating at strange hours, so it was hard to get info without a syslog server. I created a ACL within the ASA with the destination IP and then started a capture to get all traffic going to that destination. Below are the steps
1. Create ACL to grab traffic you want to capture
access-list Botnet ext per ip any host x.x.x.x
2. Start the capture to grab the ACL traffic
capture Botnet-traffic interface inside access-list Botnet
3. Check the traffic capture:
show capture Botnet-traffic
All commands show below:
config t
access-list Botnet ext per ip any host x.x.x.x
capture Botnet-traffic interface inside access-list Botnet
show capture Botnet-traffic
Recent Comments