Mikrotik ipsec 20 kbps, de miért?

Hálózati eszközök

Sziasztok!

Csak ötletben / tippben kérnék, egy kis útmutatást, a megoldást vagy magam megkeresem vagy megköszönöm nektek.

Adott két mikrotik egy Hap Ax3 (arm64) és egy hex reflesh (arm)-os.
https://mikrotik.com/product/hex_2024

A probléma a következő:
Ugyanazok a beállítások mtu, ipsec titkosítás (aes-cbc, aes-gcm)
Egy dolog a különbség, az ipsec policyban a Transfer vagy a Tunnel átvitel.

Az eredmény siralmas. 100Mbit kontra 5Mbit, szinte teljesen mindegy milyen titkosítást használok hasonló az arány.
Az 5Mbit néha "csak" 20kbps-en ragad egy nagyméretű ftp fájlmásolás alatt. Teljesen mindegy, hogy a tunnel ipip, gre vagy eoip. Csökkentett mtuval, pl.: 1300-ra is ugyanez a helyzet.
Cpu terén 100Mbitnél is maximum 50%-on van, 5Mbitnél kb 1-5%.

Kérlek ne azt mondjátok, hogy menjek wireguard, zerotier irányba, hanem a Mikrotik Expertektől kérdezném, mi felett siklottam el, hogy tunnel módban ilyen siralmas a helyzetem.

Segítségeteket előre is köszönöm.

Config:

https://pastebin.com/YRRryemK

Update:

Van clamp tcp mss a tunnelen és van mangle szabály is:

chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags=syn protocol=tcp out-interface-list=Tunnels tcp-mss=1419-65535 log=yes log-prefix="ChangeMSS"

  • 1191 megtekintés

( ecsi | 2025. 08. 23., szo – 19:16 )

Szerkesztve: 2025. 08. 23., szo – 19:20

Mikrotik Guruk please help! NAT-T engedélyezve.

( AMDFan | 2025. 08. 23., szo – 22:14 )

Szerkesztve: 2025. 08. 23., szo – 22:18

A leírás alapján nem biztos, hogy mikrotik specifikus probléma, inkább fragmentation problémák tűnik, hiszen Tunnel módban kisebb payload fér bele és ezt még megfejeled azzal is, hogy UDP encapsulation is van a nat traversal miatt. Nem lehet, hogy valami nem stimmel a PMTU discoveryvel? Hol állítottad az MTU-t?

ui: biztos kell NAT-T? Ha tudsz állítani egy one-on-one NAT-ot, akkor az ESP csomagok is betalálnak a helyükre és akkor ki tudnád kapcsolni.

Default beállítás a tunneleken a clamp tcp mss, illetve a fastpath is csak kikapcsolva lehet ipsec mellett.

Mangle is van clamp to pmtu-val, icmp engedélyezve ehhez a configban.

chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags=syn protocol=tcp out-interface-list=Tunnels tcp-mss=1419-65535 log=yes log-prefix="ChangeMSS"

( vasla_ | 2025. 08. 24., v – 09:26 )

Szerkesztve: 2025. 08. 24., v – 11:20

IPsec "installed sa" fülön webfigben látsz H betüt. Hardware gyorsítást ?

UI:

Az egyik mikrotikedben nincs hw gyorsitás, és  ha van valamelyik oldalon egy gyenge upload, akkor az korlát lesz. 

 

Nálam upload egyik oldalon 20 Mbit, ipsec sebessége 20 Mbit/sec, Másik irányba jobb ott 50-100 Mbit/sec. Mindketto hw-es mikrotik.

 

Ping paranccsal a ki tudod deriteni a csomagméretet, ping ne fragmentáljon, és kezd csökkenteni a csomagméretet. Van pár kész kis script erre.

https://blog.claryel.hu

( ggallo | 2025. 08. 24., v – 18:15 )

Szerintem is MTU probléma lesz és/vagy valamelyik oldal mégsem használja a HW IPsec gyorsítást. IPsec NAT-T GRE tunnellel kapásból szép kis overhead (kb. 92 byte IPv4 címzés esetén).

Én is úgy próbálnám, hogy leveszem a tunnel MTU-t mondjuk 1200-ra, és mérek, majd emelem addig, amíg be nem konyul a sebesség.

Fentebb írtam, hogy próbáltam. Csökkentetem 1300-ra, ami már mindenre is elég kellett volna hogy legyen.

 

 

 

Kipróbáltad ???

 

És miért is elég az 1300, elég mert az szerencseszám ? Na ahol nem elég:
 

C:\Users\vasla>tracert 172.16.3.100

Tracing route to 172.16.3.100 over a maximum of 30 hops

  1     1 ms     1 ms     1 ms  192.168.4.3
  2     *        *        *     Request timed out.
  3    15 ms    13 ms    14 ms  172.16.3.100

Trace complete.

C:\Users\vasla>ping -f -l 1300 172.16.3.100

Pinging 172.16.3.100 with 1300 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 172.16.3.100:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\vasla>ping -f -l 1200 172.16.3.100

