Posts Tagged 'Gateway'

August 29, 2016

Setting Up OpenVPN on a SoftLayer Vyatta Device

The following is a step-by-step guide on how to utilize your SoftLayer Vyatta gateway device as your own personal VPN to access any server behind the Vyatta device with even more freedom than the SoftLayer VPN. In the following example, we will be using the built-in OpenVPN daemon that comes installed with Vyatta. This means you can upload large files to your servers that are behind the Vyatta device using the speed of your public interface, rather than trying to depend on the SoftLayer VPN’s speeds—which are throttled for management, not file transfer. You will also have more control over how your VPN behaves, which subnets your users can access, how you manage your VMware environment, and more.

What we will review in the following guide, however, are just the basics. This will give you a basic level VPN working in client/server mode and using SSL keys as authentication rather than passwords.

What you will need for this guide

  • 1 Vyatta gateway device
  • 1 Windows 7/8/10 computer or 1 Apple device running OS X 10.10+
  • 1 portable private/28 subnet that is on a VLAN already associated and routed to your Vyatta (the smallest you can order is 16 portable private IPs from the portal)
  • A little patience

OpenVPN Client/Server Implementation

The first thing you’ll need to do is to copy the easy-rsa folder to your /config/.

cp -r /usr/share/easy-rsa/ /config/easy-rsa

Then you’ll need to edit the vars file to personalize your certificates.

nano –w /config/easy-rsa/vars

...

# Increase this to 2048 if you

# are paranoid.  This will slow

# down TLS negotiation performance

# as well as the one-time DH parms

# generation process.

export KEY_SIZE=2048

 

# In how many days should the root CA key expire?

export CA_EXPIRE=3650

 

# In how many days should certificates expire?

export KEY_EXPIRE=3650

export KEY_COUNTRY="US"

export KEY_PROVINCE="TX"

export KEY_CITY="Houston"

export KEY_ORG="IBMCloud "

export KEY_EMAIL="me@us.ibm.com"

Now you’ll need to load your variables from the vars file you just modified.

cd /config/easy-rsa

source ./vars

You’ll want to run the ./clean-all to start fresh in case there is something old lingering around in the directory.

./clean-all

Now build the certificate authority files. (Just press Enter to everything.)

./build-ca

Now build the Diffie-Hellman key exchange.

./build-dh

Now build the key file for the server. (Enter to everything again, enter password if asked, and Y to both questions.)

./build-key-server my-server

Next, you’ll need to copy the certificates and keys into the /config/auth/ folder.

sudo cp /config/easy-rsa/keys/ca.crt /config/auth/

sudo cp /config/easy-rsa/keys/dh2048.pem /config/auth/

sudo cp /config/easy-rsa/keys/my-server.key /config/auth/

sudo cp /config/easy-rsa/keys/my-server.crt /config/auth/

Now you can build the key for the client and distribute it to them. Use the ./build-key to generate a certificate that will connect to the VPN without a password, using an SSL key instead.

./build-key myname

Answer all questions accordingly and be sure to answer YES to sign the certificate and when it asks you to commit.

Now copy the keys and certificates and create a configuration for the client. First, you’ll need to make the directory for the client, though, for easier tracking.

cd /config/easy-rsa/keys

mkdir myname

cp myname* myname/

cp ca.crt myname/

Next, you’ll need to create a client config that you will be using on your local machine later.

nano –w myname/myvpnserver.ovpn

client

proto tcp

remote-cert-tls server

nobind

verb 2

dev tun0

cert myname.crt

key myname.key

ca ca.crt

remote 123.45.67.89 11994

float

From your local computer, you can download the config directory directly from your Vyatta.

scp –r vyatta@123.45.67.89:/config/easy-rsa/keys/myname .

This copies the client directory to the current directory on your local machine, so make sure you are in the directory you want to store the keys in.

Setting up the OpenVPN Server

The server subnet needs to be a different subnet from your LAN; for this example, we are using a portable private/28 (16 IPs on the 10.x.x. network), because it will assign an IP from that subnet to your clients as they login, giving them access to everything behind your Vyatta. You will also notice we are setting the resolvers to the SoftLayer DNS resolvers, as well as a Google DNS resolver. This ensures that your VPN-connected users still have full Internet access, as well as internal access.

You will also see that there is a push-route added for the other private subnets behind the Vyatta device. For this example, we wanted to give the users logged-in access to more than just the subnet from which it is assigning IPs. You will need to adjust the push-route lines to fit your environment, though. 

