Mikrotik RouterOS - configuratii diverse, tricks, etc

ca sa vezi cr ip folosesti to duci la ip - ipsec - tab-ul mode config. Alegi de acolo cel care este cu VPN (ma gândesc ca ai numai 1) și te uiți la address. Dacă cumva este folosit câmpul de mai sus cu address pool, reții numele pool-ului și apoi mergi la ip - pool - tab-ul de pools, deschizi cel cu numele reținut mai sus și te uiți ce ip-uri sunt în pool. alea le pui ca și src address.

tot nimic. nici nu se mai conecteaza vpn-ul, ramane in connecting.

hai s-o luam altfel, cu poze, ca poate-poate...desi la retard level-ul
astora de la MikroTik mi-e din in ce mai greu sa cred ca imi iese.

ultima bomba pe seara trecuta a fost un update de SW la AP, care
mi-a facut praf wifi-ul. aveam la 6 metri de AP, printr-un perete de
beton, cel mult 5-9Mbps atat down cat si up, indiferent ca selectam
reteaua de 2.4 sau p-aia de 5Ghz. da-i si chinuie-te cu downgrade
la FW-ul din fabrica...macar bine ca mi-a iesit. but still...

LE: am mai adaugat un screenshot. am reusit sa prind ceva eroare
de conectare.

Edited by dygey, 24 January 2021 - 20:52.

fara sa-i mai fac nimic, acu' s-a conectat. probabil o fi de la ceva ce tine de aia de la
MikroTik. daca si vpn-urile si le-au facut ca pe restu' chestiilor, viitoru-i luminos.

anyway, tot asa face...pot sa ma conectez la AP (nu inteleg nici in ruptul capului de
ce si cu ce-i asta mai special), dar la router nu. practic, daca inteleg eu bine, vpn-ul
asta ar trebui sa ma "duca" in reteaua mea de acasa si d-acolo sa pot sa fac ce-mi
trece mie prin cap.

am incercat si un ping, raspund ambele device-uri. conectare? neah...yeeeeey!!

Edited by dygey, 24 January 2021 - 22:21.

Probabil cand incerci sa te conectezi la router acesta considera ca acea conexiunea nu vine din "LAN" iar firewall-ul ii da drop, conform regulilor.
Sa verifici poti da pentru scurt timp disable la regulile de drop din firewall si sa incerci.
Pe AP nu ai firewall activ. Cam asta e diferenta intre ele.

 Znevna, on 24 ianuarie 2021 - 22:25, said:

acum, ca a aparut maestru' in peisaj, incepe sa aiba logica. ma inclin, stimate domn!

mai are rost sa spun ca m-am apucat sa fac ce-ai zis si a luat-o instant? apoi le-am
trecut pe rand pe "enable" si unde a picat iar m-am oprit. imi dau seama ca nu trebuie
s-o las dezactivata, asa ca o s-o pun la loc si o sa va mai stresez cu ce-i de facut pe
mai departe.


LE: daca ar avea gura backup-urile alea...

Edited by dygey, 24 January 2021 - 23:25.

ti-am zis bine cu ele atunci, este?
muta ultima regula, 17, inainte de regula 10.
pachetele "curg" dintr-o regula in alta, avand drop inainte de accept, se opresc acolo

Edited by Znevna, 24 January 2021 - 23:29.

dygey, iti inteleg supararea / frustrarea, am fost si eu pe acolo (nu neaparat cu Mikrotik, dar nu cred ca este relevant).

Am scris pe celalalt topic ceva mai mult despre Mikrotik, nu ma voi repeta aici. Insa nu e normal sa fii suparat pe un echipament / sistem / mediu doar pentru simplul fapt ca nu il stapanesti, sau ca are o curba de invatare mai  ... neplacuta.

Din pozele tale de mai sus nu-mi place firewall-ul ala (cel putin ordinea). Regulile par adaugate "la repezeala", si asta nu face bine. Ma uit mai atent, citesc si restul, si mai comentez.

@Tyby Sunt regulile default ale mikrotik-ului, nu stiu ce ti se pare ca ar fi puse la repezeala, exceptand ultima regula pe care am mentionat-o mai sus.