Pinging 172.16.3.100 with 1200 bytes of data:
Reply from 172.16.3.100: bytes=1200 time=39ms TTL=253
Reply from 172.16.3.100: bytes=1200 time=15ms TTL=253
Reply from 172.16.3.100: bytes=1200 time=15ms TTL=253
Reply from 172.16.3.100: bytes=1200 time=21ms TTL=253

Ping statistics for 172.16.3.100:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 15ms, Maximum = 39ms, Average = 22ms

https://blog.claryel.hu

Az a baj, hogy ez az "1 tunnel van" dolog ez csak egy high level elnevezés. Alapvetően ha NAT-T-vel használsz ipsec-et, akkor már dupla encapsulation van, egyszer ESP aztán pedig UDP. Egy "tunnel" az nem más mint egy vagy több encpasulation a valódi csomag előtt amit el akarsz küldeni. Minden encapsulation csökkenti a "valós" csomagméretet.

1400-as mtu-val
 

ecsi@vm1:~$ ping -M do -s 1372 192.168.80.200
PING 192.168.80.200 (192.168.80.200) 1372(1400) bytes of data.
1380 bytes from 192.168.80.200: icmp_seq=1 ttl=62 time=13.4 ms
1380 bytes from 192.168.80.200: icmp_seq=2 ttl=62 time=11.0 ms
1380 bytes from 192.168.80.200: icmp_seq=3 ttl=62 time=11.0 ms
^C
--- 192.168.80.200 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 10.955/11.767/13.370/1.133 ms
ecsi@vm1:~$ ping -M do -s 1373 192.168.80.200
PING 192.168.80.200 (192.168.80.200) 1373(1401) bytes of data.
ping: local error: message too long, mtu=1400
ping: local error: message too long, mtu=1400
ping: local error: message too long, mtu=1400
^C
--- 192.168.80.200 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2037ms

ecsi@vm1:~$

ecsi@vm1:~$ tracepath 192.168.80.200
 1?: [LOCALHOST]                      pmtu 1500
 1:  _gateway                                              2.497ms
 1:  _gateway                                              2.711ms
 2:  192.168.0.254                                          4.692ms pmtu 1400
 3:  192.168.80.200                                       16.345ms reached
     Resume: pmtu 1400 hops 3 back 3
ecsi@vm1:~$

Nyilván nem látom át a rendszeredet, de az látszik, hogy az MTU 1400, és az 1372 byteos icmp még átfér (1372+8 UDP +20 IP header). Én azt gyanítom, hogy nagyon a határon van a segment size, és az ESP header méretének változása miatt van amikor átmegy a csomag, van amikor nem (inkább nem) és ebből lesz a brutális lassulás. Az is jó kérdés, hogy éppen melyik hopon történik meg a fragmentálás, nekem volt egy érdekes issuem korábban amikor éppen az MTU növelése oldotta meg a problémát. Anno kiszámolgattam hogy mi és miért történt, de akárhogy próbálok, nem emlékszem vissza rá, pedig érdekes volt.

Arra emlékszem, hogy nagyon alacsony MTU-val (1300 vagy 1200) működött szépen, és volt egy range azt hiszem 1400 és 1420 között amikor nem működött. A teszt kedvéért próbáld feljebb tolni az MTU-t

Nálam mostanra a wireguard kapcsolatok mennek 1300-on, aminél valamivel kevesebb az overhead (60 byte IPv4, 80 byte IPv6). Tapasztalatom szerint 1300 feletti tunnel MTU esetén nem minden túloldalon működik nem minden szolgáltatás elérése.

Én sem szoktam pontosan kiszámolni, méregeni kapcsolatonként, meg pláne nem szoktam PMTU-t nézegetni. Csak tapasztalati alapon erre jutottam, és sehol sem célzom meg az elméleti max. sávszélt, inkább biztosra megyek az elérhetőnél valószínű alacsonyabb MTU-val.

Ha 1300-zal is ugyan olyan lassú, attól még egy 1300 alatti (pl. 1280, ami az IPv6 min. MTU) próba nem árthat. Max. nem lesz jobb, és megtudod, tuti nem az MTU a probléma.

( borz | 2025. 08. 30., szo – 11:41 )

Ezek a tesztek jutottak eszembe:

 

1) Meg tudnád próbálni, hogy teljesen kikapcsolod a fasttrackot a mikrotikeken és újraindítotod mindekőt.

Nézd meg kikapcsolt fasttrack és újraindítás után milyen sebességeid vannak. 

 

2) Ha GRE nélkül csak natív IPSEC-cel húzod össze akkor is hasonló eredményeid vannak?

 

3) Tudod esetleg SCP-vel is tesztelni a történetet?

 

4) aes-gcm ről menj le aes-256 cbc re. Nekem a minap volt olyan problémám ( bár az régebbi 7-es vol) hogy összeállt a tunnel PH1 és PH2 is,  látszólag bele is ment a forgalom, de a másik végén nem jött ki. Bár ott a túloldalt nem mikrotik volt.