Collegare Sophos Firewall ad AWS Site-to-Site VPN

Un AWS Site-to-Site VPN collega una rete locale dietro Sophos Firewall a una VPC AWS o a un Transit Gateway. Tecnicamente è un VPN IPsec, ma nella pratica è diverso da un normale tunnel Sophos-to-Sophos: AWS crea due tunnel per ogni connessione VPN, usa oggetti Customer Gateway e gateway di destinazione, e il routing dipende dal fatto che si usino route statiche o BGP.

Questo articolo descrive l’implementazione pratica con Sophos Firewall e AWS. Integra la guida generale Configurare un VPN IPsec site-to-site Sophos Firewall con gli aspetti specifici di AWS: due tunnel, neighbor BGP, route tables, security groups, NACLs e controlli di stato in AWS e Sophos. Se il tunnel è già attivo ma il traffico non passa, è più adatta la guida Troubleshooting VPN IPsec Sophos Firewall.

Quando usare questo articolo

L’articolo è adatto quando una sede, un datacenter o una rete locale deve essere collegata ad AWS tramite Sophos Firewall. Copre AWS Site-to-Site VPN verso una VPC, un Virtual Private Gateway o un Transit Gateway. Non tratta Sophos Firewall come appliance virtuale installata direttamente in AWS.

Scenari tipici:

• rete server locale verso istanze EC2 in una VPC
• traffico di backup, monitoraggio o management verso AWS
• DNS ibrido, AD, jump host o reti amministrative
• migrazione da VPN statica a routing BGP dinamico
• esercizio ridondante con due tunnel AWS

AWS e Sophos usano termini diversi. In AWS si lavora con Customer Gateway, Virtual Private Gateway o Transit Gateway, Site-to-Site VPN connection, Tunnel Details, Route Tables, Security Groups e Network ACLs. Su Sophos Firewall entrano in gioco connessioni Amazon VPC, profili IPsec, interfacce XFRM, BGP, route e regole firewall.

Pianificare prima della configurazione

AWS Site-to-Site VPN non dovrebbe essere trattato come un semplice import di un file di esempio. Il file AWS è utile, ma la messa in produzione dipende da routing, security groups, NACLs, regole firewall e test con traffico reale.

Definire reti e gateway di destinazione

Prima di tutto va deciso quale lato AWS verrà usato:

• Virtual Private Gateway per una singola VPC classica.
• Transit Gateway per più VPC, più sedi o un design di routing più ampio.
• Cloud WAN o altre varianti solo se l’architettura AWS lo richiede esplicitamente.

Documentare in anticipo:

• CIDR della VPC AWS, per esempio 10.60.0.0/16
• subnet AWS e route tables rilevanti
• reti locali dietro Sophos Firewall, per esempio 172.16.20.0/24
• IP pubblico di Sophos Firewall o del router a monte
• modalità di routing: static o dynamic BGP
• ASN locale e AWS se si usa BGP
• target di test previsti su entrambi i lati
• opzioni tunnel previste, versione IKE, preshared keys e lifetimes

Le reti sovrapposte vanno risolte prima del design VPN. NAT over IPsec può funzionare, ma rende più difficili route tables, security groups, log e troubleshooting.

Prendere sul serio entrambi i tunnel

AWS crea due tunnel per ogni Site-to-Site VPN connection, ciascuno con un endpoint AWS diverso. Entrambi dovrebbero essere configurati e verificati su Sophos Firewall. Configurare un solo tunnel può andare bene in laboratorio, ma in produzione elimina la ridondanza AWS.

È importante avere l’aspettativa corretta: il ritorno da AWS preferisce un tunnel in base al routing e al lato AWS, e può passare all’altro in caso di guasto. Questo non significa che i due tunnel vengano sempre usati in modo bilanciato. Conta che entrambi salgano, che BGP o le route statiche siano corretti e che il failover sia stato testato.

Routing statico o BGP

