Dotaz: blokovanie portu 1194

[jojo]

Mam od ISP privatnu IPv4 adresu. Od vcera sa nemozem pripojit na VPN server, ktory je u kamosa (Internet mi normalne funguje). Ak idem do suseda, ktory ma ineho ISP, tak sa na VPN server bez problemov pripojim. Je mozne, ze ISP blokuje port 1194? Ako by som mohol zistit ci ISP blokuje nejake porty ?

Odpovědi

[z_sk]

Zisti, kde zahadzuje cez nastroj traceroute.

[billgates]

Ak ide cisto len o odskusanie, ci je nejaky port blokovany, tak idealne u kamosa spustit tcpdump na porte 1194 a pozerat, potom to skusit na inom serveri s verejnou IP a tiez pozerat, ci sa to tam dostane.

Ale problemov moze byt viacero, nie len blokovanie. Kludne moze to byt jeho ISP, ktory zablokoval tvoju IP smerom k nemu, lebo tam bola podozriva aktivita. Pripadne ak mate toho isteho ISP, tak mozno zrusil vnutorne routovanie. Pricin moze byt milion.

Cize najlepsie je spustit u neho tcpdump a od seba skusit nejaky scan portov, napriklad pomocou nmapu. A potom to iste skusit na nejaky svoj iny verejne dostupny server.

[czjaromir]

Mimochodem kdysi dávno v kamených dobách se to testovalo jednoduše telnetem na určitém portu on ten vzdálený server vrátil nějakou hlášku. Anebo ne. To co radí kolegové bych zkusil v první řadě.

[Josef Kufner]

To funguje i dnes, jen to SSL a binární protokoly to trochu komplikují. Ale stále jde oťukat, že se alespoň to spojení naváže. Docela pomůže telnetu zapnout debug (-d), aby bylo vidět, jak se snaží a co se ještě povede.

[billgates]

Nafigu je, ze dnes uz mnohe distra (ani windows) neinstaluju telnet client spolu s inymi sietovymi toolmi. Niekedy je lahsie sa dostat k nejakemu nmapu a curlu nez telnetu :)

Inak, casto byva curl skombajnovany s telnet podporou, takze sa da pouzit: curl -v telnet://A.B.C.D:1194

[PetebLazar]

