Sunday, March 29, 2015

Cisco – Router as a DNS Server

As many didn’t know (me included) you can configure cisco router as DNS server.

A cisco router can:

  • Reply to requests for locally defined DNS entries.
  • Forward the request the public DNS servers (max 6)

In the cenario bellow we are going setup and test this.

Topology2

 

Configs

-- R1 --

interface FastEthernet0/0
description *** LAN ***
ip address 192.168.1.254 255.255.255.0
no shutdown

interface FastEthernet0/1
description *** WAN ***
ip address 200.0.0.2 255.255.255.252
no shutdown
 
ip route 0.0.0.0 0.0.0.0 200.0.0.1 name DefaultRoute
 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Enable the router as a DNS server
! and domain lookup on the router
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ip dns server
ip domain-lookup

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Public name-servers, for the router to query
! the names it doesn't know
! Maximum 6x DNS servers
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ip name-server 4.2.2.5
ip name-server 4.2.2.6

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Local DNS Entries
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ip host PC1 192.168.1.1
ip host PC2 192.168.1.2
ip host PC3 192.168.1.3

The big secret here is the “ip dns server”, because the rest of the config you could have it to solve name locally on the router.

With the “ip dns server” you extend the router’s local name resolution, to the hosts on the network.

 

-- PC1 --

PCx

The PCs on my topology are actually routers so here is my config:

-- PC1 (Router) --
interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 192.168.1.254 name GW

ip domain-lookup
ip name-server 192.168.1.254


-- PC2 (Router) --
interface FastEthernet0/0
ip address 192.168.1.2 255.255.255.0
no shutdown
 
ip route 0.0.0.0 0.0.0.0 192.168.1.254 name GW

ip domain-lookup
ip name-server 192.168.1.254


-- PC3 (Router) --
interface FastEthernet0/0
ip address 192.168.1.3 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 192.168.1.254 name GW

ip domain-lookup
ip name-server 192.168.1.254

 

Tests

-- Test the Local Entries for The PCs on the LAN --

PC1#ping PC2
Translating "PC2"...domain server (192.168.1.254) [OK]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms

PC1#ping PC3
Translating "PC3"...domain server (192.168.1.254) [OK]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/5 ms
PC1#

-- Test Forwarding Request to Public DNS Servers--

PC1#ping www.google.com

Translating "www.google.com"...domain server (192.168.1.254) [OK]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 216.58.208.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/69/84 ms

 

Related Links:

Monday, March 2, 2015

Cisco IOS on UNIX (IOU) – On GNS3 v1.x

Today I’m going to discuss How to install and configure Cisco IOU in GNS3-1.2.1. In this way you can emulate Cisco Switch in GNS3. This article explains to get a working layer 2 switch in GNS3-1.1. Cisco IOS on UNIX (IOU) is a fully working version of IOS that runs UNIX/LINUX platform. Cisco IOS on UNIX is intended for Cisco employees for research and experiments. Distribution of IOU images to customers or external persons is strictly prohibited.

Table of Contents

  1. Tools required
  2. Import GNS3 IOU VM.ova
  3. Uploading IOU image to UNIX
  4. GNS3 Local and Remote Server
  5. IOS on UNIX Configuration for GNS3

Tools required

  1. GNS3-1.2.1
  2. Oracle VirtualBox
  3. GNS3 IOU VM.ova:- Is the Virtual UNIX platform to run IOU image. It is a virtual box OVA file.
  4. IOU image: IOU image is intended to use only for Cisco employees, distribution of IOU is strictly prohibited. Please don’t ask me! Google is your friend always.
  5. iourc.txt file: Is the license of Cisco IOU image. I have no privilege to provide it publically, but I found a discussion related to it here. It may help you.

 

Step 1: Import GNS3 IOU VM.ova

Import GNS3 IOU VM.ova to VirtualBox.

1.png

Go to Settings → Network → Adapter 1. Make sure it is attached to Host-only Adapter with name VirtualBox Host-Only Ethernet Adapter. Then click OK.

Start the GNS3 IOU VM, and login with following credentials.

  • User name : root
  • Password  : cisco

 

Step 2: Configuring the GNS3 IOU VM Ethernet Adapter

First define the IP of the eth0 interface on GNS3 IOU VM:

nano /etc/network/interfaces

image

