Basic OpenWRT installation on VirtualBox

19 08 2018

Download the latest “combined-ext4.img.gz” image from “”.

Extract and conver the file:

# VBoxManage convertfromraw openwrt-*.img openwrt.vdi --format VDI

Install in VirtualBox taking the .vdi file as existing hard disk amd configure two network interfaces.

Network Adapter 1 > NAT
Network Adapter 2 > Bridged

Once bootup, assign dhcp to eth0 and an IP to eth1:

# vi /etc/config/network
config interface loopback
option ifname lo
option proto static
option ipaddr
option netmask
config interface wan
option ifname eth0
option proto dhcp
config interface lan
option ifname eth1
option proto static
option ipaddr
option netmask

# /etc/init.d/network restart

Now, network have to work:

# ping



Netns different outgoing source ip address

7 07 2017

Using three network interfaces, assign each one a different address as source ip address for outgoing traffic:

ip netns add blue
ip link set eth1 netns blue
ip netns add green
ip link set eth2 netns green
ip netns exec blue dhclient eth1
ip netns exec green dhclient eth2
echo "IP eth0: "
echo "IP eth1: "
ip netns exec blue curl
echo "IP eth2: "
ip netns exec green curl

Multiple network interfaces with multiple public IPs in an EC2 instance with different outbound source using network namespaces

14 02 2017

In this scenario we will have an ec2 instance with:

* 3 network interfaces
* 3 public IPs (one for each interface)
* 3 different process with different public outbound address running in separate network namespaces

As starting point, we have a simple ec2 instance with one interface and a public IP assigned to it. The steps are:

– Allocate two new elastic IPs

– Create two new network interfaces in the same subnet in which resides the instance.

– Associate the new elastic IPs to these new network interfaces.

– Associate the new network interfaces to the instance. Now, it have the default eth0 and two more, eth1 and eth2.

– Create a pair of network namespaces for the new interfaces:

ip netns add blue
ip link set eth1 netns blue
ip netns add green
ip link set eth2 netns green

– Request the IPs for the interfaces:

ip netns exec blue dhclient eth1ip netns exec green dhclient eth2

– And test it:

ip netns exec blue curl
ip netns exec green curl

Take into account that:

– You need to launch the proces with the “ip netns exec xxxx” due that systemd don’t support the network namespace assignement.

– Look the limits of AWS, by default, only 5 EIPs are allowed and each type of instance have a network limit.

VPN between PFSense in a LAN and Amazon AWS VPC with IPSec

18 10 2015

This manual cover the case of creating a IPSec VPN between a PFSense located inside a local network (in an office for example) and a VPC inside Amazon AWS, allowing the access of the resources in both sides transparently.



Base scenario

The following address are only for this manual, substitute them for your particular case:

Office LAN:
Office public IP:
Amazon VPC Net: | my_vpc



Create Customer Gateway


Start in AWS by creating a Customer Gateway. The routing can be dynamic, but as BGP is not going to be used, routing static must be select. For that reason, its neccesary to add a custom route to the Route Tables directly (later covered):

Name Tag:    test5
Routing:     Static
IP Address:





Create Virtual Private Gateways

Simply create a Virtual Private Gateway, VPG, and attach it to the target VPC.

Name Tag:     test5
Attached to: | my_vpc







Create VPN Connection

Now, create the VPN Connection joining all the things that were created before. After that, under Tunnel Details tab, there is two tunnels, we only use the first one, it have the Amazon AWS public IP for connect the IPSec VPN. Under Static Routes tab there is a route for our office network.

