Mikrotik IPSEC site2site vpn MTU

Hálózati eszközök

Két mikrotik router site to site vpn, (voidafine static ip, telekom pppoe) 
Egyik irányban minden jó, másik irányba néhány eszköz webGuija nem megy.

ping -l el kiderült,hogy baj van a csomagmérettel. Az egyszerűség kedvéért MTU-t
1300 ra állítottam mindkét routerben, minden működik. 
Viszont igy minden csomagra érvényes az 1300.

1. Miért ilyen fapados ez, vagy csak én nem tudok valamit? hogyan szokás ezt beállítani ?
2 hagyjama pi..ába és inkább wireguard ?  Vagy az is ilyen ?

 

  • 799 megtekintés

( wpeople v | 2024. 11. 23., szo – 19:27 )

Ha megnézed, a két internet kapcsolatod nem azonos MTU-val dolgozik, ez okozhat némi zavart az erőben...

Ezért állitottam mindkettőt 1300 -ra . Az egyik irányba minden működött, a másik iréányb voltak gondok. ping xxxx  -l 1300 ,ment ,  1400  meg nem , beállitottam erre "oszt jó napot". Tele a net ezel, első hozzászólónak, dorsynak  lehet igaza, jobb ha  nincs szegmentálás.

https://blog.claryel.hu

( mauzi v | 2024. 11. 23., szo – 21:19 )

Szerkesztve: 2024. 11. 23., szo – 21:20

Mit értesz IPSec site-to-site VPN alatt? Sima, tunnel módú IPSec-et, vagy van még benne valami enkapszuláció (L2TP, GRE, stb...?)

A PPPoE fejléc mérete 8 bájt, az IPv4 fejlécé 20 bájt / az IPv6 fejlécé 40 bájt. A titkosítás (ESP) teljes overheadje függ attól, hogy milyen titkosítást használsz belül. Ha NAT-T vagy Mobile IKE is van, akkor az egész payload még UDP-be is van enkapszulálva. (8 bájt)

Az 1300-as MTU értékkel nem jársz nagyon rossz helyen, de ha nagyon optimalizálni akarsz, akkor az előbb felsoroltak pontos ismeretében akár 1350-1370 környékére is fel tudhatsz mászni, már persze, ha ennek van bármi érdemi jelentőssége.

Teljesen mindegy, hogy milyen VPN technológiát használsz (IPSec, Wireguard, stb.) a matek mindenhol ugyanaz lesz, csak legfeljebb az egyes enkapszulációs rétegek overheadje között lesz pár bájtnyi eltérés.

( ggallo | 2024. 11. 23., szo – 21:48 )

Épp a minap jártam én is így, és kénytelen voltam MTU-t számolni...
...ami - mint kiderült számomra - nem is olyan egyszerű, a nekem kellő L2TP/IPsec NAT-T esetében, PPPoE internet mellett...

Nekem az jött ki, hogy a max. MTU-m 1389 byte lehet IPv4 VPN kapcsolat esetén.

Ha nem jól számoltam, akkor légyszi javítson ki, aki vágja az ilyen fokú enkapszulációt, fejléc méreteket, satöbbit.

A wireguard overhead-je IPv4 esetén 60 byte, szóval PPPoE internet mellett a max. MTU 1432 byte lehet. Plusz, sokkal egyszerűbb beállítani, és jó teljesítményt ad HW AES gyorsítás nélküli végpontokon is.

Azért fapados ez, mert bár létezik a PMTUD, de aránylag sokszor valami megakadályozza (általában "fájin" tűzfalbeállítások) a működését, így a végpontok nem tudják automatikusan kideríteni a tényleg működő max. MTU-t, ezért jellemzően kézzel kell a VPN-eken MTU-t korlátozni, hogy ez ne okozzon gondot. Legalábbis nekem ez a tapasztalatom.

( arpi_esp v | 2024. 11. 23., szo – 22:34 )