save the interface configuration: Ctlr+X – Yes

Next restart the eth0 (down/up) interface, so that it loads the configuration from the /etc/network/interfaces file

image

If you restart the VM, the initial banner will shows the configured IP, along with the Web interface URL that we will use latter to load IOU images.

image

On your computer set the VirtualBox Host-Only Ethernet Adapter with an IP in the same network.

Go to Control Panel → Network and Internet → Network Connections

image

image

to test that you have a connection between you computer and the VM, ping the VM from your computer:

image

 

Step 3: Uploading IOU image to UNIX

Check the IP address of the GNS3 IOU VM by issuing ifconfig (or as seen on step 2) command and note down the IP (mine 192.168.56.102). Now open any web browser in host machine and enter the following link in the address bar:

http://192.168.56.102:8000/upload

image

Choose your IOU image and click Upload button.

 image

Note the location of IOU image being copied:

/home/gns3/GNS3/images/XXXXXXXXXXXXXXXXXXX

 

Step 4: GNS3 Local and Remote Server

Go GNS3, Edit → Preferences → GNS3 Server → Local Server

Drop down the Host Binding section and choose 192.168.56.XX, VirtualBox Host-Only Adapter IP (mine 192.168.56.101) and click Apply.

This binds the local server to:

image

Again Edit → Preferences → GNS3 Server → Remote Server

Enter GNS3 IOU VM address (mine 192.168.56.102) and 8000 as port.

image

 

Step 5: IOS on UNIX Configuration for GNS3

Go to Edit → Preferences → IOS on UNIX → General Settings

Browse iourc.txt (iourc.txt can be stored on any directory of your local PC, eg: Desktop).

image

Go to IOU Devices → New button and select server type as Remote. Your remote server will be listed there. → Next

image

image

Put a Name for the IOU image and set IOU image path that you noted already in Step 2. (/home/gns3/GNS3/images/XXXXXXXXXXXXXXXXXXX)

Type the image must be L2 if switch IOU.

image

Click Finish button. and you are done:

image

If you want more Interfaces click on Edit to add more:

image

note that on IOU you add the interfaces in cards of four interfaces, so the above means:

  • 8 Ethernet Interfaces (2x4)
  • 8 Serial Interfaces (2x4)

Now you have one more router to select:

image

Based On:

Sunday, February 15, 2015

Cisco – 1:1 NAT (static NAT) with Exceptions

You have probably come across with this cenario:

PC1

where you want to forward the Public IP of R1 to PC1. To do this you just do a 1:1 NAT / Static Nat, and you are done.

The problem with this, is that you loose the management of R1, because all is forwarded to PC1.

Wouldn´t it be great if you could create an exception for the Telnet or SSH, port so that you keep managemnt of your router.

This is possible, basically you do the 1:1 NAT / Static Nat, and a Port Forwarding, to a Loopback on R1. This works because the Port Forwarding is more specific, so the port is forwarded to the Loopback of R1 instead of PC1.

The example bellow forwards the telnet port (23), to R1 Loopback Interface so that you can manage R1 it via Telnet.

 

Configs

## PC1 Config ##
hostname PC1

username cisco password 0 cisco

interface FastEthernet0/0
description *** LAN ***
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 192.168.1.254

!-- SSH Key Generation --
ip domain name cisco.com
crypto key generate rsa general-keys modulus 1024

line vty 0 4
login local
transport input ssh


## R1 Config ##
hostname R1
username cisco password 0 cisco

interface FastEthernet0/0
description *** LAN1 ***
ip address 192.168.1.254 255.255.255.0
 
ip nat inside
no shutdown

interface FastEthernet0/1
description *** WAN ***
ip address 203.103.3.110 255.255.255.252
ip nat outside
no shutdown

interface Loopback0
ip address 1.1.1.1 255.255.255.255
 

access-list 110 remark *** NAT ACL ***
access-list 110 permit ip 192.168.1.0 0.0.0.255 any

ip nat inside source list 110 interface FastEthernet0/1 overload

!-- 1:1 NAT / Static NAT  --
ip nat inside source static 192.168.1.1 interface FastEthernet0/1

!—EXCEPTION – Fw Port 23 to Loopback0 - Telnet Access --
ip nat inside source static tcp 1.1.1.1 23 interface FastEthernet0/1 23

line vty 0 4
login local
transport input telnet