We will also be assigning a non-standard port of 11994, due to many ISPs blocking port 1194, and changing the protocol to TCP because UDP is also blocked in many places.

set interfaces openvpn vtun0 mode server

set interfaces openvpn vtun0 server subnet 10.134.247.0/28

set interfaces openvpn vtun0 server name-server 8.8.8.8

set interfaces openvpn vtun0 server push-route 10.135.8.0/26

set interfaces openvpn vtun0 server push-route 10.134.198.80/28

set service dns forwarding listen-on vtun0

set interfaces openvpn vtun0 tls cert-file /config/auth/my-server.crt

set interfaces openvpn vtun0 tls key-file /config/auth/my-server.key

set interfaces openvpn vtun0 tls ca-cert-file /config/auth/ca.crt

set interfaces openvpn vtun0 tls dh-file /config/auth/dh2048.pem

set interfaces openvpn vtun0 local-port 11994

set interfaces openvpn vtun0 protocol tcp-passive

Now that the interface is set, we just need to open the firewall for it (note: you will need to adjust for the firewall name that you use so that it applies correctly).

set firewall name wan-local rule 40 action accept

set firewall name wan-local rule 40 destination port openvpn

set firewall name wan-local rule 40 protocol tcp

commit

save

That’s it! Your OpenVPN is set up on the Vyatta device. Now it’s time to install OpenVPN GUI on Windows or Tunnellblick on OS X.

Install either program as directed by the installer, then simply open the .ovpn file you downloaded earlier via scp with that program and it will connect. If you are on OS X, the default firewall will block ping requests from your Vyatta and a few other things. For my personal use, I used Murus Lite and loaded the Murus Predefined Configuration to make it work correctly.  Windows may need the Windows firewall adjusted to allow traffic to pass on TCP 11994 as well.

Congratulations! You now have a working OpenVPN setup connecting you to your SoftLayer environment. You can test it by pinging one of the servers behind your Vyatta on the private network.

If you need to create more than one client key, simply follow these steps.

source ./vars

./build-key newclient

cd /config/easy-rsa/keys

mkdir newclient

cp newclient* newclient/

cp ca.crt newclient/

Then run the same scp command from earlier (but fix the path to the newclient) and you're set!

-Shawn

February 3, 2016

Use TShark to see what traffic is passing through your gateway

Many of SoftLayer’s solutions make excellent use of the Brocade vRouter (Vyatta) dedicated security appliance. It’s a true network gateway, router, and firewall for your servers in a SoftLayer data center. It’s also an invaluable trouble-shooting tool should you have a connectivity issue or just want to take a gander at your network traffic. Built into vRouter’s command line and available to you, is a full-fledged terminal-based Wireshark command line implementation—TShark.

TShark is fully implemented in vRouter. If you’re already familiar with using TShark, you know you can call it from the terminal in either configuration or operational mode.  You accomplish this by prefacing a command with sudo; making the full command sudo tshark – flags.

tshark graphic

For those of us less versed in the intricacies of Wireshark and its command line cousin, here are a couple of useful examples to help you out.

One common flag I use in nearly every capture is –i (and as a side note, for those coming from a Microsoft Windows background, the flags are case sensitive). -i is a specific interface on which to capture traffic and immediately helps to cut down on the amount of information unrelated to the problem at hand. If you don’t set this flag, the capture will default to “the first non-loopback address;” or in the case of vRouter on SoftLayer, Bond0. Additionally, if you want to trace a packet and reply, you can set –i any to watch or capture traffic through all the interfaces on the device.

The second flag that I nearly always use to define a capture filter is –f, which defines a filter to match traffic against. The only traffic that matches this pattern will be captured. The filter uses the standard Wireshark syntax. Again, if you’re familiar with Wireshark, you can go nuts; but here are a few of the common filters I frequently use to help you get started:

  • host 8.8.8.8 will match any traffic to or from the specified host. In this case, the venerable Google DNS servers. 
  • net 8.8.8.0/24 works just like host, but for the entire network specified, in case you don’t know the exact host address you are looking for.
  • dst and src are useful if you want to drill down to a specific flow or want to look at just the incoming or outgoing traffic. These filters are usually paired with a host or net to match against.
  • port lets you specify a port to capture traffic, like host and net. Used by itself, port will match both source and destination port. In the case of well-known services, you can also define the port by the common name, i.e., dns.  

One final cool trick with the –f filter is the and and the negation not. They let you combine search terms and specifically exclude traffic in order to create a very finely tuned capture for your needs.