Jestli těch 1194 představuje port OpenVPN serveru, tak ten s velkou pravděpodobností poběží na UDP ne TCP, takže na to asi telnet zkušební spojení nenaváže. Ideální je asi kontrola příchozích packetů na straně VPN serveru z Vaší veřejné IP (http://mojeip.cz) jak bylo zmíněno výše, případně kontrola logů VPN serveru pokud jde o jiný důvod.

[X]

Az na to, ze ten openvpn port je v defaultu UDP. Tady telnet nepomuze.

[jojo]

ee ten ovpn je na tcp

[xkucf03]

Já jsem si na to udělal skript telnets, ve kterém je:

openssl s_client -connect $server:$port

Některé protokoly používají STARTTLS (-starttls smtp), tak pro ně se tam přidá jeden IF.

Pokud je protokol binární, tak si člověk se serverem tímhle způsobem povídat nemůže, ale často stačí ověřit, že se vůbec dá připojit (TCP) a že funguje šifrování (SSL/TLS) případně zkontrolovat, jestli je tam důvěryhodný certifikát.

Pak už nastupuje tcpdump/wireshark, kde se člověk dozví zase o něco víc. Pakety můžeme zachytávat jak na straně kliente, tak někde cestou, tak na cílovém serveru (posílat si je k sobě v reálném čase přes SSH nebo si je uložit do souboru a později stáhnout).

Ještě bych pro jistotu zkusil netstat/ss nebo se připojoval na IP adresu, abych vyloučil nějaké problémy s DNS (kdyby se jméno překládalo na špatnou adresu).

[Jendа]

To jsem mu chtěl poradit, ale openvpn TLS je nějaké divné TLS a s_clientem se mi tam připojit nepodařilo. Jinak to používám třeba na debugování certifikátů a povolených šifrovacích módů atd.

[Karlosek]

Tady mám podezření na nedostupnost té veřejné IP - jak píšete - od stejného ISP. To s oblibou dělá S*****t , tzv binat, který se přesně tak chová. Jak projde ping na tu danou veřejku? Tam pustit tcpdump na icmp a koukat.

[Jendа]

traceroute -Tp 80 (pokud chodí třeba web)

traceroute -Tp 1194

traceroute -Up 53 (pokud chodí třeba DNS)

traceroute -Up 1194

a porovnat

Dále se koukat tcpdumpem i na druhé straně a zjistit, jestli nechodí už požadavky, nebo nechodí odpovědi.

[jojo]

Zaujmave je, ze na dany openvpn server sa pripajame viaceri. Ty co mame kvazi toho ISP (co udajne blokuje komunikaciu), tak sa nedokaze pripojit nikto. Ostatny co maju inych ISP, tak bez problemov funguju.

Je uplne jasne, ze problem je u ISP. Skusil som telnet

telnet xx.xx.xx.xx 1194
telnet dyndns.dyn 1194

preslo to vporiadku. ping tak isto fungoval. Neviem teda preco to nefunguje. Je uplne jasne, ze problem ma ISP, ale neviem aky. ISP tvrdi, ze nic neblokuje. A aj keby blokoval, tak sa neprizna.

S tcpdump a traceroute az tak neviem pracovat, takze zrejme budem musiet postudovat.

[Jendа]

S tcpdump a traceroute az tak neviem pracovat, takze zrejme budem musiet postudovat.

traceroute se spustí přesně tak jak jsem napsal (nevšiml jsem si že máš openvpn přes TCP, takže jenom ty varianty s -T). tcpdump se používá "tcpdump -ni eth0 port 1194".

Ale ty píšeš že ti telnet prochází? Jako že se to spojí (ale pak už nic neuděláš, alespoň moje openvpn mě odpojí když tam něco napíšu -- a zaloguje

2022-02-19 19:59:50 localhost openvpn[414]: TCP connection established with [AF_INET]86.49.249.167:61240
2022-02-19 19:59:54 localhost openvpn[414]: 86.49.249.167:61240 WARNING: Bad encapsulated packet length from peer (26212), which must be > 0 and <= 1626 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
2022-02-19 19:59:54 localhost openvpn[414]: 86.49.249.167:61240 Connection reset, restarting [0]
2022-02-19 19:59:54 localhost openvpn[414]: 86.49.249.167:61240 SIGUSR1[soft,connection-reset] received, client-instance restarting

).

Každopádně pokud spojení projde a umře to až později, tak o tom určitě bude napsána spousta věcí v openvpn logu.

Ještě mě napadá že by problém mohlo být MTU a třeba se to zasekne v okamžiku kdy se pokusí odeslat TLS certifikáty. Zkusil bych ip l s mtu 1280 dev eth0.

[czjaromir]

Je tu ještě jedna věc na kterou jsem si vzpoměl o které nevím jak přesně funguje, ale měly by to podporovat routery pro vpn https://www.nstec.com/where-is-the-vpn-passthrough-on-my-router/ víte o tom něco?

[Jendа]

To je nějaká MFA stránka, a ne, openvpn je standardní UDP/TCP spojení, takže to nesouvisí.

[czjaromir]

jde o tu funkci passtrough kdysi dávno jsem řešil proč mi neprolézá přes router vpn a toto byla podmínka.

[jojo]

Este by som chcel doplnit. Niektori klienti (od inkriminovaneho ISP), ktori sa drzia openvpn servera, tak stale funguju. Ale ak sa odpoji uz sa viac nepripoji. Ak sa mi podari, tak sem dam dnes log s openvpn klienta.

Skusim aj tcpdump

[Josef Kufner]

To zní jako problém s DNS.

[jojo]

Presne tak. tcpdump ani nic som uz neskusal. Pozrel som sa do syslog a zistil som nasledovne.

Feb 20 09:26:46 jojo-Latitude-D610 ovpn-client[1240]: OpenVPN 2.3.2 i686-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Jun 22 2017
Feb 20 09:26:46 jojo-Latitude-D610 ovpn-client[1240]: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Feb 20 09:26:46 jojo-Latitude-D610 ovpn-client[1240]: WARNING: file 'client.key' is group or others accessible
Feb 20 09:26:46 jojo-Latitude-D610 ovpn-client[1240]: RESOLVE: Cannot resolve host address: domain.dyndns.com: Temporary failure in name resolution
Feb 20 09:26:46 jojo-Latitude-D610 ovpn-client[1243]: RESOLVE: Cannot resolve host address: domain.dyndns.com: Temporary failure in name resolution
Feb 20 09:26:51 jojo-Latitude-D610 ovpn-client[1243]: RESOLVE: Cannot resolve host address: domain.dyndns.com: Temporary failure in name resolution
Feb 20 09:26:56 jojo-Latitude-D610 ovpn-client[1243]: RESOLVE: Cannot resolve host address: domain.dyndns.com: Temporary failure in name resolution
Feb 20 09:27:01 jojo-Latitude-D610 ovpn-client[1243]: RESOLVE: Cannot resolve host address: domain.dyndns.com: Temporary failure in name resolution
Feb 20 09:27:06 jojo-Latitude-D610 ovpn-client[1243]: Attempting to establish TCP connection with [AF_INET]xx.25.258.98:1194 [nonblock]
Feb 20 09:27:07 jojo-Latitude-D610 ovpn-client[1243]: TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Connection refused
Feb 20 09:27:14 jojo-Latitude-D610 ovpn-client[1243]: TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Connection refused
Feb 20 09:27:50 jojo-Latitude-D610 ovpn-client[1243]: message repeated 6 times: [ TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Connection refused]
Feb 20 09:27:56 jojo-Latitude-D610 ovpn-client[1243]: TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Connection refused
Feb 20 09:28:21 jojo-Latitude-D610 ovpn-client[1243]: message repeated 4 times: [ TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Connection refused]
Feb 20 09:28:27 jojo-Latitude-D610 ovpn-client[1243]: TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Connection refused
Feb 20 09:28:33 jojo-Latitude-D610 ovpn-client[1243]: TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Connection refused
Feb 20 09:28:39 jojo-Latitude-D610 ovpn-client[1243]: TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Connection refused
Feb 20 09:28:45 jojo-Latitude-D610 ovpn-client[1243]: TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Connection refused
Feb 20 09:29:15 jojo-Latitude-D610 ovpn-client[1243]: message repeated 5 times: [ TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Connection refused]
Feb 20 09:29:20 jojo-Latitude-D610 ovpn-client[1243]: RESOLVE: Cannot resolve host address: domain.dyndns.com: Temporary failure in name resolution
Feb 20 09:29:20 jojo-Latitude-D610 ovpn-client[1243]: TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Network is unreachable
Feb 20 09:29:25 jojo-Latitude-D610 ovpn-client[1243]: RESOLVE: Cannot resolve host address: domain.dyndns.com: Temporary failure in name resolution
Feb 20 09:29:25 jojo-Latitude-D610 ovpn-client[1243]: TCP: connect to [AF_INET]xx.25.258.98:1194 failed, will try again in 5 seconds: Network is unreachable
.....

Z coho je vidiet, ze nie je mozne vyriesit domain name.

Server ma dynamicku verejnu IP. Este pred tym ked sme zistili problem, tak na servery admin zmenil IP adresu, ale problem sa nevyriesil. Vytvorenim novej dyndns adresy sa vsetko vyriesilo. Len neviem preco ISP dal tuto dyndns na svoj blacklist ?

Je to OpenVPN, takze netusi co tam tecie, neviem ake mal dovody.

[Jendа]

No ale po 20 sekundách se to resolvnout podařilo (tohle mi to dělá třeba s notebookem když někam dojedu a ještě se nepřipojil k síti, že) a hned se na xx.25.258.98 zkouší připojit a nejde mu to.

Nevím proč hned obviňuješ ISP, může to být problém i jinde, zkus to taky přes různé veřejné otevřené resolvery a zkus to z té sítě „ručně“ digem.

[jojo]

Moment! Tato IP adresa xx.25.258.98 je adresa (inkriminovaneho) ISP a nie adresa servera.

[trekker.dk]

Tipnul bych si, že vám ISP přístup k tomu serveru blokuje a vrací svoji adresu podle logiky "internet je web". Tj. že počítá s tím, že ten překlad DNS jména děláte, abyste se podíval na nějaký web - a místo toho webu se vám má zobrazit jejich stránka, kde bude napsáno, že ten web blokují. Nebo že vás blokují.

[jojo]

Vcera som pisal, ze admin na servery zmenil domenove meno (lebo sa domnievame, ze ISP blokuje nasu domenu). Po zmene domeny vsetko funguje. Skusil som curl a vysledky su nasledovne

Domena, ktoru ISP (udajne) blokuje

curl -vkI blokovana-domena.dns.com
* Rebuilt URL to: blokovana-domena.dns.com/
*   Trying xxx.25.251.35...
* TCP_NODELAY set
* Connected to blokovana-domena.dns.com (xxx.25.251.35) port 80 (#0)
> HEAD / HTTP/1.1
> Host: blokovana-domena.dns.com
> User-Agent: curl/7.53.1
> Accept: */*
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Mon, 21 Feb 2022 18:33:57 GMT
Date: Mon, 21 Feb 2022 18:33:57 GMT
< Server: Kestrel
Server: Kestrel

< 
* Connection #0 to host blokovana-domena.dns.com left intact

Z ripe.net vypliva, ze ISP ma zakupeny blok /22 a tato IP xxx.25.251.35 rozhodne patri ISP. Cize to smeruje na svoj nejaky win server.

Nova domena, ktora funguje bez problemov

curl -vkI nova-domena.dns.com
* Rebuilt URL to: nova-domena.dns.com/
*   Trying xx.103.29.165...
* TCP_NODELAY set
* Connected to nova-domena.dns.com (xx.103.29.165) port 80 (#0)
> HEAD / HTTP/1.1
> Host: nova-domena.dns.com
> User-Agent: curl/7.53.1
> Accept: */*
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Server: nginx/1.14.2
Server: nginx/1.14.2
< Date: Mon, 21 Feb 2022 18:39:01 GMT
Date: Mon, 21 Feb 2022 18:39:01 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 612
Content-Length: 612
< Last-Modified: Thu, 22 Apr 2021 18:10:24 GMT
Last-Modified: Thu, 22 Apr 2021 18:10:24 GMT
< Connection: keep-alive
Connection: keep-alive
< ETag: "6081bc10-264"
ETag: "6081bc10-264"
< Accept-Ranges: bytes
Accept-Ranges: bytes

< 
* Connection #0 to host nova-domena.dns.com left intact

Tato IP xx.103.29.165 je adresa skutocneho servera na ktorej sedi openvpn server.

Koniec koncov na novej domene vsetko funguje, ale nerozumiem preco ISP nasu domenu blokoval. Domena je tretieho radu vytvorena na free dns servery, mozno sa mu v tej domene nepacilo pismeno "x". Inak si to neviem vysvetlit.

A ked som vcera skusal ping a podobne srandy, tak sa zdalo, ze to funguje. Ono ping aj fungoval, ale ja som si nevsimol, ze to pinguje IP adresu, ktora patri ISP a nie openvpn serveru.

Ja nie som nijaky specialista na siete, ale myslim, ze toto co robi ISP nie je v sulade z beznym ISP.

[Peter Golis]

ale nerozumiem preco ISP nasu domenu blokoval

Skús sa na toto opýtať ISP, predpokladám že má nejakú linku podpory zákazníkov. Žeby tá DynDNS doména vypršala nevylučujem. V prípade zadarmových služieb im bolo treba odklepnúť že ich človek stále chce. Upozornenie chodieva emailom. Ale používam Dynamické DNS od inej firmy.

[jojo]

To je nezmysel, pretoze ta domena stale funguje normalne. U inych ISP neni blokovana.

Ked som sa pytal, tak ISP tvrdil, ze oni nic neblokuju (jedine zeby mal nejaky specialny script (soft), ktory domeny, podla nejakeho kluca presuva na blacklisty a ani sam ISP o tom nevie ).

[Jendа]

Pro začátek dig @dns.server.isp doména a dig @8.8.8.8 doména.

[jojo]

nemam dig, ale nslookup, neviem, ci tieto vysledky su obdobou z dig

nslookup ns1.isp.sk blokovana-domena.dns.com
Server:    192.168.55.1
Address 1: 192.168.55.1

Name:      ns1.isp.sk
Address 1: xxx.25.248.2 ns1.isp.sk

nslookup 8.8.8.8 blokovana-domena.dns.com
Server:    192.168.55.1
Address 1: 192.168.55.1

Name:      8.8.8.8
Address 1: 8.8.8.8 dns.google

[bigBRAMBOR]

192.168.55.1 ?

[jojo]

Ano je tam tato IP

[Jendа]

Teď to nechápu. Tam má být RFC1918 adresa a VPN funguje nějakým kouzlem že máš routu někudy? Potom to nemusí fungovat na některých DNS serverech, protože ty takové adresy blokují, a není to zlý úmysl. Nebo tam má být jiná adresa a ISP ti dělá MITM na DNS a mění odpovědi? Odjinud, a přes DoH/DoT se to přeloží správně? A jaktože výše píšeš, že se to překládá na veřejnou IP ISP, a tady najednou na RFC1918 IP?

[jojo]

192.168.55.1 je IP domaceho routeru, ale ma ho v sprave ISP.

[Jendа]

Jinak teda můj nslookup má parametry v pořadí host server a odpověď vypadá jinak, explicitně je tam že answer.

$ nslookup root.cz 8.8.8.8 
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	root.cz
Address: 91.213.160.188
Name:	root.cz
Address: 2001:67c:68::76

Každopádně jsme se jako od "blokovanie portu" dostali přes "blokuje mi DNS resolving" a "resolvuje se to na povdrženou adresu" po "resolvuje se to na RFC1918 adresu" a do naprostého zmatení. Tímto s diskuzí končím, protože to nikam nevede. Zkus to příště popsat líp.

[jojo]

Ja nie som specialista sietar a najprv som mal podozrenie na blokovanie portu. Nevadi, problem sa uz vyriesil.

[trekker.dk]

A pro jistotu nenapíšete jak, aby náhodou tahle debata nebyla užitečná někomu, kdo bude řešit něco podobného...?

[bigBRAMBOR]

na to snad nemusis byt nejaky extra specialista sietar

- ovpn server bezi na nejakem serveru, ten ma IP, prelozi DNS na spravnou IP - ANO/NE - spoji se VPN kdyz misto DNS pouziju v conf IP - ANO/NE - OVPN bezi na urciten portu, TCP nebo UDP, dostanu se na ten port - telnet, nc cokolit - ANO/NE

[Jendа]

No hlavně v #11 psal

Je uplne jasne, ze problem je u ISP. Skusil som telnet

telnet xx.xx.xx.xx 1194
telnet dyndns.dyn 1194

preslo to vporiadku.

přičemž telnet přelozenou adresu aktivně vypisuje

$ telnet nix.cz 80
Trying 93.190.134.171...
Connected to nix.cz.
Escape character is '^]'.

tak by si toho snad proboha všiml a pak zase že problém s DNS…

[bigBRAMBOR]

hmmm, to az tak podrobne nesledoval, ale vidim ze ty jsi vystupoval aktivne, tak frustraci chápu

[Jendа]

Pomohlo by shrnutí, co teda přesně zkusil a jaký byl výsledek.

[jojo]

Dospel som k tomuto zaveru, ale nie som sietar. Ako som pisal v #11 tak ping a telnet vracal odpoved OK. Cize som sa domnieval, ze domena ani IP neni blokovana. Mohol som aspon skusit v openvpn configu (client.conf) zmenit remote z dns name na IP adresu a ono by to fungovalo. Ani to som neskusil.

Aj ked sa zdalo ze ping je OK, lebo ocakavas nieco ako

64 bytes from xx.103.29.165: seq=0 ttl=243 time=21.068 ms
64 bytes from xx.103.29.165: seq=1 ttl=243 time=21.562 ms
64 bytes from xx.103.29.165: seq=2 ttl=243 time=21.648 ms

ale ono tam je toto

64 bytes from xxx.25.251.35: seq=0 ttl=61 time=2.092 ms
64 bytes from xxx.25.251.35: seq=1 ttl=61 time=2.193 ms
64 bytes from xxx.25.251.35: seq=2 ttl=61 time=2.197 ms

Mohlo ma napadnut uz pri time 2ms, ze nieco nie je v poriadku. Cize ping nesmeroval na Ip adresu ovpn servera, ale niekde na server ISP.

V #36 sa napisalo, ze doticny diskusiu konci. Ja som ale este skusil obratit dns a host a vysledky boli tieto

nslookup blokovana-domena.dns.com ns1.dns.sk
Server:    192.168.55.1
Address 1: 192.168.55.1

Name:      blokovana-domena.dns.com
Address 1: xxx.25.251.34 redirect.whalebone.io

Z toho sa da dedukovat, ze ISP pouziva whalebone a ani o tom nevie, ze nieco moze byt cez whalebone odfiltrovane (kedze mi tvrdil, ze nic neblokuje). Zhodou okolnosti som medzi tym od uplne ineho ISP (ktory tak isto vyuziva sluzby od whalebone) skusil ping a tak isto to vratilo IP adresu od ISP (a nie skutocnu IP adresu ovpn servera).

Cize dalsou opravou moze byt zmena DNS servera (u klienta, cize u mna). To som este zatial neskusil.

Neviem ci whalebone ma nejake blacklisty, ktore su verejne dostupne, ale problem bude najskor u whalebone.

[czjaromir]

No pokud používáte překlad jmen na adresy tak bych rozhodně měl vědět kam ukazuje. To znamená že doménový záznam je poskytovatele vpn. A jestli mám jen serverhosting s veřejkou bez záznamu pak se nemůžu odkazovat jménem ale pomocí IP.

[Andrej]

Mam od ISP privatnu IPv4 adresu.

Huh? Připoj se tam normálně přes IPv6. Nemá smysl řešit nějaký předpotopní nesmysl z roku 1975 (IPv4).

[czjaromir]

Jako jo rád bych přešel na IPv6 se všemi důsledky. Jen to že většina ISP to nemá. Nebo ano. A tunelovat IPv6 přes IPv4 to je kauf.

[[Jooky]]

Uz to IPv6 funguje aj niekde inde ako na katedre informatiky medzi jednym serverom a troma pracovnymi stanicami ? ...


... IPv4 proste funguje a to je fakt. IPv6 ma vacsina zariadeni ako dalsi stack a mam pocit, ze to velmi nemusia ani velky hraci ako Cisco a podobne. V praci sa zakaznik rozhodol mat celu NAS cast serverovej infrastruktury na IPv6 a stym su prakticky stale nejake problemy. Od takych, ze cely IPv6 stack na ciscu "zhasne" az po take, ze sa to rozhodne neprenasat IPv6 pre niektore pripojene zariadenia. Linux na tom nie je o nicom lepsie a ked nahodou nehneva cisco, tak samotny linux kernel. Realita je, ze v DC su tisice servrov a stale je nejaky "cisco bug", "netapp bug", "linux bug" a v konecnom dosledku ma zakaznik stale nejaky vypadok. Ja by som ratal, ze v 2022 to IPv6 pojde spolahlivejsie ... v office mame optiku od Orange, kde je primarne IPv6. Po niekolkych dnoch, kedy mi nahodne rozne veci nesli som rezignoval a na laptope si nadobro vypol IPv6 podporu. Od kedy som to spravil, tak zazrakom vsetko funguje aj u nas v office.