## ISP Config ##
hostname ISP
username cisco password 0 cisco

interface FastEthernet0/1
description *** WAN ***
ip address 203.103.3.109 255.255.255.252
no shutdown

line vty 0 4
login local
transport input telnet

 

Tests (on ISP)

## Check The Management of R1 via Telnet ##

telnet 203.103.3.110
Trying 203.103.3.110 ... Open
User Access Verification
Username: cisco
Password:*****
R1>

As expected we reach R1 via Telnet


## Check That The Other Ports Go to PC1 ##
ssh -l cisco 203.103.3.110
Password:****
 PC1>

 

 

Another Cenario

If you want, you can have this scenario:

PC2

where instead of forwarding the Telnet port to R1 Loopback, you forward it to another equipment, in this case PC2.

The configs bellow build upon the configs above.

 

Configs

## PC2 Config ##
hostname PC2

username cisco password 0 cisco

interface FastEthernet0/0
description *** LAN ***
ip address 192.168.2.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 192.168.2.254

line vty 0 4
login local
transport input telnet


## R1 - Config (addon) ##
interface FastEthernet1/0
description *** LAN2 ***
ip address 192.168.2.254 255.255.255.0
ip nat inside
no shutdown


!—REMOVE: Fw Port 23 to Loopback0 - Telnet Access --
no ip nat inside source static tcp 1.1.1.1 23 interface FastEthernet0/1 23

!—EXCEPTION - Fw Port 23 to PC2 - Telnet Access --
ip nat inside source static tcp 192.168.2.1 23 interface FastEthernet0/1 23

 

Tests (on ISP)

## Check The Management of PC2 via Telnet ##
telnet 203.103.3.110
Trying 203.103.3.110 ... Open
User Access Verification
Username: cisco
Password:****
PC2>

As expected we reach PC2 via Telnet
 
 
## Check That The Other Ports Go to PC1 ##
ssh -l cisco 203.103.3.110
Password:*****
PC1>

Hope this was informative, and thant you for reading.

Saturday, December 27, 2014

Huawei and Cisco – Connect eNSP to GNS3 (Simulators)

Huawei eNSP (Enterprise Network Simulation Platform) is a network simulator developed by Huawei and freelly available. eNSP use Oracle Virtual Box (bundled within the eNSP installer), where each device is emulated from a single Virtual Box VM. eNSP uses a GUI to create and manage devices so no Virtual Box knowledge is needed.

Below we are going to show how to connect eNSP (v1.2.00.330) with GNS3 (v1.2.1), so that the equipments in both simulators can comunicate with each other.

Setting Up eNSP (Huawei Simulator)

ScreenShot005

Two interfaces must be added:

  • Ethernet Internal (UDP) port: used between eNSP GUI and Virtual Box ASR2 instance;
  • Ethernet Public port: used between eNSP GUI and the GNS3

Both interfaces must implement (Port Mapping) a Two-way Channel.

ScreenShot006

ScreenShot007

ScreenShot008

ScreenShot009

ScreenShot010.1

ScreenShot010.2

ScreenShot011

ScreenShot012

ScreenShot013

 

Setting Up GNS3 (Cisco Simulator)

ScreenShop001

ScreenShop003

ScreenShop004

ScreenShop005

ScreenShop007

ScreenShop008

ScreenShop009

ScreenShop010

Now just configure GE0/0/0 on AR2 (eNSP) and Fa0/0 on R1 (GNS3) on the same subnet and start pinging.

Related Links:

Friday, December 5, 2014

Cisco – IP SLA Basics

IP SLA BASICS

MAY 6, 2011 TONY MATTKE