AWS Site-to-Site VPN supporta route statiche e routing dinamico con BGP. BGP è di solito preferibile con più prefissi, espansioni future o Transit Gateway. Le route statiche sono più semplici, ma ogni cambio di rete deve essere mantenuto manualmente.

In pratica:

• BGP richiede ASN coerenti su entrambi i lati.
• Sophos Firewall deve annunciare i prefissi locali previsti.
• Le route tables AWS devono usare davvero le route propagate o statiche.
• Security groups e NACLs devono consentire il traffico.
• Route statiche e BGP identiche possono creare priorità inattese.

Preparare AWS

I passaggi seguenti descrivono il flusso tipico. I dettagli cambiano tra Virtual Private Gateway e Transit Gateway, ma il principio resta lo stesso.

Creare il Customer Gateway

Il Customer Gateway descrive in AWS il lato Sophos locale.

Inserire:

1. Nella console AWS andare in VPC > Virtual private network (VPN) > Customer gateways e scegliere Create customer gateway.
2. Impostare Name tag, per esempio cgw-sophos-hq.
3. Se si prevede di usare BGP, impostare BGP ASN esattamente sull’ASN Sophos locale. AWS mostra questo campo anche per le connessioni con routing statico, ma il routing statico non stabilisce un peering BGP.
4. In IP address inserire l’indirizzo statico raggiungibile da Internet del lato Sophos. Se il firewall è dietro un dispositivo NAT a monte, inserire nell’AWS Customer Gateway l’indirizzo IP pubblico di tale dispositivo NAT, non l’indirizzo dell’interfaccia WAN Sophos che si trova dietro di esso.
5. Facoltativamente inserire in Device un nome chiaro, quindi scegliere Create customer gateway.

Se Sophos Firewall si trova dietro un router o un dispositivo del provider, deve essere chiaro quale IP pubblico vede AWS e se NAT-T funziona correttamente. Per il Customer Gateway sono necessari UDP 500 e, quando si usa NAT-T, UDP 4500 tra la rete locale e gli endpoint AWS Site-to-Site VPN. Configurare il dispositivo NAT/firewall a monte in modo che consenta e inoltri queste porte tra l’interfaccia WAN Sophos e gli indirizzi di entrambi gli endpoint dei tunnel AWS indicati nel file di configurazione.

Creare o selezionare il gateway di destinazione

Per una singola VPC si crea di solito un Virtual Private Gateway in VPC > Virtual private network (VPN) > Virtual private gateways e lo si collega con Actions > Attach to VPC. Ambienti AWS più grandi usano spesso un Transit Gateway.

Verificare:

• Il gateway è collegato alla VPC o al Transit Gateway corretto.
• L’ASN lato AWS non confligge con l’ASN Sophos.
• Le route tables della VPC o del Transit Gateway sono pianificate.
• Le subnet usate per il test usano la route table corretta.

Creare la Site-to-Site VPN connection

Successivamente andare in VPC > Virtual private network (VPN) > Site-to-Site VPN connections e scegliere Create VPN connection.

Punti importanti:

• In Target gateway type selezionare il Virtual Private Gateway o Transit Gateway pianificato.
• In Customer gateway scegliere Existing e il Customer Gateway creato in precedenza.
• Impostare Routing options su Dynamic (requires BGP) o Static; in Static IP prefixes inserire solo i prefissi locali che AWS deve raggiungere tramite VPN.
• Verificare consapevolmente le Tunnel Options, soprattutto IKE version, encryption, integrity, DH/PFS e DPD.
• Documentare le preshared keys per tunnel o farle generare da AWS in modo intenzionale.

Per il routing dinamico, Sophos richiede che Local IPv4 Network Cidr e Remote IPv4 Network Cidr nella connessione AWS siano entrambi impostati su 0.0.0.0/0, affinché possa stabilirsi il peering BGP. Se sul firewall è già configurato un Local AS, inserire esattamente tale ASN per l’AWS Customer Gateway.

