oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: routing

Windows 10: Internal Virtual Switch with NAT

2021/07/12 1 comentari

Reading time: 2 – 4 minutes

When you are playing with Windows Hyper-V and you want to create a completely virtual internal network with private virtual machines inside your Windows 10 machine virtual switch are mandatory.

Then it’s the time to connect that virtual switch with the host machine using a virtual network interface. All those steps can be done using Hyper-V manager user interface, but you cannot control 100% of parameters like enable, or not, the NAT of the virtual internal network.

Using PowerShell the steps are:

New-VMSwitch -SwitchName NATSwitch -SwitchType Internal
New-NetIPAddress -IPAddress 10.46.1.1 -PrefixLength 24 -InterfaceAlias "vEthernet (NATSwitch)"
New-NetNAT -Name NATNetwork -InternalIPInterfaceAddressPrefix 10.46.1.0/24

Of course, change “NATSwitch” for your switch name and “10.46.1.1” for the IP address of the host virtual network card. Finally “NATNetwork” is another arbitrary name for referring to the NAT rule, and “10.46.1.0/24” is the network address of the virtual internal host network.

Running the commands looks like:

For removing what you did:

Remove-VMSwitch -Name "NATSwitch"
Remove-NetIPAddress -InterfaceAlias "vEthernet (NATSwitch)"
Remove-NetNAT -Name NATNetwork

In Windows 10 IP forwarding is not enabled and packets between interfaces are not routed. According to the Microsoft forums, you can enable IP forwarding (routing) using the following steps:

Go to Start and search on cmd or command. Right click on either cmd or command then select Run as administrator. At the command prompt type regedit. Navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\Tcpip\Parameters\IPEnableRouter setting, right click and select Modify. Change 0 to 1 and exit the editor.
When your back at the command prompt type services.msc and navigate to the Routing and Remote Access service. Right click and select Properties. Change to Automatic and click on Start to start the service.

I had to research a long time until I found all this information, but in my case leverage my proofs of concepts to another level.

Internet fail over connection with Mikrotik

2016/08/29 2 comentaris

Reading time: 2 – 4 minutes

Based on my home configuration I’m going to describe how to set up a Mikrotik to manage fail over Internet connection. Next schema describes a Mikrotik gateway with two internet connections (GUIFI and SS). Assuming GUIFI as a default Internet connection periodic checks on Google DNSes (8.8.8.8 and 8.8.4.4) will allow to know when it’s good to change the default route.

If you have some Linux routing background it will be easier to understand the configuration. Main idea is use policy routing tables and mark packets to use one table or other. In my case I have two routing tables GUIFI and SS, and of course, the default gateway of each of those tables is the gateway indicated in the schema.

First step is take care about the routes for hosts to monitor; using GUIFI connection will be checking connectivity to 8.8.8.8 and using SS the monitored host will be 8.8.4.4.

/ip route
add dst-address=8.8.8.8 gateway=172.29.2.1 scope=10
add dst-address=8.8.4.4 gateway=172.29.1.1 scope=10

Second step is configure two routing tables, those routes will check Internet hosts availability. Routes are resolved recursively (more info), and will be active only if any host is pingable.

# routing table for GUIFI
/ip route
add distance=1 gateway=8.8.8.8 routing-mark=GUIFI check-gateway=ping
add distance=2 gateway=8.8.4.4 routing-mark=GUIFI check-gateway=ping
# routing table for SS
/ip route
add distance=1 gateway=8.8.4.4 routing-mark=SS check-gateway=ping
add distance=2 gateway=8.8.8.8 routing-mark=SS check-gateway=ping

Routing table looks like that:

Next step will be create marking rules in the firewall:

# next rule mark all LAN traffic (10.2.0.0/26) before routing
# it'll be processed by routing table GUIFI
# it makes GUIFI the default Internet connection 
/ip firewall mangle
add action=mark-routing chain=prerouting comment="All LAN traffic" dst-address=\
    !10.0.0.0/8 new-routing-mark=GUIFI passthrough=no src-address=10.2.0.0/26

If any specific host, service or whatever want to use specific routing table, then you can create new rules with proper mark to redirect the traffic to that Internet connection. But if that path fails other Internet connection will be used.

In my case I have a more complicated scenario, internal VoIP server uses a IP Telephony service only available through GUIFI connection. The way to force that is forbidding traffic to SS connection. A simple firewall rule will help to do that:

# X.X.X.X = IP address of the IP telephony provider
/ip firewall filter
add action=reject chain=forward dst-address=X.X.X.X in-interface=\
    bridge-lan out-interface=SS-eth2

I hope previous simple notes are useful for you, they are inspired by Advanced Routing Failover without Scripting.

parprouted – ARP daemon

2010/03/03 No hi ha comentaris

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é.

mikrotik: failover gateway

2008/02/26 3 comentaris

Reading time: 4 – 6 minutes

Avui he refrescat una mica la meva memòria, feia algún que altre mes que no jugava amb els mikrotik. Doncs bé, per un client havia de montar un failover gateway i com que ja sabeu que sóc un fan declarat dels mikrotik per fer això he usat un RB150. Per si això ús sona a xinès segur que amb una petita explicació ho trobareu molt útil. Doncs bé, cada cop més empreses tenen dos sortides a internet i el que volen és que quan alguna de les dues sortides caigui l’altre sortida assumeixi tot el tràfic sense haver de tocar res.

Obviament per fer això el que hem de tenir és un element que s’encarregui de redirigir tot el tràfic cap a un router o cap a l’altre segons si la sortida a internet esta fallant o no. La solució que plantejo és molt simple i pot perfeccionar-se moltíssim. Per exemple, l’únic que explicaré és a usar un dels dos routers i quan aquest falla enviar el tràfic cap a l’altre però no és gaire difícil crear unes policy routes per balancejar tràfic entre els dos routers mentre aquests estiguin operatius. Però per no liar la cosa em quedaré amb l’exemple bàsic. A partir d’aquí, la base estarà més que feta perquè feu coses més xules.

escenari

El RB150 tindrà a l’ethernet 1 la xarxa LAN. A la ethernet 4 la WAN1 i a la ethernet 5 la WAN2. Amdues interficies tenen el router ADSL en monopuesto. O sigui, que tinc la IP pública a l’interficie del router.

funcionament

Per defecte, sortirem per la WAN1 i quan aquesta falli sortirem per la WAN2.

configuració

Assumeixo que les configuracions bàsiques ja estan fetes, o sigui, assignació d’IPs a interficies i l’enmascarament d’IP internes cap a internet. Això suposo que no té cap dificultat si algú necessita ajuda que avisi.

Creem dos scripts a llençar quan s’hagi de llençar la connexió via WAN1 i l’altre via WAN2:

Script per la WAN1:

:log info wan_1
/ip route set [/ip route find dst-address="0.0.0.0/0"] gateway=IP_GW_WAN1

Script per la WAN2:

:log info wan_2
/ip route set [/ip route find dst-address="0.0.0.0/0"] gateway=IP_GW_WAN2

Si ens interessa en cada un dels scripts hi podem afegir el que calgui. Per si no esteu habituats a treballar amb scripts al mikrotik els heu de colocar a /system scripts. Allà afegiu dues entrades i llestos. Com sempre això serà molt més còmode fer-ho des del winbox que no pas des de la cli.

Ara només cal que creem una entrada a l’eina netwatch, això es fa a /tool netwatch. A l’entrada li direm que faci pings cada un interval de temps que decidirem i que tingui un timeout fixe i si els pings no tornen llavors s’executarà l’script indicat. Bàsicament le entrades de netwatch tenen dos estats el up i el down i podem associar un script a llençar en cas de que hi hagi una oscil·lació cap a un dels dos estats. Això es fa així:

add host=208.67.222.222 timeout=10s interval=1m up-script=wan1 down-script=wan2 \
comment="Failover Gateway Script" disabled=no

El que fem és mirar si arribem a un dels servidors d’OpenDNS cada 1minut i ens esperem com a molt 10s perquè el ping torni. Després fixeu-vos com associem cada un dels scripts que em programat abans als estats d’aquesta prova.

Com podeu veure això és ben senzill, la gràcia esta en que jugueu amb els ECMP i els policy routing i feu del RB150 tot un balencejador de càrrega amb suport de fallides de línia. També és molt senzill que balancegeu el tràfic d’entrada d’internet cap a una ADSL o cap a l’altre, per fer això ús recomano que jugueu amb el DDNS que podeu actualitzar a través dels scripts comentats, només cal que li llenceu la petició d’actualitzar la IP associada al DDNS i els usuaris remots entraran per una o altre línia.