Lantronix XPort a odchozí spojení přes pfSense

[starostacz]

Dobrý den všem,
ve firmě máme router pfSense 2.8.1 CE pro připojení k Internetu. Používáme jej roky, žádný problém s ním není.
Běží na něm základní věci jako firewall, BIND DNS, DHCP server, NTP server, IPsec, OpenVPN a Wireguard.

V lokální síti mám zařízení s modulem Lantronix XPort (serial to Ethernet converter), který je nastavený tak, aby sám automaticky vytvořil odchozí spojení na cloudový server a zařízení do něj sype data pro ten server.
Nastavení XPort:
IP Address: 192.168.99.76    
Subnet Mask: 255.255.252.0    
Default Gateway: 192.168.96.1

Active Connect: Auto Start
Remote Port: 65211
Remote Host: 81.31.X.X

XPort připojím do LAN, zapnu, spojení se vytvoří, data se přenáší, potud OK.
Problém nastane, když dojde k opakovaným krátkodobým výpadkům Internetu. Pak už se spojení většinou neobnoví.

Pokud se podívám na LAN pfSense, tak požadavky SYN na něj z XPortu chodí, pokud se podívám na WAN pfSense, tak tam ty požadavky už do Internetu nevylezou.
Ve firewall states je toto:

Kód: [Vybrat]

LAN tcp 192.168.99.76:10001 -> 81.31.X.X:65211                         ESTABLISHED:ESTABLISHED 12.809K / 9.542K 566 KiB / 411 KiB
WAN tcp 193.165.X.X:41410 (192.168.99.76:10001) -> 81.31.X.X:65211 ESTABLISHED:ESTABLISHED 12.809K / 9.542K 566 KiB / 411 KiB

Když dojde k výpadkům a spojení přestane fungovat, tak tyto záznamy ve states jsou stále ve stavu "ESTABLISHED:ESTABLISHED". Firewal si tedy myslí, že je vše OK, ale data přes něj netečou, počet paketů a bytů se nemění. Pokud ty záznamy smažu, okamžitě se vytvoří nové a spojení se obnoví.
V pfSense je oubound NAT nastavený na Hybrid Outbound NAT, záznamy vypadají OK.

Podotýkám, že mám ještě jiné zařízení, PC s Linuxem, které dělá to samé, připojuje se na stejný server a port a jemu se při výpadku Internetu spojení vždy obnoví.
Problém je tedy v kombinaci chování XPortu a nějaké vlastnosti firewallu pfSense. Už mě nenapadá, kde může být problém. Co s tím? Díky za rady, odpovědi AI nikam nevedou.

[Reklama]

[RDa]

Zkusil bych nahrat konkretni sekvenci komunikace jak u PC tak u XPortu, zacit predtim nez vytahnete kabel do internetu.

Nejspis jde o rozdilny zpusob ukonceni spojeni a navazani noveho (tipuji: XPort znovu zacne na tom samem Local Port-u, coz zmate ten firewall/nat).

XPort ma posledni FW ? (zda se to toto nevyresilo uz vyrobcem)

[František Ryšánek]

Firmware Xportu je maličký, jeho IP stack je koloběžka. Xport má 16bit x86 CPU (80186 compatible), 256 kB SRAM, 16 kB bootROM, 512 kB flash. Tam není Linux ani BSD, jenom nějaký sranda OS. Nedivil bych se, pokud zotavení po výpadku spojení nemá moc dobře ošetřeno. Nejlíp ještě, pokud ten kousek softwaru co "točí spojení ven" je nějaký custom plugin od výrobce boxu, ve kterém je ten X-port integrovaný... nevím jestli je to ještě pravda, ale před lety se k tomu dodávalo SDK pro DOSové Borland C.

[starostacz]

Zkusil bych nahrat konkretni sekvenci komunikace jak u PC tak u XPortu, zacit predtim nez vytahnete kabel do internetu.

Nejspis jde o rozdilny zpusob ukonceni spojeni a navazani noveho (tipuji: XPort znovu zacne na tom samem Local Port-u, coz zmate ten firewall/nat).

XPort ma posledni FW ? (zda se to toto nevyresilo uz vyrobcem)