Dopo la creazione, scegliere Download configuration. Per l’importazione automatica Sophos, scegliere Vendor Sophos, Platform Sophos Firewall, Software v19+ e la IKE version effettivamente pianificata. Il file è solo una configurazione di esempio: algoritmi, gruppi DH, certificati e famiglia IP devono corrispondere al design di produzione. Dietro NAT, prima dell’importazione, inserire l’indirizzo locale dell’interfaccia WAN Sophos in entrambi i blocchi tunnel_outside_address lato customer gateway. Lasciare invariati gli endpoint Outside lato AWS; non sostituire indiscriminatamente ogni blocco XML con lo stesso nome. Nell’AWS Customer Gateway resta invece l’indirizzo pubblico del dispositivo NAT a monte. Per le route statiche, scegliere Generic e configurare manualmente. Anche BGP dinamico può essere configurato manualmente con il download Generic descritto di seguito; l’importazione Sophos non è l’unico percorso per BGP.

Verificare route tables, security groups e NACLs

Un tunnel VPN verde in AWS non significa ancora che un’istanza EC2 sia raggiungibile.

Per la validazione verificare:

• La route table della VPC contiene una route verso la rete locale tramite Virtual Private Gateway o Transit Gateway.
• Con Virtual Private Gateway, route propagation è attiva o la route è configurata staticamente.
• Le route tables del Transit Gateway contengono attachment e propagazioni corretti.
• Il security group dell’istanza di destinazione consente il traffico richiesto dalla rete locale.
• Le Network ACLs consentono andata e ritorno.
• Il firewall del sistema operativo dell’istanza non blocca il test.

Questo punto viene spesso dimenticato, perché Sophos e AWS possono mostrare entrambi un tunnel connesso anche se l’istanza non risponde per una security group o una route di ritorno errata.

Configurare Sophos Firewall

Sophos offre due percorsi pratici per AWS: import tramite Site-to-site VPN > Amazon VPC o configurazione manuale come connessione IPsec route-based. Per molti setup AWS l’import è il punto di partenza più pulito, ma gli oggetti creati automaticamente devono essere controllati.

Importare la configurazione AWS

In Site-to-site VPN > Amazon VPC, Sophos Firewall può importare la connessione mediante Use AWS security credentials oppure Use VPC configuration file. Per il metodo con credenziali, utilizzare un utente IAM AWS dedicato con i permessi richiesti per le impostazioni Site-to-Site VPN; proteggere e ruotare access key e secret key come gli altri segreti amministrativi.

L’importazione è un’istantanea. Se in AWS cambiano le opzioni del tunnel o altri valori della connessione, importare nuovamente le impostazioni e ripetere poi l’intera validazione. Un’importazione precedente non segue automaticamente la configurazione AWS.

La procedura seguente utilizza il file di configurazione AWS scaricato:

Procedura:

1. Aprire Sophos Firewall.
2. Andare in Site-to-site VPN > Amazon VPC.
3. Selezionare Use VPC configuration file.
4. Caricare il file di configurazione AWS.
5. Avviare l’import.
6. Verificare connessioni, profili IPsec, interfacce XFRM e impostazioni BGP create.

L’importazione crea profili IPsec, impostazioni BGP e interfacce XFRM. Aggiungere quindi i prefissi locali in Routing > BGP > Networks. In Administration > Device access, IPsec deve essere attivo per WAN e Dynamic Routing per VPN. Queste impostazioni consentono il traffico di controllo del tunnel e del routing; non sostituiscono una regola firewall per il traffico utile.

Dietro NAT, verificare in ciascuna delle due sezioni tunnel che tunnel_outside_address lato customer gateway contenga l’indirizzo WAN locale di Sophos. Non modificare gli indirizzi Outside lato AWS; l’indirizzo NAT pubblico resta l’indirizzo dell’AWS Customer Gateway. Se l’associazione non è chiara, non attivare il file né gli oggetti importati, ma identificare prima in modo univoco il lato cliente e il lato AWS.

