Neko vas puškom tera da migrirate na Google cloud, a ne na Azure/Amazon?

Nisi glup. :)

Ja bi probao :

- Da promenim MTU. (Znam, znam... ali probaj).
- Da umesto tog FreeSwan (koristio pre X godina, smara) dignem lepo u VPC-u na GCloud-u svoj firewall, mozes ASAv, mozes i samo npr. pfSense i da probas sa njim.

Ja nagadjam da problem nije do GCloud-a vec do tog "provajdera" i tog FreeSwan koji su nakalemili. Ako imas dva 6880 javlja mi se da mozes da cimnes i dobijes makar trial za ASAv, to ti je najbrze resenje. Mislim da mu je limit 10Mbit/s, ali za probu ti je dosta.

Mi se ne pitamo, to je odluka druge strane, na žalost.

Majstori su tražili da promenim MTU na outside interfejsu. A to će se onda odraziti na sve tunele. Malo mi ova muka... :)

A što se labuda tiče, ja se tu ne pitam ništa. Ja ne mogu da radim ništa u Gcloud-u. Samo da se nakačim na njega. I da plačem :(

Jebemliga..... Escalate? Trazi menadzera? Zovi svog menadzera/CTO-a/koga vec da ih cima. Ili promeni MTU, sta da ti kazem..... moguce da malo veci pakti probijaju limit, jer ima nekoliko "slojeva" pakovanja paketa u paket u paket...

Nema razloga da menjas MTU na outside interface-u, ali, cisto da razjasnimo, probao si da smanjis MTU na tunnel interface-u? Taj deo mi nije najjasniji iz prve poruke.

Vidi ovo: ping sa aerodromskog Core sviča

BEGAP-Area2_CoreVSS#ping 10.0.12.68 sou vlan 107 df-bit size 1000
Type escape sequence to abort.
Sending 5, 1000-byte ICMP Echos to 10.0.12.68, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1
Packet sent with the DF bit set
!!!.!
Success rate is 80 percent (4/5), round-trip min/avg/max = 24/25/28 ms
BEGAP-Area2_CoreVSS#

Bez df bita:

BEGAP-Area2_CoreVSS#ping 10.0.12.68 sou vlan 107
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.12.68, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/24/24 ms
BEGAP-Area2_CoreVSS#ping 10.0.12.68 sou vlan 107
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.12.68, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/24/24 ms
BEGAP-Area2_CoreVSS#ping 10.0.12.68 sou vlan 107
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.12.68, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/24/28 ms
BEGAP-Area2_CoreVSS#ping 10.0.12.68 sou vlan 107
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.12.68, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1
!.!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 24/24/24 ms
BEGAP-Area2_CoreVSS#


ASA:

JU-Internet-FW/pri/act# sh cry ipsec sa pee 34.65.86.117
peer address: 34.65.86.117
Crypto map tag: STAT_MAP, seq num: 3, local addr: 91.194.216.5

access-list IPSEC-Airserbia-AMOS_Swiss_DE extended permit ip 192.168.10.0 255.255.255.0 10.0.12.0 255.255.255.0
local ident (addr/mask/prot/port): (192.168.10.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.0.12.0/255.255.255.0/0/0)
current_peer: 34.65.86.117


#pkts encaps: 20421, #pkts encrypt: 20446, #pkts digest: 20446
#pkts decaps: 21096, #pkts decrypt: 21096, #pkts verify: 21096
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 20421, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 25, #pre-frag failures: 0, #fragments created: 50
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 57
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#send errors: 0, #recv errors: 0

local crypto endpt.: 91.194.216.5/500, remote crypto endpt.: 34.65.86.117/500
path mtu 1500, ipsec overhead 74(44), media mtu 1500
PMTU time remaining (sec): 0, DF policy: clear-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: 1B9700B9
current inbound spi : E96E835F

Zato kažem da je problem skroz lud ;(

A što se menadžera i eskalacije tiče, nemam kome. Sam sam u ovom s*anju. Tebi bezgranično hvala što odvajaš vreme na ovo. Stisnuću pa ću probati da smanjim MTU. Mada mi je strepnja dublja od nade da će to išta promeniti.

Ne, to nisam probao. Jel grešim ako kažem da MTU može samo globalno da se menja? A na ping nikad nisam dobio onaj čuveni odgovor

''Packet needs to be fragmented but DF set.''

Ovo dole sam dodao u konfiguraciju:

crypto ipsec security-association lifetime seconds 10800
crypto ipsec security-association pmtu-aging infinite
crypto ipsec df-bit clear-df outside

Da me ne zeza nešto od toga?

Da dodam na ovu poruku:

TCP MSS mi je na default vrednosti, 1380. Ima do 1500 dovoljno da se napakuju svi hederi koje dodaju esp i ostali drugari. Ili da ga spustim?

Jako cudno, sad sam radio trace do ipsec peer-a 34.65.86.117, ovo ode u Ameriku.
Nek prebace taj cloud u Sofiju :)

Da, znam. Kad sam im rekao da to ide u USA bilo je ''Ma neeeee, to nam je u Cirihu''. Nemoj Sofiju molim te! Stalno im neko seče optiku, malo malo pa mi stigne mail od jednog od provajdera čije usluge koristimo za neki levi servis: E, sine, opet nam neko cviknuo kabl. Saćemo mi to, samo da nađemo splajsere.

Ne, mozes da ga menjas na nivou (tunnel) interface-a, tako da naravno nikad ne predje ono sto ce na kraju biti na izlaznom interface-u.




Deluje ok taj deo.



Trebalo bi da, medjutim bitna je i druga strana. Probaj da spustis, to je svakako najjednostavnije izmeniti.

Google se najblize vide preko SOX-a, bas taj DC u Sofiji i to je poznato kao jako nestavilna veza, od pocetka godine bilo je 5-6 fiber cut-ova.
Da sam na tvom mestu, u nekom Cloud-u bih digao na virutualki ovaj softver strongSwan ili negde lokalno, treba ti IP veza do ASE, pa udri po testiranju.

Sto se tice 34.65.86.117, moguce da je anycast adresa, ali.. meni bar, ne ide dalje od Ciriha.

http://lg.telekom.rs/cgi-bin/b...raceroute&req=34.65.86.117

Takodje pokazuje da je zadnji vidljiv hop u ZH.

Probaću. Ne smem sad, moraću da sačekam neko vreme kad mi na mreži ne bude gužva. U svakom slučaju javljam šta sam uradio. I hvala na pomoći!

Ima i sam Google neke hintove, pre par godina sam se i ja zezao kreiranjem IPSec tunela do GC i čačkanjem oko MTU jer je konekcija bila užasno spora, i vidim da je njihov vodič i dalje tu, doduše malo izmenjen:

https://cloud.google.com/vpn/docs/concepts/mtu-considerations

Trial verzija ima sve opcije otkljucane, ali samo 100Kbps protok. Mora licenca za brze...

Pa i to mu je dosta da proba...

Evo moze i privremeno da se koriste-aktiviraju licence dok traje Korona

https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/215330-obtaining-an-emergency-covid-19-anyconne.html




Sad videh da je samo za Anyconnect. Pardon.

Ispratio sam i ovaj dokument, pola noći se mlatio i ništa. Apsolutno isto.

Moraću da cimnem Cisco TAC još jednom, ali ću uključiti i Google ekipu (ako pristanu) pa da zajedno pokušamo da se izborimo sa ovim.

Nikad na ovako nešto nisam naleteo. Mikrotik, Baracuda, Juniper, Palo Alto, Checkpoint, svi oni su mi bili sa druge strane i nikad ni jedan problem. Baracuda mi je prvi VPN gateway sa kojim sam radio tunel sa digitalnim sertifikatom (na mojoj strani bio 1841) i to pre nekih 7-8 godina. I sve je svaki put prolazilo bez greške i bez frke. A ovo g*vno... Neverovatno. Hvala vam svima na pomoći. Idem da sednem ispred prozora i da tiho jecam nad svojom tužnom sudbinom.

There, there....

Posto tebi generalno tunel radi, ali problem je u performansama, pogledaj da ne fragmentujes enkriptovani IPSec saobracaj i/ili da ti cloud ne salje fragmente - ne radim sa cisco dugo, ne mogu konkretan primer da ti dam, ali pretpostavljam da ces naci lako acl koji ce smo brojati fragmentovane pakete na eksternom interface-u.
Ako ti je to cisto - bez fragmenta, stavi slican acl prema aplikativnom serveru i od njega, da vidis da se ne desava pre-fregmentacija na strani google-a.

Da, tunel radi stabilno, performanse su krš. Fragmentaciju saobraćaja radim pre enkripcije:

JU-Internet-FW/pri/act# sh crypto ipsec fragmentation outside
fragmentation outside before-encryption


Iskreno, ne znam kako mogu da proverim da li Google pravi problem. :(

Čitam i gledam i dalje, ne mogu ovo da pustim da ostane ovako. Iskopaću ga, da *ebe oca.

Pa jel ti TCP ta aplikacija? Fregmentacija se izbegava gde god je moguce. Podesi MSS na 1300 - ako je TCP pa vidi da li imas fragmentaciju.

Jeste, otvara neke visoke portove. A igrao sam se i sa MSS-om (hvala Vuče), nije pomoglo.

JU-Internet-FW/pri/act# sh run all sysopt
no sysopt traffic detailed-statistics
no sysopt connection timewait
sysopt connection tcpmss 1300 ------------------------->menjao vrednost (od 576 pa na dalje i ostavio na ovoj)
sysopt connection tcpmss minimum 0
no sysopt connection permit-vpn
sysopt connection reclassify-vpn
sysopt connection preserve-vpn-flows

Pitao sam ovog tipa iz Google Cloud support-a koliki je njegov MSS, još čekam odgovor. 5 dana...

Jesu Azure i AWS ovakvi? Mislim ima li i sa njima ovakvih problema? Čeka me još par migracija, ali na ova dva pomenuta.
Ako bude ovako, roknuću se preventivno.

_{[Ovu poruku je menjao dvidovic dana 17.04.2020. u 13:08 GMT+1]}

Sad sam procitao ceo thread, vec su ljudi rekli sta su imali vezano za mss, ja sam bespotrebno ponavljam, a ti gubis icmp, tako da ne znam, tcpdump na klijent i server i onda ping, pa kad ne prodje paket vidi gde je nestao - u kom smeru za pocetak...

Samo salji mail-ove.. ovih dana su svi u poslu zbog globalne situacije, pa nesto sto mozda nije prioritet bude izostavljeno.

Stigao i odgovor. Odlažemo migraciju na 6 meseci zato što su primetili da postoje određeni problemi na njihovoj strani i da će im trebati vremena (uzevši u obzir i tekuću situaciju sa COVID-19 virusom) da sve to ispeglaju. Pride su se i izvinili na vremenu koje smo potrošili na ovaj posao. Zbog velikog broja uloženih čovek-sati, a u dogovoru sa našim servis provajderom Google će pokriti naše troškove za tih 6 meseci. Nije neka kinta, ali lepo od njih.

Bar sad znaš da nisi lud. :D

Mao je falilo :)