Am scris si la ei pe forum despre gaselnita de azi, voi scrie si aici.
Util pentru posesorii de MikroTik hEX RB750Gr3.
Pe pagina de support al acestui model https://mikrotik.com...fndtn-downloads exista doua "block diagrams", una cu disabled switching, alta cu enabled switching.
Pe scurt, in disabled switching, sunt doua link-uri de cate 1Gb catre procesor, 1 link (port 1,3,5) + 1 link (port 2,4), adica daca providerul tau iti ofera mai mult de 500Mbps up/down ar trebui sa folosesti unul din cele doua link-uri pentru WAN(1,3,5) iar celalalt pentru LAN(2,4), sau invers sa ai mai multe porturi pentru LAN.
Nu stiu cand e activa schema cu "enabled switching", pentru ca aia ar fi de preferat. Porturile 2,3,4,5 sunt in bridge, hardware offloaded, dar nimic.
Urc si testele facute intre doua laptop-uri cu doua sesiuni iperf, tot mutand un laptop in 2,3,4,5..

interface bridge port print
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload
#	 INTERFACE		 BRIDGE	 HW PVID PRIORITY PATH-COST INTERNAL-PATH-COST HORIZON
0 H ;;; defconf
	 ether2			 bridge	yes 1	 0x80		 10	  10	 none
1 I H ;;; defconf
	 ether3			 bridge	yes 1	 0x80		 10	  10	 none
2 H ;;; defconf
	 ether4			 bridge	yes 1	 0x80		 10	  10	 none
3 I H ;;; defconf
	 ether5			 bridge	yes 1	 0x80		 10	  10	 none

Edited by Znevna, 12 March 2021 - 09:32.

Update: nu prea bate ce-am zis mai sus cu testele facute azi, adica daca vrei sa scoti portul 2 din bridge si sa faci bridge din 1,3,4,5, sa folosesti 2 ca port WAN, ghinion, mai ai doar un singur port in bridge cu throughput wan<=>lan bun. Bridge-ul pare sa modifice totusi ce port merge pe care lane, dar e un bug undeva.
Astept sa vad ce raspund si cei de la support.
Teste:

Edited by Znevna, 13 March 2021 - 19:07.

Pe scurt, sa ai (momentan, poate se rezolva) WAN pe port 2 sau 4 e cea mai proasta combinatie posibila.

Edited by Znevna, 13 March 2021 - 19:32.

hmmm ... mai devreme am pierdut acces pe mikrotik-ul de acasa de pe toate trusted hosts (dar ma "doare" ca nu imi dau seama de ce draq?! ). Pot accesa prin VPN din spatele lui (din LAN) si WinBox, si Webfig, insa nu din extern (de nicaieri se pare).

In filter este asa cum o setez de ani intregi, si neschimbata ca si pozitie:

/ip firewall filter
add action=accept chain=input comment="Winbox from TM-hosts" dst-port=8291 protocol=tcp src-address-list=TM-hosts

Astazi inainte de pranz am intrat sa modific niste reguli de NAT (niste mascaradari pentru hairpin, ca uitasem sa le fac, si m-am lovit ieri de ele, si am restrictionat mai adanc niste ssh-uri de la niste masini de test, ca m-am saturat de alerte), dar fara nici o legatura cu winbox-ul sau webfig-ul. Pentru singurata insa am dezactivat tot ce inseamna NAT, mai putin L2TP si src-nat general, am deschis winbox fara restrictii cat am dat un test ... nada.

Am facut un update de ros si firmware, poate poate. Nada. Deja mi se pare ca RDS-ul imi filtreaza portul / porturile. Ceea ce, evident, nu cred sa fie adevarat.

PS: tot ce e NAT (si am si testat) pare sa functioneze (cloud, NS, surveillance, http/s, MTA etc). In filter insa pare sa nu lase nimic. Imi vine sa le arunc cateodata! :/ O sa vad acasa dupa un restore ce si cum ...

PS: ca sa nu apara discutii: da, evident ca am incercat de pe mai multe masini de la mine din birou, si din mai multe locatii (incluse in TM-hosts).

Edited by Tyby, 15 March 2021 - 17:17.

Ai cumva porturile de vpn puse in NAT (port forward)?
Eu a trebuit sa scot 500 si 4500 din NAT ca sa imi mearga l2tp ipsec pe input. Cu ele acolo nu puteam intra pe vpn devat din LAN.

Cretule, da, dar nu vad legatura

VPN merge ok, si de pe device-urile mele catre extern, si invers. Fac L2TP catre Synology-uri din spate (de-aia le am forwardate, cu ipsec-esp), nu fac catre Mikrotik-uri (de la un punct incoa am avut probleme cu L2TP-ul catre Mikrotik-uri).

Nu am avut timp aseara sa ma joc cu ala de acasa, poate astazi (desi ma indoiesc). In continuare nu ma pot conecta cu WinBox din exterior la hAP AC2-ul de acasa (problema a aparut brusc, de ieri).

