Bypassing CG-NAT

Last week I dumped Vodafone Internet + TV bundle for a dirt cheap DIGI unlimited 5G data plan for my home. I have zero interest on TV… so it felt kind of dumb to be paying for something that I really don’t use or care.

Everything working fine except that I couldn’t access my cloud server from outside my home network… I traced the problem to DIGI using CG-NAT. Carrier Grade Network Address Translation is a technology that shares the same public IP address between multiple customers. The upside: it saves IPV4 addresses, the downside: it doesn’t allow for inbound connections.

CG-NAT blocks outside connections because many devices share one public internet address. The router managing this can’t tell which device an outside request is for, so it blocks them to keep things secure and organized.

A solution is top set up a reverse SSH tunnel. You establish a secure connection to an outside device with a public IP address that forwards internet requests through it to your CGNATed device via the encrypted tunnel.

Great news this software tunnel is very easy to set up. First check for port availability on the outside device. Let’s say you want to use port 8080. Check if the port is available

lsof -i :8080

or

netstat -tuln | grep 8080

make sure nothing is using the port you will assign to your service.

Set up ssh keys login with no password between your home network device and the outside device. You should be able to login like

ssh outsidedevice

remember the -v option can be very helpful debugging ssh troubles. On the outside server adjust GatewayPorts in sshd configuration:

sudo nano /etc/ssh/sshd_config
GatewayPorts clientspecified

and restart the sshd service

sudo systemctl restart sshd

now actually dig the tunnel. From your home device connect to the outside server, replace 192.168.1.100 with your internal device IP and adjust the ports of your service and bind address..

ssh -R bind_address:8080:192.168.1.100:8080 outsideserver -v

For simplicity sake, probably you want the same port on both machines. But if for some reason you want different ports the syntax is:

ssh -R outside_ip:outside_port:inside_ip:inside_port outside -v

If for some reason you want to bind to all addresses available:

ssh -R '*:outside_port:inside_ip:inside_port' outside -v

Or simply change the GatewayPorts directive in /etc/ssh/sshd_config to yes.

Now you should be able to access from anywhere via outside, lets say http://outside:8080 the service running inside your home network at lets say http://192.168.1.100:8080 bypassing CGNAT.

If your tunnel silently freezes up when data is transmitted trough it, please try lowering the MTU in the local network device. I was having this kind of problem and lowering the interface MTU from 1500 to 1400 solved it.

ifconfig eth0 mtu 1400

replace eth0 with your interface, and if needed to stabilize your ssh tunnel connection, don’t forget to update /etc/network/interfaces to make this change permanent across reboots.

At this point probably you are happy with the setup and want to auto magically connect the tunnel at startup and re-connect in case of unexpected tunnel closing. The tool for that is autossh. Install it:

sudo apt install autossh

test it manually first

autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -R 8081:192.168.1.100:8081 outsideserver -v

If all good make a systemd script to control it

sudo nano /etc/systemd/system/autossh-tunnel.service

adjust according

[Unit]
Description=AutoSSH tunnel to Outside Server
After=network-online.target

[Service]
User=root
Environment="AUTOSSH_GATETIME=0"
ExecStart=/usr/bin/autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -o ExitOnForwardFailure=yes -NR 8080:192.168.1.100:8080 outside
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Then reload the service daemon, enable your autossh tunnel service, start it, and confirm its status.

sudo systemctl daemon-reload
sudo systemctl enable autossh-tunnel.service
sudo systemctl start autossh-tunnel.service
sudo systemctl status autossh-tunnel.service

Boom, there you go your home network service again accessible trough the internet.

Raspberry PI sending emails

Using the PI as an headless server doing some stuff, it’s a good thing to have reports by email. The best and easy way is to run sSMTP a very simple program that sends outgoing email to a mailhub for delivery.

You can actually use your Gmail account or any other account (I’m using any other account).

Install it:

apt-get install ssmtp

Configure it at /etc/ssmtp/ssmtp.conf. The most relevant option:

mailhub=mail.domain.com (the SMTP agent host, the “outgoing server” in email clients like thunderbird)

If your outgoing server needs authentication for relaying (probably you do need, if you can send emails to your own domain emails, but can’t send to external emails), set the credentials with these two options:
AuthUser=youruser@domain.com
AuthPass=yourpassword

To test it, i executed the good old mail command but get a no-no response:
-bash: mail: command not found

As Raspbian is Debian based, the “user-friendliness” doesn’t provide these stone age commands to protect one from oneself… so I went kind of mental and install it anyway:

apt-get install mailutils


After this operation, 22,8 MB of additional disk space will be used.
Do you want to continue? [Y/n] y

OH BOY, THAT’S A FUCKING LOTS OF MB/PACKAGES/DEPENDENCIES TO GET A CLI COMMAND

mail youremail@domain.com

in the interactive mode, just follow the instructions, write some non-sense to test it and then press CTRL-D to test it. And your email should automagically appear in youremail@domain.com inbox.

If something goes wrong, you can add DEBUG=YES to /etc/ssmtp/ssmtp.conf.

Raspberry PI running from an external HDD

This is a scenario where you have an external HDD (or “pen” drive) connected via USB to the PI. The SD card will be just used for the boot sequence then everything will work from the external HDD, I find the system to work faster, smoother and more stable this way (at least with my v1 PI).

First thing is to normally install the Raspbian system in the SD card. There will be 2 partitions on it. A first small fat16 partition labeled ‘boot’ with the lba flag set, and a second ext4 partition. So, on your external HDD you will need also a ext4 partition. I advice you to to make 2 partitions in the HDD, one for the OS, programs and files, and the second (like a /home/ or /data/) for personal files, backups, etc. In the event of a major catastrophic malfunction, this configuration offers a bigger safeguard to your personal data.

If you need assistance to partition and format your HDD probably its a good idea to stop here.

Mount and sync the second SD card ext4 partition with your external HDD ext4 partition

sudo rsync -avHx /mnt/sdcard/ /mnt/hdd

Next step is to mount the SD card boot partition. And change in /cmdline.txt (adjust sda1 to your HDD partition as needed).

root=/dev/mmcblk0p2 

to

root=/dev/sda1 rootwait

You can actually delete de SD card system directory (or not) it works the same. Also don’t forget to add an entry in /etc/fstab for mounting the second partition in the HDD in case you have it.

Good luck with your PI.

Raspberry PI open hotspot for your company site(s) only

Raspberry HotspotThe problem is really simple, you want/need to give open Wifi to your customers (let’s say inside a shop), but to you own company website (or websites) only. And nothing else, no other resources in the (internal or external) network.

The solution is simple and it comes in a tiny format… you will just need a Raspberry PI with a Wifi USB dongle that supports AP mode. Your company website should have an exclusive IP address

Side note: as normal, I’m not liable for any kind of mess, data loss, massive meteorite smash or other apocalyptic event in your world due to this guide.

Have the PI installed with the latest Raspbian, booted and logged in as root (sudo -s or equivalent).

Update the software sources:

apt-get update

Install the required software

apt-get install hostapd dnsmasq

Configure the wireless interface with a static IP address,
edit /etc/network/interfaces

iface wlan0 inet static
address 10.0.0.1
netmask 255.255.255.0
broadcast 255.0.0.0
# pre-up iptables-restore < /etc/iptables.rules

and restart the interface

ifdown wlan0
ifup wlan0

Here I choosed the 10.0.0.1 address to isolate the Wifi guests from the 192.168.1.x internal network. You should adapt it according to your existing set-up.

edit /etc/default/hostapd

and replace
#DAEMON_CONF=””

with
DAEMON_CONF=”/etc/hostapd/hostapd.conf”

now edit (it’s a new file) /etc/hostapd/hostapd.conf

For a full list of switches and whistles please do refer to http://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf, we go with a very minimalistic (but functional) configuration

interface=wlan0
ssid=WIFI-FREE-AS-BEER
channel=0
macaddr_acl=0
auth_algs=1
wmm_enabled=0
driver=nl80211
hw_mode=g
ieee80211n=1

Here we can start the service.

service hostapd start

and I got the dreadful failed in red font… a lsusb command quickly showed the infamous RTL8188CUS chip:
Bus 001 Device 004: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter

Thanks to the good people of the Internets you get a quick fix (you are downloading an external binary… so cross your fingers before installation, and nothing bad will happen to your PI… well, it worked for me).

wget http://dl.dropbox.com/u/1663660/hostapd/hostapd
chmod 755 hostapd
mv /usr/sbin/hostapd /usr/sbin/hostapd.ori
mv hostapd /usr/sbin/

and change in /etc/hostapd/hostapd.conf
driver=nl80211
to
driver=rtl871xdrv

service hostapd start

service [….] Starting advanced IEEE 802.11 management: ok
hostapdioctl[RTL_IOCTL_HOSTAPD]: Invalid argument