IP SLA is a function of Cisco’s IOS enabling you to analyze a Service Level Agreement (SLA) for an IP application or service. IP SLAs use active traffic-monitoring to continuously monitor traffic across the network. This is very different from SNMP or Netflow data which give you more volume oriented statistics. Many different metrics can be analyzed using IP SLA, here is a break down of a few.

  • UDP Jitter – Probably the most used operation in all of IP SLA. This IP SLA generates UDP traffic and measures Round-trip Delay, One-way Delay, One-way Jitter, One-way Packet Loss, and overall Connectivity.
  • ICMP Path Jitter – Hop-by-hop Jitter, Packet Loss, and Delay.
  • UDP Jitter for VoIP – Enhanced test for VoIP monitoring. It can simulate various codecs and spits out voice quality scores (MOS, and ICPIF). Also shows us Round-trip Delay, One-way Delay, One-way Jitter, and One-way Packet Loss.
  • UDP Echo – Round-trip Delay for UDP traffic.
  • ICMP Echo – Round-trip Delay, full path.
  • ICMP Path Echo – Round-trip Delay and Hop-by-hop round trip delay.
  • HTTP – Round-trip time using simulated http traffic.
  • TCP Connect – Allows us to sample the time to connect to a target using TCP.
  • FTP – Round-trip time for file transfers.
  • DHCP – Round-trip time for dynamic host configuration.
  • Frame-Relay –Round-trip Delay, and the Frame Delivery Ratio. Mostly used for circuit availability.

IP SLA Configuration

There are 2 parts to the IP SLA configuration. Our testing source, and the responder. Typically our responder is a device local to the data center, while the test host is device at a remote site. The test host sends data to the responder and the responder sends a reply back. The configuration for the responder is nothing but really, really simple…

ip sla responder

Seriously. Now lets take a look at the configuration of the testing source. Any questions I don’t answer here should be easily available via IOS context help… Here is an example I’m using in production.

ip sla 10 ! New IP SLA Instance #10
udp-jitter 10.1.1.1 16800 source-ip 10.2.2.2 codec g711ulaw ! udp jitter w/Voice codec
tos 184 ! TOS bit, using EF here
frequency 300 ! testing interval

ip sla schedule 10 life forever start-time now ! start now, never stop

So, what does this get us? Here are the stats output by our IP SLA source..

Router#sh ip sla statistics 10 ! Omit the # to view all SLA stats.
IPSLAs Latest Operation Statistics

IPSLA operation id: 10
Type of operation: udp-jitter
    Latest RTT: 42 milliseconds
Latest operation start time: 18:28:06.603 UTC Thu May 5 2011
Latest operation return code: OK

RTT Values:
    Number Of RTT: 1000 RTT Min/Avg/Max: 39/42/154 milliseconds
   
Latency one-way time:
    Number of Latency one-way Samples: 1000
    Source to Destination Latency one way Min/Avg/Max: 25/26/41 milliseconds
    Destination to Source Latency one way Min/Avg/Max: 13/15/127 milliseconds

Jitter Time:
    Number of SD Jitter Samples: 999
    Number of DS Jitter Samples: 999
    Source to Destination Jitter Min/Avg/Max: 0/2/15 milliseconds
    Destination to Source Jitter Min/Avg/Max: 0/2/90 milliseconds

Packet Loss Values:
    Loss Source to Destination: 0 Loss Destination to Source: 0
    Out Of Sequence: 0 Tail Drop: 0
    Packet Late Arrival: 0 Packet Skipped: 0
   
Voice Score Values:
Calculated Planning Impairment Factor (ICPIF): 1

MOS score: 4.34
Number of successes: 7
Number of failures: 0

Operation time to live: Forever

Conclusion

Cisco’s IP SLA features can be a huge benefit to any engineer trying to track down issues on the network. Using IP SLA in combination with a SNMP management suite, or even an EEM script can provide real time alerting for adverse network conditions, allowing you to respond faster and perform better.

Author: Tony Mattke

Taken From: http://routerjockey.com/2011/05/06/ip-sla-basics/?subscribe=success#blog_subscription-3

Monday, November 24, 2014

Change MAC Address on Linux (Ubuntu / Debian)

Temporary MAC Address Change

When you change the MAC address for an interface, you need to have the network interface disabled (down) and than to set the new MAC.

You can do both this things with the command:

$ sudo ifconfig eth0 down hw ether AA:BB:CC:DD:EE:FF && ifconfig eth0 up

This sets down the eth0 interface, changes the mac to AA:BB:CC:DD:EE:FF and turns the interface back down.

Or, do it in the old fashioned way:

$ sudo ifconfig eth0 down
$ sudo ifconfig eth0 hw ether AA:BB:CC:DD:EE:FF
$ sudo ifconfig eth0 up

Read more about the ifconfig command here.

 

Permanent MAC Address Change

To set the hardware address (MAC), open the /etc/network/interface file in your favourite text editor:

$ sudo vim /etc/network/interfaces