Configurare manualmente due tunnel IPv4 VGW con BGP

Questa alternativa descrive una connessione IPv4 a un Virtual Private Gateway collegato alla VPC con Dynamic (requires BGP). Non è un runbook per IPv6/Transit Gateway/Cloud WAN e non afferma in modo generale che AWS non supporti IPv6. I prerequisiti sono permessi AWS, diritti amministrativi locali, endpoint Outside raggiungibili, reti non sovrapposte e un percorso di ritorno approvato. Non attivare contemporaneamente l’importazione e una configurazione manuale parallela per le stesse route.

1. In AWS, nella connessione VPN prevista, aprire Download configuration: Vendor Generic, Platform Generic, Software Vendor agnostic, IKE version ikev2. Questo vale espressamente anche per BGP dinamico manuale. Il file contiene PSK: conservarlo cifrato e con accesso limitato.
2. Per ogni tunnel, registrare separatamente endpoint Outside, PSK, CIDR Inside, indirizzo Inside del cliente, indirizzo Inside AWS e ASN dalla configurazione effettivamente generata. Utilizzare due reti /30 diverse accettate da AWS nell’intervallo 169.254.0.0/16; non utilizzare intervalli riservati o già in uso. La seguente mappatura è un esempio di pianificazione leggibile, non un’assegnazione da parte di AWS:

Tabella di mappatura: l’IP Outside stabilisce IPsec; l’IP Inside indirizza XFRM e BGP. Utilizzare esclusivamente gli indirizzi effettivamente forniti da AWS: non dedurre la propria assegnazione dall’ordine degli indirizzi dimostrativi. L’indirizzo XFRM di SFOS è l’indirizzo Inside del cliente, mai l’indirizzo Inside AWS o l’IP pubblico. Il neighbor BGP è l’indirizzo Inside AWS, non l’endpoint Outside.

