Sep 12

Ubuntu server as wifi AP and Mikrotik as a DHCP server

Reading time: 2 – 3 minutes

It’s important to have a very clear picture about the scenario that we’re going to configure in that case because it’s a little bit particular. This is an evolution of the previous post: Ubuntu server as wifi AP and Mikrotik as a DHCP server

schema

There is a server running Ubuntu 16.04 and offering wifi service as an AP. The wifi interface is in bridge mode with the ethernet port and send all traffic to the Mikrotik gateway where there is a DHCP server in charge to serve IP address to wifi clients.

Start by configuring the bridge in the Ubuntu server. File “/etc/network/interfaces”:

source /etc/network/interfaces.d/*

auto lo br0
iface lo inet loopback

#ethernet interface
allow-hotplug enp2s0
iface enp2s0 inet manual

#wifi interface
allow-hotplug wlp3s0
iface wlp3s0 inet manual

# Setup bridge
iface br0 inet static
    bridge_ports enp2s0 
    address 192.168.2.2
    netmask 255.255.255.0
    network 192.168.2.0

Pay attention on “bridge_ports” the wifi interface is not added on the list, this is because until the hostapd is running it doesn’t make sense to do that. You’ll see “bridge=br0” option on hostapd.conf which will fix that misbehavior.

Wifi AP configuration, “/etc/default/hostapd”:

DAEMON_CONF="/etc/hostapd/hostapd.conf"

and “/etc/hostapd/hostapd.conf”:

bridge=br0                # bridge interface
interface=wlp3s0          # wifi interface name
driver=nl80211
ssid=the_ssid_name        # name of your network
hw_mode=g
channel=1
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=3
wpa_passphrase=the_secret_key   # secret key to joing with the wifi network
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
logger_syslog=-1
logger_syslog_level=3
logger_stdout=-1
logger_stdout_level=1

DHCP server configuration on Mikrotik:

# setting the interface address, in my case ether4
/ip address
add address=192.168.2.1/24 interface=ether4 network=192.168.2.0

# setting up DHCP on interface 4 of the mikrotik device
/ip dhcp-server
add address-pool=dhcp-pool disabled=no interface=ether4 name=dhcp-pool

# network of the DHCP server
/ip dhcp-server network
add address=192.168.2.1.0/24 dns-server=8.8.8.8 domain=your_network.local gateway=192.168.2.1 netmask=24

# IP pool used by the DHCP server
/ip pool
add name=dhcp-pool ranges=192.168.2.65-192.168.2.70
Mar 03

parprouted – ARP daemon

Reading time: 1 – 2 minutes

parprouted és un dimoni que fa funcions de proxy ARP, idea per fer unir dues xarxes a nivell 3 quan no estan unides per la capa 2. O sigui, no cal que fem WDS (usant en xarxes Wi-Fi) o que posem un bridge de capa 2 per unir dues xarxes separades físicament però unides a través de routing.
El funcionament del dimoni és el següent: quan es rep una petició ARP i la resposta de la petició és desconeguda llavors aquesta petició ARP es re-envia a la resta d’interficies en busca de la MAC requerida per la IP demanada en la petició ARP. Quan es localitza la IP es creen rutes estàtiques de tipus host (/32) per interconnectar aquella IP que esta en una altre interficie de xarxa diferent de la interficie que la requeria. Així aconseguim fer visible la IP entre les dues interficies de xarxa.
Totes les entrades que es creen amb el dimoni es refresquen cada 50s enviant peticions ARP que validin que encara són vigents. En cas de que les peticions fallin el propi kernel borrarà les entrades de la taula ARP i el dimoni s’encarregarà de borrar les rutes estàtiques.
Normalment es triguen uns 60ms per aconseguir fer visible un host que no esta al propi segment de xarxa degut als processos que s’han comentat, però es considera un temps marginal en comparació al benefici que se’n obté.

Feb 27

pfSense i VMWare: problemes amb les interficies en bridging [solucionat]

Reading time: 4 – 6 minutes

Ahir en Joan i jo ens varem passar 11h per descobrir que el nostre gran problema d’incompatibilitat entre el pfSense i el VMWare ESX 3.5 no era res més que un petit error de configuració a un virtual siwtch (vSwitch) que unia les interficies virtuals del firewall.

Bé anem a descriure l’escenari. Imagineu un pfSense com a màquina virtual d’VMWare amb dues potes físiques, o una física i una virtual, com volgueu el problema és el mateix.  Si les dues són virtuals no ho he provat, però imagino que passa el mateix. La qüestió és que si fem que les dues potes del pfSense estiguin en mode bridge, és a dir com si el pfSense no hi fos i ambdues subxarxes estiguessin unides en una de sola, llavors el tràfic entre una xarxa i l’altre no flueix. O sigui, no podem passar ni paquets ICMP, ni TCP ni UDP. Però si que podem passar paquets ARP. Curiós, eh!?

vmware-pfsense-bridge

En el dibuix anterior es veu l’escenari d’exemple que varem estar provant. O sigiui, un portàtil en una xarxa física, després en una altre xarxa hi teniem un servidor físic i un de virtual. El pfSense sempre virtual, o sigui dins del VMWare ESX. Per altre banda teniem una altre pota real que ens connectava a internet. Però això no és rellevant, només ho indico perquè quedi clar que el pfSense tenia tres potes i que les que feien el bridge no eren la LAN i la WAN. Sinó la LAN i una OPT1. L’escenari real i le proves següents complicaven aquest escenari bàsic afegint una pota més del pfSense també en mode bridge amb la primera, les proves també van funcionar.

Pels que no estigueu familiaritzats amb el VMWare per fer això cal definir dos vSwitch un que uneixi la LAN del pfSense amb la targeta de xarxa real del VMWare i la Xarxa 1. Un altre vSwitch ha d’unir el pfSense amb la Xarxa 2, que té una màquina virtual connectada a ell i un targeta de xarxa del VMWare connectada a un switch real amb un ordinador físic. Doncs bé, aquestes dues interficies del pfSense es posen en mode bridge i els ordinadors de la xarxa 1 i 2 poden compartir domini de col·lisió i el pfSense pot fer filtrat de packets en mode stealth ja que els usuaris ni s’adonen que els seus paquets passen per un firewall.

Diria que ja ha quedat clar el que passava, doncs bé en Joan i jo ens varem passar 11h lluitant i investigant d’on podia venir el problema que feia que els paquets no passessin d’un costat a l’altre del pfSense. De fet, el que varem observar per començar és que a l’itnerficie de xarxa del pfSense no arribaben els paquets de la xarxa 1 a menys que aquests anessin dirigits a la IP de la pota de forma explícita, o els paquets que volien usar el firewall com a porta d’enllaç per navegar.

Doncs bé, el tema esta en que els vSwitch del VMWare han de tenir el paràmetre “Promiscous Mode“, que per defecte esta a “Reject“, a “”Accept“. Fent això a ambdós vSwitch els paquets flueixen d’un costat a l’altre del firewall sense problemes. Increible, oi? doncs si. Una de les múltiples alegries que et dona l’informàtica quan després d’aixecar-te a les 4 del matí per posar en producció el sistema, a les 6 de la tarda descobreixes en un entorn simulat que el problema venia d’això.

A continuació adjunto un parell de captures de pantalla on podeu veure com per  defecte el paràmetre esta a “Reject” :

Caputra de les propietats d'un vSwitch

i simplement editant les propietats del vSwitch el podem posar a “Accept”:

vmware-vswitch-sc002

Això farà, que demà a les 8 hem toqui treballar altre vegada i que per fi pugui posar en producció el sistema. Esperem que les proves de concepte fetes en el entorn simulat que varem montar ahir a la tarda segueixin funcionant tan bé en l’entorn real demà al matí. Apa doncs, només agraïr al Joan la seva paciència i seguir provant i provant colze amb colze amb mi per arribar a aquesta solució.