After the network interface configuration, paste this line: hwaddress ether AA:BB:CC:11:22:33.
Note: AA:BB:CC:11:22:33 is just a sample, replace it with the MAC address you want to set for your interface.

Example, with dhcp enabled network interface:

auto eth0
iface eth0 inet dhcp
hwaddress ether AA:BB:CC:11:22:33

Example, with a network interface having a static ip:

auto eth0
iface eth0 inet static
address 192.168.0.100
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.0.1
hwaddress ether AA:BB:CC:11:22:33

To apply the MAC change, restart the network interface:

$ sudo /etc/init.d/networking restart

Based On:

Sunday, November 23, 2014

Raspberry Pi (Linux) – TigthVNC Server + File Transfer

How to Configure Your Raspberry Pi for Remote Shell, Desktop, and File Transfer

So you have a Raspberry Pi and you would like to maximize its tiny footprint by turning into a totally stand alone box—no monitor, keyboard, or other input peripherals. Read on as we show you how to set up remote shell, desktop, and file transfer access on your Pi.

Why Do I Want to Do This?

The Pi, even clad in a sturdy case, is a tiny computer. It’s perfect for tucking somewhere out of sight without a gaggle of wires sticking off of it—for many projects you simply don’t need a permanent monitor and peripheral accompaniment.

That doesn’t mean, however, that you won’t need to connect to the box to make changes, update things, transfer files, and so on. A perfect example of this is the cool little rain indicator we built as part of our Build an LED Indicator with a Raspberry Pi (for Email, Weather, or Anything) article. It doesn’t need all that stuff attached right to it, but we still would like the ability to hop onto the device and easily make changes or try out a new experiments with the LED module without having to drag it back into the workshop, and hook it up to a monitor, keyboard, mouse, etc. By configuring it for remote shell, remote desktop, and remote file transfer, we make it super simple to always interact with our Pi unit from the comfort of our desktop computer as if we’ve hooked the unit up to a full work station.

What Do I Need?

If you’re brand new to working with the Raspberry Pi, we strongly suggest checking out The HTG Guide to Getting Started with Raspberry Pi to get a handle on the basics of the device and get up to speed.

For this tutorial you will need the following things:

  • A Raspberry Pi running Raspbian.
  • A desktop or laptop computer.
  • A local Wi-Fi or wired network to connect the Pi and your computer.

First, most of the steps in this tutorial should work with other Linux-based Pi distributions butwe’re going to be using Raspbian. You should have little trouble adapting the tutorial to other distributions.

Second, we’re using a Windows machine as our networked computer to interact with the Raspberry Pi unit as the remote head/interface. When appropriate, we’ll do our best to link to tutorials and suggested reading regarding performing parallel tasks and tools on OS X and Linux.

Setting Up and Connecting to the SSH Server
clip_image002

Remote command line access to your Raspbian installation is about the handiest little tweak you can make to your system, and it’s down right simple to enable.

Open up the terminal in Rasbian, the shortcut is LXTerminal on the desktop, and type in the following command:

sudo raspi-config

Navigate down to ssh and hit enter. When prompted about the SSH server, select Enable and hit enter again. You will be returned to the Raspi-config panel; navigate down to Finish and hit enter to close out the configuration tool. That’s all you need to do to turn on SSH access to your Pi. The default SSH login and password is pi and raspberry, respectively.

While you’re still sitting at the command line, now is a great time to check the IP of your Raspberry Pi unit on the local network. Type ifconfig at the prompt and then look at the output of the command. If you’re using the Ethernet port you want to look for the init addr in the eth0section; if you’re using Wi-Fi, you want to look for the init addr in the wlan0 section. In addition to checking and noting the IP address, this is also a great time to set up a static IP entry in your router so you don’t have to hunt for the IP in the future.

Now that we have the SSH server enabled, we know the login, and we know the IP address of the machine, it’s time to connect in via SSH and test it out. To do so from Linux and OS X you can simply use the ssh command at the terminal. Windows users, however, will need an SSH client like PuTTY.

Since we’re using a Windows box to remotely manage our Pi, PuTTY it is. Install a copy of PuTTY or extract the portable version and fire it up. There are a lot of settings you can mess with in PuTTY, but we only need to worry about a single thing to connect to our Pi. On the main Session interface, just type in the IP address of your Pi and select SSH below it:

clip_image003

Hit Open at the bottom and PuTTY will launch a terminal window for you, connect to your Pi, and prompt you to log in. Go ahead and log in with pi / raspberry:

clip_image005

Once your SSH connection is functional, you could technically complete the rest of this tutorial remotely from the comfort of your desk—although we’d advise leaving the head and keyboard on your system until you have finish the whole project and have everything running smoothly.

Before we move on, there’s some extra functionality we can squeeze out of SSH. In addition to managing the command line remotely, you can also remotely transfer files using Secure Copy. It’s command line intensive and not particularly convenient for transferring a large number of files sourced from multiple directories, but for a one-off configuration file transfer or other small dump, it’s pretty handy. Check out our guide to copying files over SSH using the SCP command here.

We’re going to be looking closer more user-friendly/GUI-based file transfer techniques later in the tutorial.

Setting Up and Configuring Your Remote Desktop

clip_image006

Remote command line access is awesome, but so is having access to the desktop for GUI-focused activities. Let’s bring the powers of the command line and the powers of the desktop together.

Although we’ve been referring to it as “remote desktop” to this point, the tool we’re actually installing is known as Virtual Network Computing (VNC)—iterations of which many are familiar with such as RealVNC and TightVNC. For this tutorial, we’ll be installing TightVNC on the Pi. In order to access the Pi-based TightVNC session, you will need a remote client such as:

Grab a copy now, and we’ll be trotting it out later in this section. For now, let’s get down to installing the TightVNC server on your Raspberry Pi. Open up the terminal. Enter the following command to get started:

sudo apt-get install tightvncserver

This will download and unpack the installation files; when prompted to continue press Y. After the installation is complete, you’ll be returned to the prompt.  You can start the VNC one of two ways. Simply running the command for the server like so:

tightvncserver

clip_image007

Will prompt you enter a password to access your VNC desktop—as seen in the screenshot above. The password needs to be 4-8 characters long. Once you confirm the password, you will be prompted to set a view-only password (you can opt out of the step, as we did).

 

Continue reading to learn how to configure your server and setup file transfer tools.

Alternatively, you can use a much more precise, albeit longer to type out, command that gives you more control over how the remote computer will see the desktop—most importantly, what resolution the desktop will display so you can enjoy a full screen view on the remote computer. To specify the resolution of the VNC desktop, use the following command, swapping out the resolution value (the fourth item in the command) for the resolution of the remote desktop:

vncserver :1 -geometry 1600×900 -depth 16 -pixelformat rgb565:

If at any point you make a mistake in setting up your VNC server instance and/or you want to shut down the VNC server, simply enter the following (changing the number after the colon to the number of the VNC instance you want to kill):

vncserver –kill :1

Now that we have the VNC server up and running, let’s connect into it from our remote desktop. Fire up TightVNC viewer on your computer and plug in the IP address of the Raspberry Pi unit followed by :1 like so:

clip_image008

And here’s our reward for successfully configuring our VNC server—a nice full screen view of our remote Raspberry Pi unit:

clip_image010

There’s a known issue with TightVNC and Rasbian that, thanks to a wonky permission change, will cause trouble with the actual monitor-is-attached desktop (while leaving the remote desktop interface provided by the VNC server untouched).  To fix this issue before it even becomes a problem for you, head right to the command line and enter the following command:

sudo chown pi /home/pi/.Xauthority

This command changes the ownership of the .Xauthority file back to the user pi—for the curious, the .Xauthority file is used by the X-windows system in Rasbian and something during the TightVNC server installation and configuration process causes that little permissions hiccup.

With that little minor detour out the way, let’s get back to finishing our remote desktop configuration.

Now that we have full command line and desktop access to the Raspberry Pi, there’s one not-so-trivial tweak we need to make. The Raspi-config tool set the SSH server to automatically start on boot for us, but the VNC server is not yet configured in such a fashion. You can skip this step and manually start the server at the command line via SSH when you need it, but we’re trying to make this as fuss-free as possible for future use. Let’s take a minute now and create a startup file for the VNC server.

In order to automatically start the VNC server, we need to set up an init, or initialization, file that Raspbian will use to cleanly start and shut down the server during the boot and shut down process. Let’s create the init file now. At the command line type in the following command:

sudo nano /etc/init.d/tightvnc