3. Sotto Profiles > IPsec profiles > Add, creare un profilo personalizzato con un nome univoco. Un esempio circoscritto per tunnel configurati in questo modo su entrambi i lati è IKEv2, fase 1 AES256 / SHA2 256 / DH 14 (DH2048) e fase 2 AES256 / SHA2 256 / PFS 14 (DH2048). Abilitare Re-key connection; utilizzare Key negotiation tries 0 e Use strict profile disabilitato solo se previsto dal piano operativo approvato. Gli algoritmi e i gruppi DH/PFS selezionati devono formare una proposta comune consentita, non semplicemente avere lo stesso nome di profilo.
4. Documentare separatamente lifetime e Rekey/DPD. Un esempio storico indica per AWS fase 1 28800 secondi, ma per SFOS Key life 28000; fase 2 3600 su entrambi i lati, Rekey Margin 360 e Fuzz 50 percento. Timer locali di rekey IKEv2 diversi non sono automaticamente un errore di proposta e non dimostrano un’interoperabilità testata. Non adottare tacitamente un timer contraddittorio come standard universale: utilizzare i valori AWS effettivamente configurati e un piano di rekey SFOS approvato per tali valori; se le condizioni non sono chiare, fermarsi e chiarirle. Un esempio DPD è AWS Restart e SFOS con DPD abilitato, intervallo di controllo 30, attesa della risposta 120 secondi e Re-initiate. Questi valori sono un esempio di profilo da verificare, non una prescrizione universale. Prima dell’esercizio in produzione, confermare il comportamento Rekey/DPD nella propria finestra di modifica.
5. Sotto Site-to-site VPN > IPsec > Add, creare una connessione distinta per ogni tunnel con Connection type Route-based (Tunnel interface), IP version IPv4 e Gateway type Initiate the connection. Sotto Profile, selezionare il profilo personalizzato appena verificato, non un altro profilo predefinito chiamato IKEv2 senza controllarlo. Impostare Authentication type Preshared key e precisamente il PSK di questo tunnel. Listening interface è l’interfaccia WAN locale; Gateway address è il rispettivo endpoint Outside AWS. Impostare gli ID IKE locali/remoti solo secondo il piano delle identità effettivamente previsto, senza utilizzare IP casuali; dietro NAT, l’indirizzo WAN locale non equivale all’indirizzo pubblico del Customer Gateway. Selezionare Activate on save solo nella finestra approvata e dopo la verifica; salvare e attivare entrambe le connessioni.
6. Sotto Network > Interfaces, aprire l’XFRM associato alla rispettiva connessione e controllare il collegamento alla connessione. Sotto IPv4/netmask, inserire l’IP Inside del cliente e /30 (255.255.255.252) di questo tunnel. Per il secondo XFRM, utilizzare il suo specifico IP Inside; non invertire le associazioni.
7. Sotto Routing > BGP > Global configuration, mantenere il Local AS già in uso oppure impostare l’ASN del Customer Gateway approvato. Utilizzare una Router ID univoca e stabile tratta dal proprio piano. Non sovrascrivere un ASN globale esistente per questo VPN; AWS deve utilizzare lo stesso valore ASN locale. Non copiare intervalli ASN o ASN dimostrativi senza verificarli: controllare prima disponibilità, ammissibilità in AWS e assenza di conflitti. Sotto Neighbors, creare per ogni IP Inside AWS un neighbor IPv4 con Remote AS uguale all’ASN effettivo del VGW.
8. Sotto Routing > BGP > Networks, annunciare solo i prefissi autorizzati raggiungibili localmente. Sotto Administration > Device access, consentire IPsec per WAN e Dynamic Routing per VPN; non aggiungere un’apertura LAN generalizzata se non è previsto un peer di routing locale su quella rete. Aprire BGP TCP 179 come traffico dati a tutto Internet o tra tutte le reti LAN/VPN non sostituisce questa autorizzazione del piano di controllo. Creare inoltre le regole dati strettamente limitate descritte nella sezione seguente.
9. Per ogni neighbor, sotto Routing > Information > BGP > Neighbors, verificare Established e i prefissi appresi e annunciati previsti. In AWS, sotto Tunnel Details, verificare entrambi i tunnel UP e le route BGP; controllare la propagazione delle route VGW nelle Route Tables delle subnet interessate. Solo dopo testare il traffico applicativo consentito e una sorgente non autorizzata. Nella finestra concordata, disabilitare un tunnel in modo controllato, verificare che la route/l’applicazione prevista continui a funzionare attraverso l’altro, riattivarlo e controllare nuovamente entrambe le adiacenze; senza un effettivo test di failover, non dichiarare accettata la ridondanza.

In caso di errori IPsec, verificare prima per ogni tunnel endpoint, PSK, proposte, ID e NAT-T; con BGP Active, verificare prima indirizzi Inside XFRM, ASN, attivazione del peer e Device Access. Una route statica provvisoria con ping non è una riparazione BGP generale e può nascondere un percorso errato. Se scompaiono route esistenti o l’associazione lifetime/ID non è chiara, non provare altri valori, ma fermare la nuova configurazione e confrontarla con lo stato salvato.

Verificare profilo IPsec e tunnel

Dopo l’import, o in configurazione manuale, non bisogna fidarsi ciecamente del solo stato.

Verificare:

• Esistono entrambi i tunnel AWS.
• La versione IKE corrisponde alla configurazione AWS.
• Encryption, Authentication, DH Group e PFS definiscono per ciascun tunnel una proposta consentita da entrambi i lati; i lifetimes e i timer locali di rekey vengono verificati separatamente rispetto al piano approvato, senza ridurre la verifica alla sola uguaglianza numerica.
• La preshared key è corretta per ogni tunnel.
• Gateway type e remote gateway puntano agli endpoint AWS corretti.
• Le interfacce XFRM esistono e hanno nomi chiari.