hat nem kene tiltani az ICMP-t es akkor megbeszelnek egymassal (path mtu discovery)

IKEv2 tud fragmentalni amugy

gondolom a ping a vegpontok kozott zajlott nem a routerekre, szoval attol meg a routereken lehet tiltva az icmp hogy atengedi

na meg ping!=icmp, az csak egy a sok kozul...

de ugye az mtu hibat nem a vegpont hanem a szuk keresztmetszetet okozo router fogja generalni (ha hagyjak)

Igen, a ping a végpontok között ment csak , beállítom majd , hogy a routerek is pingelhesék egymást a  VPS-en át:

/ip firewall nat add chain=srcnat src-address-type=local dst-address=172.16.3.0/24 action=src-nat to-address=192.168.4.3

illetve a túloldal:

/ip firewall nat add chain=srcnat src-address-type=local dst-address=192.168.4.0/24 action=src-nat to-address=172.16.3.3

majd kpróbálom , ICMP nincs tiltva, sőt ez egy otthoni dolog, ilyenhor tűzfal kikapcs. 

https://blog.claryel.hu

Kipróbáltam,  bár sejtettem a végeredményt, ICMP nincs tiltva, de nem látom, hogy lenne    "automatikus discovery"-t . Csak ha "kézzel"  beállítom egy értékre az MTU-t , akkor viszonnt egyből jó.  Szóval automatikus discovery ebben az esetben  nincs.
Nem foglalkoztam ilyen szinten a beállítsokkal, kicsit meglepődtem, szóval azt látom, hogy igy vagy úgy , de valahol meg kell adnod a ppoe MTU értéket ipsec tunnel esetében biztosan.

https://blog.claryel.hu

( junior013 | 2024. 11. 25., h – 10:27 )

Nem MTU-t kell változtatni, hanem MSS clamp-et kell bekapcsolni, vagy - biztos, ami biztos - tűzfalban (mangle chain) is definiálni az érintett IP subnet-ek között mindkét érintett router-en. Ezzel tudod manuálisan korlátozni, hogy ne akarja túllépni a két végpont közötti legkisebb MTU-t.

"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Valahol azt olvastam, hogy sok UDP alapú protokoll fel van erre készítve (persze biztos, nem mind) vagy kapásból valami nagyon kis csomagméretet használ, azért nem akkora probléma. Mindenesetre PPPoE-nél is, ha RouterOS alatt kikapcsolom a PPP profilban a Clamp-ot, akkor jó pár hazai weboldal be se jön, míg másokkal semmi gond, UDP-vel meg a RouterOS se bajlódik alapból (mondjuk azon kívül, hogy vagy a PMTU vagy valami felsőbb rétegbeli protokoll közbe nem lép, nem is tudom, létezik-e ezen a szinten bármilyen technika az UDP-re).

( lcseh | 2024. 11. 25., h – 15:53 )

Nekem ez oly módon állt elő, hogy bizonyos weboldalak, (Fiido.com, orczy.hu) nem jöttek be. Az egyik vonal Vodafone (ezzel nem ment), a másik egy PPPoE VDSL, azzal meg simán ment. Addig küszködtem, míg végül arra jutottam, hogy a Vodafone hálózatában van útközben egy PPPoE kapcsolódási pont és emiatt levettem a WAN interfész MTU-ját 1492-re. Most megy minden oldal.

Nem VPN, de hátha...

Teljesen véletlenül vettem észre én is, két tp_link menedszelhető switch , a tipusuk ugyanaz, egy P betű kivételével, annak  4 portja POE-s. (TL-SG108PE) Az egyiket elértem , a másikat nem ipsec en át, amig le nem vettem a csomagméreteket. A többi alkalmazáson meg nem volt észrevehető. Kis iot szenzorok, láttam őket, , Win 10 RDP meg "igazithatja"  magát, az minden beállítással ment. 

https://blog.claryel.hu