RDS-ul nu cred ca filtreaza portul, cel putin eu am incercat acum sa intru (din si pe RDS) pe dispozitivele ramase cu port standard & allow_list si n-am avut probleme.
Poti verifica usor daca ajunge totusi pana la router folosindu-te de sniffer: interfaces: all, tcp, 8291, rx.

Daca ajung pachetele, ai de luat la puricat firewall-ul de pe router

Edited by Znevna, 16 March 2021 - 12:03.

Da, stiu, dar trebuie timp Deocamdata, cat am VPN, mi-e suficient ... vedem zilele care urmeaza. Sau in week-end ...

M-am enervat, am rupt doua minute (ma rog, vreo 15 in final), am facut un sniff.  Surpriza: ajung pachetele (asa cum ma asteptam). Dar nu se intampla nimic cu ele!

Mai mult, am pus ca prima regula din firewall (ma rog, a doua, prima este dummy for fasttrack counters) un log pe input, cu sursa IP-ul respectiv. Imi loga pe input ICMP, insa nu WinBox sau webfig.

add action=log chain=input comment="input log for incoming tests" connection-state="" log=yes log-prefix=input_log_test src-address=IP_SURSA

Next: am adaugat un log si pe forward

add action=log chain=forward comment="forward log for incoming tests" connection-state="" log=yes log-prefix=forward_log_test src-address=IP_SURSA

Si - surpriza - toate pachetele mele se duceau in forward!

Evident ca ieri, cand am modificat regulile de forward, am lasat un forward fara port. DMZ like.

PS: adaugat portul, totul a revenit la normal.

Si uite asa ... un nou trick pentru topicul asta: cum sa faci debugging la o conexiune care "nu vrea", pornind de la sniff-ul lui Znevna, si continuand cu doua reguli simple, dar eficiente.



PPS: mi-am rupt cele "doua minute" pentru ca ma stresa maxim, si nu aveam stare!

Jucarie noua pentru un client.

 2021-04-27 14.08.57.jpg   188.02K   44 downloads

Urmeaza un pic de laborator (RDS, un /29 routat prin IP-ul de link, NAT 1:1 pentru unele servicii, plus unul dintre IP-uri cu srcnat pentru restul clientilor).

O sa trisez un pic, ca deja am facut laboratorul pe 1009-le meu prin iarna, acum doar o sa o replic (si testez).

Ceva de genul:

[...]
/ip address
add address=192.168.0.240/24 comment="WAN Interface" interface=bridge-wan network=192.168.0.0
add address=192.168.16.254/24 comment="LAN Interface" interface=bridge-local network=192.168.16.0
add address=2.2.2.1/29 comment="public /29" interface=bridge-29-loopback network=2.2.2.0
add address=2.2.2.2/29 interface=bridge-29-loopback network=2.2.2.0
add address=2.2.2.3/29 interface=bridge-29-loopback network=2.2.2.0
add address=2.2.2.4/29 interface=bridge-29-loopback network=2.2.2.0
add address=2.2.2.5/29 interface=bridge-29-loopback network=2.2.2.0
/ip firewall nat
add action=dst-nat chain=dstnat comment="2.2.2.2 traffic - restricted RDP at T450-TM" dst-address=2.2.2.2 dst-port=3389 protocol=tcp src-address-list=myHosts to-addresses=192.168.16.198
add action=dst-nat chain=dstnat comment="2.2.2.2 traffic - general SMTP(s), HTTP(s) at T450-TM" dst-address=2.2.2.2 dst-port=25,465,80,443 protocol=tcp to-addresses=192.168.16.198
add action=src-nat chain=srcnat src-address=192.168.16.198 to-addresses=2.2.2.2
add action=dst-nat chain=dstnat comment="2.2.2.3 traffic - MTA on vBox @T450" dst-address=2.2.2.3 dst-port=25,465,993,995 protocol=tcp to-addresses=192.168.16.197
add action=src-nat chain=srcnat src-address=192.168.16.197 to-addresses=2.2.2.3
add action=src-nat chain=srcnat comment="2.2.2.4 - rest of the clients" src-address=192.168.16.0/24 to-addresses=2.2.2.4
add action=src-nat chain=srcnat comment="2.2.2.5 - VPN clients" src-address=192.168.16.64/28 to-addresses=2.2.2.5
[...]

Tin minte ca era ceva ce nu mergea cum trebuie (ICMP catre 2.2.2.0/29?! - parca), dar ma lamuresc dupa ce setez.

PS: evident, 2.2.2.0/29 este exclusiv pentru "frumusete", si necesita niste rute suplimentare pe clientii externi, altfel se duc in Oranju' din FR (care detine clasa cu 2.2.2.0 real)