Se vengono modificate le opzioni dei tunnel AWS, le proposte Sophos devono rimanere compatibili e i timer di rekey/DPD, documentati separatamente, devono essere conformi al piano operativo approvato. Modifiche unilaterali ad algoritmo, DH/PFS, PSK o identità possono impedire il completamento di Phase 1 o Phase 2; lifetimes IKEv2 locali diversi, da soli, non dimostrano un errore di questo tipo nelle proposte.

Configurare BGP o route statiche

Con BGP, sotto Routing > BGP verificare che ASN locale, neighbor, ASN remoto e reti annunciate siano corretti. Configurare BGP su Sophos Firewall spiega la configurazione e verifica complete. In Routing > Information > BGP, Neighbors, Summary e Routes dovrebbero mostrare i valori attesi.

Con routing statico, le route verso le reti AWS devono puntare all’interfaccia XFRM corretta. Anche AWS deve conoscere i prefissi locali, tramite route VPN statiche o tramite la route table corretta.

In entrambe le varianti, il routing deve essere corretto in entrambe le direzioni. Un tunnel può essere connesso mentre il ritorno passa da Internet, da un NAT Gateway o da una route table sbagliata.

Creare regole firewall

Route-based IPsec non crea automaticamente regole firewall produttive sufficientemente precise. Le regole devono essere create e loggate consapevolmente.

Raccomandato:

1. In Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule creare la regola locale-verso-AWS: Source zones LAN, Source networks and devices l’oggetto di rete locale, Destination zones VPN e Destination networks l’oggetto di rete AWS.
2. In Services selezionare solo i servizi necessari; usare Any solo temporaneamente per isolare un problema e poi sostituirlo.
3. Consentire la direzione opposta con Source zones VPN e Destination zones LAN solo se AWS deve raggiungere attivamente sistemi locali.
4. Abilitare Log firewall traffic per la validazione.
5. Verificare la posizione della regola prima di drop generali o catch-all.

Se la regola prevista non viene usata, consultare Regola Sophos Firewall non applicata: come trovare la causa.

Verificare la connessione

La validazione deve includere sempre entrambe le piattaforme e traffico applicativo reale. Il solo stato verde del tunnel non basta.

Verificare AWS

In AWS verificare:

• VPC > Site-to-Site VPN Connections > Tunnel Details mostra entrambi i tunnel.
• Lo stato tunnel è UP.
• Con BGP, le route sono visibili.
• La route table della VPC o del Transit Gateway contiene le route attese.
• Security groups e NACLs consentono il test.
• Metriche CloudWatch o VPN logs non mostrano problemi IKE o DPD ripetuti.

Verificare Sophos Firewall

Su Sophos Firewall verificare:

• Site-to-site VPN > Amazon VPC o Site-to-site VPN > IPsec mostra tunnel attivi.
• Routing > Information > BGP mostra neighbor e route apprese se si usa BGP.
• Network > Interfaces mostra le interfacce XFRM.
• Log Viewer mostra la regola firewall attesa.
• Packet Capture conferma interfaccia di ingresso e uscita se i log non bastano.

Scegliere bene il traffico di test

Un test deve usare host sorgente, host destinazione e servizio concreti, per esempio ICMP, RDP, SSH, HTTPS o DNS. Se ICMP è bloccato, ping non è significativo. Meglio testare il servizio che verrà davvero usato.

Errori tipici

Gli errori AWS VPN sembrano spesso problemi IPsec, anche quando la causa è routing o controlli di sicurezza AWS. I casi seguenti sono particolarmente frequenti.

È attivo un solo tunnel

Un tunnel basta per un primo test, ma non per un esercizio corretto. Entrambi i tunnel AWS hanno endpoint e parametri propri. Verificare per tunnel preshared key, parametri IKE/IPsec, interfaccia XFRM, neighbor BGP e stato AWS.