Even with the warning output the service managed to start and work correctly.

By now there should be an open network called WIFI-FREE-AS-BEER available to log in, but the process will stall in the Obtaining IP Address stage. So it’s time to move to the DHCP and DNS server.

Edit /etc/dnsmasq.conf, and place at the end of the file the lines

address=/#/aaa.bbb.ccc.ddd
interface=wlan0
dhcp-range=10.0.0.10,10.0.0.250,12h015/05/raspberry-pi-open-hotspot-for-your-company-sites-only/
no-resolv
log-queries
log-dhcp

adjust the aaa.bbb.ccc.ddd to the exclusive public IP address of your company website. Basically we are configuring Dnsmasq to answer all name resolution queries to your public IP address, and setting DCHP leases to the Hostspot clients from IP 10.0.0.10 to 10.0.0.250 valid for 12h periods.

From now on it should be possible to log in to the Hotspot, but no data flow, so let’s take care of this now. First activate the kernel IP forwarding

echo 1 > /proc/sys/net/ipv4/ip_forward

and then adjust iptables rules

iptables -F
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i wlan0 -o eth0 -p tcp -d aaa.bbb.ccc.ddd --dport 80 -j ACCEPT
iptables -A FORWARD -i wlan0 -o eth0 -p tcp -d aaa.bbb.ccc.ddd --dport 443 -j ACCEPT
iptables -A FORWARD -i wlan0 -o eth0 -p udp -d 10.0.0.1 --dport 53 -j ACCEPT
iptables -A FORWARD -i wlan0 -o eth0 -p udp -d 10.0.0.1 --dport 67:68 -j ACCEPT
iptables -A FORWARD -i wlan0 -j DROP 

remember to replace aaa.bbb.ccc.ddd with your the exclusive public IP address like in dnsmasq. From this point there should be a fully functional system. You can login to the Hotspot, and any http/https request will be landing in your company website. All other network traffic (except for the DHCP and name resolution will be blocked).

Now, to wrap up just make all this stuff survive reboots:

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf

update-rc.d hostapd defaults
update-rc.d dnsmasq defaults

iptables-save > /etc/iptables.rules

and uncomment in /etc/network/interfaces the line
# pre-up iptables-restore < /etc/iptables.rules

There is just one thing left, avoid the captive portal detection and the respective sign in to network message. If you are using some kind of URL mapping/decoupling system (really hope you do) it’s pretty easy.

For Android, test for http://clients3.google.com/generate_204 request and send a 204 header and 0 bytes:

if (isset($script_parts) && $script_parts[0] == 'generate_204') {
    header('HTTP/1.1 204 No Content');
    header('Content-Length: 0');
    die();
}

For iOS lalaland test for the user agent ‘CaptiveNetworkSupport’ and send a 200 response:

if (isset($_SERVER['HTTP_USER_AGENT']) && preg_match('/CaptiveNetworkSupport/i', $_SERVER['HTTP_USER_AGENT'])) {
    header("HTTP/1.1 200 OK");
    die();
}

That’s it folks, and I wonder what will be the next use for this tiny big computer?

UPDATE
After all been working well and good for a long time, maybe after a reboot a problem surfaced. Maybe a whim of the bits gods, the system was using the dnsmasq on internal lookups for all interfaces ignoring the interface directive.

So for example if one ssshed into the raspberry and tried to wget google.com one would get our company site…. not good.

Simple fix, manually edit /etc/resolv.conf, you can use Google public DNS (not censored) or your LAN Router IP (that normally uses the upstream DNS of your provider).

# Google IPv4 nameservers
nameserver 8.8.8.8
nameserver 8.8.4.4

and to not be automatic overwritten by dhcpclient updates set the immutable bit:

chattr +i /etc/resolv.conf

UPDATE 2
Noticed that the raspberry was missing /etc/network/interfaces (no file at all and I don’t recall to delete it). Maybe the problem was due to this and Maybe it’s time for a new SD card and fresh install.

Raspberry GPIO

Finally the fun stuff. Messing around with the General Purpose Input Output of the PI. So, first things first. First you must identify what revision PI you are working. Visually, looking at it, if there are 2 mounting holes is a revision 2, if there are no mounting holes it’s a revision 1. A much more scientific approach is to install WiringPi.

sudo bash
apt-get install git-core
apt-get update
apt-get upgrade
git clone git://git.drogon.net/wiringPi
cd wiringPi
git pull origin
cd wiringPi
./build