Ono se to těžko simuluje, nestačí mi odpojovat LAN XPortu, to se chytí, musí se přerušit spojení z WAN na server a ještě pouze nějakým způsobem.
XPort dělá všechny odchozí spojení na stejném portu a jak se mu spojení přeruší, tak hned posílá SYN.
FW není poslední, ale ve změnách nic o tomto není. Mohu to zkusit, i když si nemyslím, že to pomůže.

[starostacz]

Firmware Xportu je maličký, jeho IP stack je koloběžka. Xport má 16bit x86 CPU (80186 compatible), 256 kB SRAM, 16 kB bootROM, 512 kB flash. Tam není Linux ani BSD, jenom nějaký sranda OS. Nedivil bych se, pokud zotavení po výpadku spojení nemá moc dobře ošetřeno. Nejlíp ještě, pokud ten kousek softwaru co "točí spojení ven" je nějaký custom plugin od výrobce boxu, ve kterém je ten X-port integrovaný... nevím jestli je to ještě pravda, ale před lety se k tomu dodávalo SDK pro DOSové Borland C.

Ale ten XPort se chová myslím způsobně, resp. jemu to přerušení spojení nijak nevadí a hned posílá SYN, aby se spojil znovu. Vidím to na LAN. Jenže pfSense už to nepřeposílá na WAN.

[Reklama]

[jjrsk]

...
opakovaným ... výpadkům ...

... tak požadavky SYN na něj z XPortu chodí, pokud se podívám na WAN pfSense, tak tam ty požadavky už do Internetu nevylezou. ...

Tomu se rika syn flood, a muze byt, ze ten tvuj router to proste zacne zahazovat. Melo by to jit vypnout, a nebo nastavit nejakou vyjimku.

Nejlepsi by ale bylo vyresit stabilitu ty linky.

Edit: V tuxovi to vypada nejak tak (dmesg)
TCP: request_sock_TCP: Possible SYN flooding on port ...

A konfiguruje se to pomoci sysctl + pripadne rule do firewallu samo.

[jjrsk]

Ale ten XPort se chová myslím způsobně, resp. jemu to přerušení spojení nijak nevadí a hned posílá SYN, aby se spojil znovu. Vidím to na LAN. Jenže pfSense už to nepřeposílá na WAN.

Pro zajimavost, kolik to generuje pps? Protoze i to muze byt ten problem. Jestli to generuje milionkrat za sekundu syn, tak to rek bych odstreli kazdej aspon trochu svepravnej firewall.

[starostacz]

Stabilitu linky neovlivním, je to prostě připojení k Intrnetu místním poskytovatelem a někdy to vypadavá.
Ten SYN tam vidím tak 15x za 10 sekund, tedy asi 1,5 za sekundu.

Jak jsem psal, on si ten pfSense firewall asi myslí, že se to spojení nezavřelo, proto jsou ty záznamy ve "states" označené jako ESTABLISHED, ale data přes to netečou. Jakmile ten řádek smažu, vytvoří se znova a jede to.
Moje teorie je, že se při výpadku "správně neuzavře" spojení, firewal to nepozná a drží si jej dále. XPort posílá SYN, ale to už neprochází.
Když jsem na straně serveru to spojení uzavřel, tak XPort poslal první SYN snad za pár desítek milisekund. A je možné, že tehdy firewall nepozná ukončení spojení.

Já mohu XPort nastavit tak, aby nevytvářel spojení sám od sebe ihned jak se mu uzavře, ale až mu přijdou nějaká data na sériový port. Pak je tam výpadek pár sekund a tehdy to funguje dobře. Ale z různých důvodů toto nastavení nechci použít.

[RDa]

Jeste bych mozna zkusil variantu pfSense nahradit za "tupy" router/NAT (proste takovy obyc router+wifi).

At se izoluje problem - zda za to muze nejake featura z prechytraleho pfSense, nebo ten XPort samotnej.


Jinak se zaznamem ESTABILISHED nemuze projit SYN na druhou stranu, to je logicky.
A ze NAT nebude zasahovat do spojeni (nebude generovat RST/FIN) je asi taky cekatelny.. takze ten chudak XPort se nedozvi ze je konec.. a tim ze zacne ze stejneho local portu tak zmate ten router.

Dalsi vec k testu: pri takovem vypadku provest RESET xportu a doufat ze si vylosuje jiny local port - nebo ne? Zustava fixni i po cyklovani napajeni/systemu?