BGP non si stabilisce

Se il tunnel è connesso ma BGP non forma il peering, verificare prima ASN, IP del neighbor, annunci locali e indirizzi inside tunnel. Un caso Sophos ben delimitato si presenta quando il tunnel AWS VPC è attivo e connesso sul firewall, il neighbor BGP rimane in Active, AWS mostra la VPN come down mentre IPsec è up e la configurazione BGP attiva contiene no bgp default ipv4-unicast.

Solo se tutte queste caratteristiche coincidono, registrare la configurazione BGP attuale, il Local AS e l’IP del neighbor. Aprire quindi la console BGP tramite 3. Route Configuration > 1. Configure Unicast Routing > 3. Configure BGP e attivare esattamente il neighbor AWS interessato:

enable
conf t
router bgp <as-number>
neighbor <ip-address> activate
write

Sostituire <as-number> con l’ASN Sophos locale e <ip-address> con l’indirizzo inside tunnel del neighbor AWS interessato. Verificare quindi di nuovo il riepilogo BGP, i prefissi appresi e annunciati, lo stato del tunnel AWS e il traffico reale. Se no bgp default ipv4-unicast è assente o gli indirizzi e gli ASN AWS non corrispondono, non applicare questi comandi. Il comando proviene dalla procedura di troubleshooting SFOS 22 limitata alle connessioni Amazon VPC e non è una riparazione BGP generale.

Prima di conf t, documentare la configurazione BGP corrente e il metodo di ripristino approvato per l’ambiente. Se il neighbor non raggiunge Established o scompaiono route esistenti, non improvvisare e usare esclusivamente quel metodo già testato. Se tale metodo non esiste, fermarsi prima della modifica ed eseguire l’escalation al supporto Sophos.

Tunnel verde, istanza non raggiungibile

La causa è spesso fuori da IPsec: route table AWS errata, route propagation mancante, security group, NACL, firewall del sistema operativo, rete sorgente sbagliata o regola Sophos mancante.

Il ritorno segue il percorso sbagliato

AWS deve conoscere il ritorno verso la rete locale tramite VPN. Localmente, il ritorno verso la VPC AWS deve passare da XFRM o BGP. Routing asimmetrico può sembrare normale nello stato tunnel ma rompere sessioni reali.

MTU o frammentazione disturbano le applicazioni

AWS Site-to-Site VPN e overhead IPsec possono far emergere problemi MTU. Se piccoli test funzionano ma trasferimenti grandi o applicazioni specifiche si bloccano, verificare MSS/MTU, frammentazione e packet capture.

Esercizio e review

Dopo il go-live, il tunnel deve entrare nel normale processo operativo. Servono un owner, un processo documentato per le preshared keys, una finestra di change per i parametri IPsec, monitoraggio dei tunnel, test regolari di failover e una procedura chiara per cambi AWS o ISP.

Ogni modifica a CIDR VPC, routing Transit Gateway, route tables, security groups, reti locali o annunci BGP richiede una nuova validazione VPN. Il cloud VPN non è un clic una tantum, ma parte dell’architettura di rete.

Annullare in modo mirato nuovi tunnel e route

Prima della modifica, salvare backup, profili IPsec e associazione dei tunnel, indirizzi XFRM, neighbor/annunci BGP, regole firewall e Route Tables AWS con la relativa propagazione. In caso di annunci inattesi, destinazione errata o interruzione del traffico esistente, ritirare prima i prefissi appena introdotti oppure disabilitare la nuova connessione e ripristinare allo stato sicuro documentato solo le regole/route modificate. Non eliminare né reimpostare neighbor BGP esistenti, ASN globale e gateway/VPC/subnet condivisi. Controllare nuovamente le route esistenti previste, le applicazioni autorizzate e il blocco di una sorgente non autorizzata. Senza un percorso di ritorno approvato, fermare la modifica prima dell’attivazione.

FAQ