Then run

gpio -v

Raspberry Pinout DiagramAnd there you got the answer in the last line of the output. “This Raspberry Pi is a revision 2 board.”. So, first thing is to pull from the Internets a wiring diagram.

Now, for the actual cabling from the PI, in my opinion the best route is to get a set of male to female jumper cables. You can also find for sale some ribbon cables specific for the PI. In my opinion, unless you want to connect some device or accessory already wired to match the PI GPIO, the best option are the jumper cables, it’s very easy to visually  match the PI pin to a breadboard location, you only use the number of cables needed and they are easily routed trough the venting holes of the average PI case and easy to solder on a protoboard.

I ordered my jumper cables from Ebay, but has i waited for them, the inner MacGyver took over… with a old floppy drive flat cable is not so difficult to improvise. Just cut a segment of the cable with a sharp knife, so in one end you have the plastic connector and in the other you have the wires with a clean cut and no short circuits between them. One problem, is the floppy cable 34 pins versus 26 in the PI. What i did is simple to cut out of the way the first 8 cables of the ribbon (and just forget encasing the PI, the connector protrudes almost the same length as the SD card). Then with cable connected in the right way (not bad idea to test first at the end of the cable with a multimeter) the first cable of the ribbon corresponds to pin 1 of the PI and so on. Some pictures of this setup:

IMG_20131108_023031IMG_20131108_035153

Just another note, i have been messing with the GPIO, juggling and testing different setups without powering off the PI between rewiring, without no problem at all, but please use good judgment and common sense.

1 – Lighting up a LED with the PI (simple output example)

Connect physical pin 11 of the PI to the positive bus of the breadboard and physical pin 6 (ground) to the negative bus of the breadboard, and connect a led and >= 68Ω resistor (why?) closing the circuit between positive and negative bus strips (remember that a led is one way device, so long leg on the positive side and small leg to the negative). The diagram to make even easier:

Raspberry First Led

And now in the PI command line, the command to put the pin in output mode, switch off and on the LED:

gpio mode 0 out
gpio write 0 0
gpio write 0 1

Wait! But isn’t the cable connected to pin 11? What is this stuff with pin 0?
Well.. the logic in wiringPI is to abstract pin numbers in software so it remains “immune” to any hardware changes. As the pin diagram above (can be checked running gpio readall also), physical pin #11 (third column of gpio readall output) corresponds to wiringPI pin #0 (first column of gpio readall)  and to the GPIO #17 (the internal pin number used in the chip). So, regarding the logic of hardware abstraction with the gpio command, we can call a pin by the wiringPI numbering or the GPIO numbering (with the -g switch, ex: gpio -g write 17 0) but not by physical pin-out number…

2 – Reading state (simple input example)

To read state from a pin, you must devise a circuit that pulls up or pulls down the pin that you are going to read, then change the state of the circuit with a pushbutton (or any other suitable mean). This is a fucking bad explanation… so let’s look to the schematic:

raspberrypi_input_schemWe have physical pin #1, the 3.3v output (that’s the one that should be used for input reading) going to a 10kΩ resistor then split by a) a pushbutton that connects to physical pin #6 (ground) and b) a 1kΩ resistor that connects to physical pin #11. When the pushbutton is not pressed, no current passes trough there to ground, so the current goes to the 1kΩ resistor and pulls up pin #11. In this state, all the readings from pin #11 will be High. When the pushbutton is pressed the current will flow freely to ground (pin #6) and the reading from pin #11 will be Low. This is a bit counter intuitive, reading High (or 1) when the pushbutton is NOT pressed and Low (or 0) when the pushbutton IS pressed, but is very easy to take care in the software stage.

The diagram on the RaspberryPI and breadboard:

raspberry_input

And a very simple Python script to output when the push button is pressed:

import RPi.GPIO as GPIO
import time
buttonPin = 11
GPIO.setmode(GPIO.BOARD)
GPIO.setup(buttonPin,GPIO.IN)

while True:
    input = GPIO.input(buttonPin)
    if input == 0:
        print("Button pressed")
        exit();
time.sleep(0.1)

Save and run as “python script_name”. When the pushbutton is pressed it should output “Button pressed”. Note that with the RPi.GPIO module in the GPIO.BOARD mode, we are addressing the physical number of the pin in the board.

There! Raspberry PI, welcome to the real world. Just baby steps… laying the foundations for further developments.

Some references:
http://elinux.org/RPi_Low-level_peripherals
http://wiringpi.com/