Name Tag:                 test5
Virtual Private Gateway:  vgw-xxxx | test5
Customer Gateway:         Existing
                          cgw-xxxx ( | test5
Routing Options:          Static
Static IP Prefixes:





Download the configuration. Mainly for know the Pre-Shared Key, the other parameters for PFsense are usually the same for all.

Vendor:    Generic
Platform:  Generic
Software:  Vendor Agnostic



Open the file and copy the Pre-Shared Key for later use:
Configure the IKE SA as follows
- Authentication Method : Pre-Shared Key
- Pre-Shared Key : AoLmjz_XLnktHkZxfSdm_69wJN11OqIuf9
- Authentication Algorithm : sha1
- Encryption Algorithm : aes-128-cbc
- Lifetime : 28800 seconds
- Phase 1 Negotiation Mode : main
- Perfect Forward Secrecy : Diffie-Hellman Group 2



Add custom route to Route Tables

This step is more dependent of your particular VPC subnets and route tables configuration, but essentially, its neccesary to add a route entry for send the traffic from your AWS subnet to your Office LAN trought the Virtual Gateway.

Target:       vgw-xxxxx | test5




PFSense configuration
Our office PFSense have two networks, one WAN interface, in this case behind a NAT but can be directly connected to internet with a public routable IP, and an other interface connected to the LAN.


Start with creating a IPSec VPN

Bring up the Phase 1 with the particular values, from the screen capture, usually only change the Remote Gateway and the Pre-Shared Key.

Key Exchange Version:  V1
Internet Protocol:     IPv4
Interface:             WAN
Remote Gateway:
Description:           VPC VPN
Authentication Method: Mutual PSK
Negotiation Mode:      Main
My identifier:         My IP address
Peer identifier:       Peer IP address
Pre-Shared Key:        AoLmjz_XLnktHkZxfSdm_69wJN11OqIuf9
Encryptation algorithm: AES 128 bits
Hash algorithm:        SHA1
DH key group:          2 (1024 bit)
Lifetime:              28800 seconds
Nat Transversal:       Auto
Dead Peer Detection:   Enable DPD
                       10 seconds
                       2 retries


Continue bringing up the Phase 2 with the particular values, from the screen capture, usually only change the Remote Network. For keep the tunnel up when there aren’t any traffic, add the IP of a AWS host in the “Automatically ping host” section.
Change Local Network to other different than “LAN subnet” if your local network is different, or greater, than the LAN connected to the interface.

Mode:                  Tunnel IPv4
Local Network:         LAN subnet
Remote Network:
Protocol:              ESP
Encryption algorithms: AES 128 bits
Hash algorithms:       SHA1
PFS key group:         2 (1024 bit)
Lifetime:              3600
Automatically ping host: ?


Define in VPN: IPsec: Settings “Maximum MSS” for avoid inexplicable failures. Tick “Enable MSS clamping on VPN traffic” and set 1387 in the box.

Finally, if all went well, must be something like this:


and this:


It’s necessary a firewall rule for allow IPSec traffic.
In case of your local network is different, or greater, than the LAN connected to the interface, add an other rule to allow all traffic under LAN tab.

Proto:       IPv4
Source:      *
Port:        *
Destination: *
Port:        *
Gateway:     *
Queue:       *


In the Amazon AWS side, the Status of VPN Connection must be changed from DOWN to UP:


Try to ping host from one side to the other, with the VPN stablished and if there aren’t any other particular network configuration, there sould not be any issue.

I hope it has been helpful…



  • You can configure the Tunnel 2 in the same PFSense, but don’t use the same public IP. For each IPSec tunnel, use a different public IP.




Other resources:

Optimized Network Settings

23 09 2013

From RedHat Performance Tuning Guide:

Performance tuning is usually done in a pre-emptive fashion. Often, we adjust known variables before running an application or deploying a system. If the adjustment proves to be ineffective, we try adjusting other variables. The logic behind such thinking is that by default, the system is not operating at an optimal level of performance; as such, we think we need to adjust the system accordingly. In some cases, we do so via calculated guesses.

As mentioned earlier, the network stack is mostly self-optimizing. In addition, effectively tuning the network requires a thorough understanding not just of how the network stack works, but also of the specific system’s network resource requirements. Incorrect network performance configuration can actually lead to degraded performance.

For example, consider the bufferfloat problem. Increasing buffer queue depths results in TCP connections that have congestion windows larger than the link would otherwise allow (due to deep buffering). However, those connections also have huge RTT values since the frames spend so much time in-queue. This, in turn, actually results in sub-optimal output, as it would become impossible to detect congestion.

When it comes to network performance, it is advisable to keep the default settings unless a particular performance issue becomes apparent. Such issues include frame loss, significantly reduced throughput, and the like. Even then, the best solution is often one that results from meticulous study of the problem, rather than simply tuning settings upward (increasing buffer/queue lengths, reducing interrupt latency, etc).

Searching for Strings in Network Traffic

8 01 2013

To search for packets containing data that matches a regular expression and protocols that match a filter
# ngrep [grep-options] regular-expression [filter-expression]
To search instead for a sequence of binary data:
# ngrep -X hexadecimal-digits [filter-expression]
To sniff packets and save them in a file:
# ngrep -O filename [-n count] [-d interface] [-s snap-length] \
regular-expression [filter-expression ]

To read and display the saved network trace data:
$ ngrep -I filename regular-expression [filter-expression]

The ngrep command searches network traffic for data that matches extended regular expressions, in the same way that the egrep command (or grep -E) searches files. In fact, ngrep supports many of the same command-line options as egrep, such as -i (case-insensitive), -w (whole words), or -v (nonmatching). In addition, ngrep can select packets using the same filter expressions as tcpdump. To use ngrep as an ordinary packet sniffer, use the regular expression “.”, which matches any nonempty payload.

ngrep is handy for detecting the use of insecure protocols. For example, we can observe FTP transfers to or from a server, searching for FTP request command strings to reveal usernames, passwords, and filenames that are transmitted as clear text:

$ ngrep -t -x 'USER|PASS|RETR|STOR' tcp port ftp and host
interface: eth0 (
filter: ip and ( tcp port ftp )
T 2003/02/27 23:31:20.303636 -> [AP]
55 53 45 52 20 6b 61 74 69 65 0d 0a USER katie..
T 2003/02/27 23:31:25.315858 -> [AP]
50 41 53 53 20 44 75 6d 62 6f 21 0d 0a PASS Dumbo!..
T 2003/02/27 23:32:15.637343 -> [AP]
52 45 54 52 20 70 6f 6f 68 62 65 61 72 0d 0a RETR poohbear..
T 2003/02/27 23:32:19.742193 -> [AP]
53 54 4f 52 20 68 6f 6e 65 79 70 6f 74 0d 0a STOR honeypot..
58 received, 0 dropped

The -t option adds timestamps; use -T instead for relative times between packets. The -x option prints hexadecimal values in addition to the ASCII strings.

ngrep prints a hash character (#) for each packet that matches the filter expression: only those packets that match the regular expression are printed in detail. Use the -q option to suppress the hashes.

To search for binary data, use the -X option with a sequence of hexadecimal digits (of any length) instead of a regular expression. This can detect some kinds of buffer overflow attacks, characterized by known signatures of fixed binary data.

ngrep matches data only within individual packets. If strings are split between packets due to fragmentation, they will not be found. Try to match shorter strings to reduce (but not entirely eliminate) the probability of these misses.
Shorter strings can also lead to false matches, however—a bit of experimentation is sometimes required. dsniff does not have this limitation.

Like other packet sniffers, ngrep can write and read libpcap-format network trace files, using the -O and -I options. This is especially convenient when running ngrep repeatedly to refine your search, using data captured previously, perhaps by another program. Usually ngrep captures packets until killed, or it will exit after recording a maximum number of packets requested by the -n option. The -d option selects a specific interface, if your machine has several. By default, ngrep captures entire packets (in contrast to
tcpdump and ethereal), since ngrep is interested in the payloads. If your data of interest is at the eginning of the packets, use the -s option to reduce the snapshot and gain efficiency.

When ngrep finds an interesting packet, the adjacent packets might be of interest too, as context. The ngrep -A option prints a specified number of extra (not necessarily matching) packets for trailing context.

This is similar in spirit to the grep -A option, but ngrep does not support a corresponding -B option for leading context.

A recommended practice: Save a generous amount of network trace data with tcpdump, then run ngrep to locate interesting data. Finally, browse the complete trace using Ethereal, relying on the timestamps to identify the packets matched by ngrep.

Configurar la red en Debian

10 12 2012

En /etc/network/interfaces:

auto eth0
iface eth0 inet static
address 192.168.0.XX
up /usr/local/etc/