If you want to capture to a file to share with a team or to plug into more advanced analysis tools on another system, the –w flag is your friend. Without -w, the file will behave like a tcpdump and the output will appear in your terminal session. If you want to load the file into Wireshark or another packet analyzer tool you should make sure to add the –F flag to specify the file format. Here is an example:

Vyatta# sudo tshark –i Bond0 –w testcap.pcap –F pcap –f ‘src 10.128.3.5 and not port 80’

The command will capture on Bond0 and output the capture to a .pcap file called testcap.pcap in the root directory of the file system. It will match only traffic on bond0 from 10.128.3.5 that is not source or destination port 22. While that is a bit of a mouthful to explain, it does capture a very well defined stream! 

Here is one more example:

Vyatta#sudo tshark –I any –f ‘host 10.145.23.4 and not ssh’

This command will capture traffic to the terminal that is to or from the specified IP (10.145.23.4) that is not SSH. I frequently use this filter, or one a lot like it, when I am SSHed into a host and want to get a more general idea of what it is doing on the network. I don’t care about ssh because I know the cause of that traffic (me!), but I want to know anything else that’s going to or from the host.

This is all very much the tip of the iceberg; you can find a lot more information at the TShark main page. Hopefully these tips help out next time you want to see just what traffic is passing through your gateway.

- Jeff 

 

October 14, 2013

Product Spotlight: Vyatta Network Gateway Appliance

In the wake of our recent Vyatta network gateway appliance product launch, I thought I'd address some of the most common questions customers have asked me about the new offering. With inquiries spanning the spectrum from broad and general to detailed and specific, I might not be able to cover everything in this blog post, but at the very least, it should give a little more context for our new network gateway offering.

To begin, let's explore the simplest question I've been asked: "What is a network gateway?" A network gateway provides tools to manage traffic into and out of one or more VLANs (Virtual Local Area Networks). The network gateway serves a customer-configurable routing device that sits in front of designated VLANs. The servers in those VLANs route through the network gateway appliance as their first hop instead of Front-end Customer Routers (FCR) or Back-end Customer Routers (BCR). From an infrastructure perspective, SoftLayer's network gateway offering consists of a single server, and in the future, the offering will be expanded to multi-server configurations to support high availability needs and larger clustered configurations.

The general function of a network gateway may seem a little abstract, so let's look at a couple real world use cases to see how you can put that functionality to work in your own cloud environment.

Example 1: Complex Traffic Management
You have a multi-server cloud environment and a complex set of firewall rules that allow certain types of traffic to certain servers from specific addresses. Without a network gateway, you would need to configure multiple hardware and software firewalls throughout your topology and maintain multiple rules sets, but with the network gateway appliance, you streamline your configuration into a single point of control on both the public and private networks.

After you order a gateway appliance in the SoftLayer portal and configure which VLANs route through the appliance, the process of configuring the device is simple: You define your production, development and QA environments with distinct traffic rules, and the network gateway handles the traffic segmentation. If you wanted to create your own VPN to connect your hosted environment to your office or in-house data center, that configuration is quick and easy as well. The high-touch challenge of managing several sets of network rules across multiple devices is simplified and streamlined.

Example 2: Creating a Static NAT
You want to create a static NAT (Network Address Translation) so that you can direct traffic through a public IP address to an internal IP address. With the IPv4 address pool dwindling and new allocations being harder to come by, this configuration is becoming extremely popular to accommodate users who can't yet reach IPv6 addresses. This challenge would normally require a significant level of effort of even the most seasoned systems administrator, but with the gateway appliance, it's a painless process.

In addition to the IPv4 address-saving benefits, your static NAT adds a layer of protection for your internal web servers from the public network, and as we discussed in the first example, your gateway device also serves as a single configuration point for both inbound and outbound firewall rules.

If you have complex network-related needs, and you want granular control of the traffic to and from your servers, a gateway appliance might be the perfect tool for you. You get the control you want and save yourself a significant amount of time and effort configuring and tweaking your environment on-the-fly. You can terminate IPSec VPN tunnels, execute your own network address translation, and run diagnostic commands such as traffic monitoring (tcpdump) on your global environment. And in addition to that, your gateway serves as a single point of contact to configure sophisticated firewall rules!

If you want to learn more about the gateway appliance, check out KnowledgeLayer or contact our friendly sales team directly with your questions: sales@softlayer.com

-Ben

Subscribe to gateway