This will create a file in the initialization directory called “tightvnc” and open the nano editor so we can paste in our script. In the nano editor, paste the following code (make sure to change the 1600×900 resolution value to match the screen of your remote computer:

#!/bin/sh
### BEGIN INIT INFO
# Provides: tightvncserver
# Required-Start:
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start vnc server
# Description:
### END INIT INFO

case “$1″ in
start)
su pi -c ‘vncserver :1 -geometry 1600×900 -depth 16 -pixelformat rgb565:’
echo “VNC Started”
;;
stop)
pkill Xtightvnc
echo “VNC Terminated”
;;
*)
echo “Usage: /etc/init.d/tightvnc {start|stop}”
exit 1
;;
esac

In addition to modifying the screen resolution portion of the script, there is one other thing you can modify. In line 14 you can change the command “su pi -c” to any other user account besides “pi” if you wish to VNC to the specific desktop for that account.

Once you have pasted and modified the code, it’s time to save it. Press CTRL+X to exit and save your work in nano. Once you are back at the command line, we need to make a few quick changes to the permissions of the file:

sudo chmod 755 /etc/init.d/tightvnc

Now the initialization file is executable. We can test it from the prompt:

sudo /etc/init.d/tightvnc start

sudo /etc/init.d/tightvnc stop

The last change we’re going to make is to update the rc.d file (which tracks which initilization scripts are in the /init.d/ folder):

sudo update-rc.d tightvnc defaults

After you enter that command, you’ll get a confirmation that the file was updated. Now it’s time for the real test: does the file load properly after reboot? Enter the following at the command line to reboot and be prepared with your VNC client to test the connection in a moment:

sudo reboot

Once the system has finished rebooting, log in with your VNC client. If your VNC session fails, visit the command prompt and run the tightvnc start command (from the test portion above) again to double check that the file is executable and that the password was saved properly.

At this point, we’re even further along in our mission to totally remote-control our Raspberry Pi unit. With remote command line access via SSH and remote desktop access via VNC under our belts, let’s move on to simplifying the process of transferring files between our Pi and desktop computer.

 

Setting Up and Configuring File Transfer Tools

clip_image012

Since we already have SSH set up, the easiest way to set up dead simple file transfer between our Pi and remote computers is to piggy back a GUI interface on the SSH connection. Remember how we talked about using SCP over SSH earlier in the tutorial? Running it from the command line gets real tedious, real fast. With a GUI wrapper, we’ll be able to spend more time moving files and playing with our Pi and less time pecking at the keyboard.

While there are a variety of GUI wrappers for the SCP command, we’re going to go with a cross-platform tool that many people already know, have, and love (and may even be unaware that it does SCP transfers): FileZilla. It’s available for Windows, OS X, and Linux—you can grab a copy here.

Once you have installed FileZilla, fire it up and go to File –> Site Manager. Create a new site entry, name it, and plug in user name and password for your Pi.

clip_image013

Finally, make sure to set the port to 22 and the Servertype to SFTP – SSH File Transfer Protocol. Click connect at the bottom and you’ll be treated to a view similar to this one:

clip_image014

Your local directories are in the left-hand pane and the remote directories on the Pi are in the right-hand pane. Moving files between the two is as simple as drag and dropping them.

Taking advantage of the existing SSH file transfer is the easiest way to get at the files on the Pi with no additional configuration necessary but if you want to configure your Pi to receive and share files without the remote user requiring any fancy tools (like an SCP capable FTP client such as FileZilla), we highly recommend checking out the Samba configuration portion of our guide:How to Turn a Raspberry Pi into a Low-Power Network Storage Device. Reading over that will familiarize you with setting up a basic Samba share on Pi to create a shared folder easily accessible by just about anyone on your network without any additional tools.

You’ve configured SSH, you’ve configured VNC, and you’ve set up simple SFTP and/or Samba access to your Pi—at this point you can boot down your Raspberry Pi, strip away the monitor, keyboard, and mouse, and tuck it away as a silent and headless machine.

Have an idea for Raspberry Pi project and you’re dying for us to write a tutorial for it? Sound off in the comments or shoot us an email at tips@howtogeek.com and we’ll do our best to help.

Taken From: http://www.howtogeek.com/141157/how-to-configure-your-raspberry-pi-for-remote-shell-desktop-and-file-transfer/all/