Problemi

Il comportamento in fase di impostazione della "policy di stato - di - Stato" per i firewall statici dal rilascio 5,1 è stato modificato. Nelle versioni precedenti al rilascio 5,1, se si imposta state -global -state -policy di un firewall stateful, il vRouter ha automaticamente aggiunto una regola implicita Allow per la comunicazione di ritorno della sessione automaticamente.

In uscita 5,1 e successivi, è necessario aggiungere un'impostazione di regola Allow sul IBM Cloud® Virtual Router Appliance. L'impostazione con stato funziona per le interfacce sui dispositivi Vyatta 5400 e per i protocolli sui dispositivi VRA.

Soluzioni alternative

Se la regola firewall-in viene applicata su un'interfaccia ingress / inside, allora è necessario applicare la regola Firewall-out sull'interfaccia egress / esterna. In caso contrario, il traffico di ritorno viene sganciato all'interfaccia egia/esterna.

Problemi di abilitazione stato

Se global-state-policy non è configurato, questa modifica della modalità di funzionamento non è interessata. Inoltre, se stai utilizzando l'opzione state enable in ciascuna regola invece di global-state-policy, la modifica della modalità di funzionamento non è interessata.

Problematiche di gestione zona locale

Non c'è alcuna pseudointerfaccia "local-zone" da assegnare alla politica di zona.

Soluzioni di gestione della zona locale

Questa modalità di funzionamento può essere simulata applicando un firewall basato sulle zone alle interfacce fisiche e un firewall interfaccia all'interfaccia loopback. Il firewall nell'interfaccia loopback filtra tutto quanto entra nel, ed esce dal, router.

Ad esempio:

set security zone-policy zone internal default-action 'drop'
set security zone-policy zone internal description 'Private zone'
set security zone-policy zone internal interface 'dp0bond0'
set security zone-policy zone internal to external firewall 'internal-2-external'
set security zone-policy zone internal to ovpn firewall 'internal-2-ovpn'

set security zone-policy zone ovpn default-action 'drop'
set security zone-policy zone ovpn description 'OpenVPN'
set security zone-policy zone ovpn interface 'vtun0'
set security zone-policy zone ovpn to external firewall 'ovpn-2-external'
set security zone-policy zone ovpn to internal firewall 'ovpn-2-internal'
 
set interfaces loopback lo firewall local 'Local'
 
set security firewall name ovpn-2-external default-action accept
set security firewall name ovpn-2-internal default-action accept
 
set security firewall name external-2-ovpn default-action accept
set security firewall name external-2-internal default-action accept
 
set security firewall name internal-2-external default-action accept
set security firewall name internal-2-ovpn default-action accept
 
set security firewall name Local default-action 'drop'
set security firewall name Local 'default-log'
set security firewall name Local rule 10 action 'accept'
set security firewall name Local rule 10 description 'RIP' ("/opt/vyatta/etc/cpp.conf" )

Ordine delle questioni di funzionamento

In uno scenario in cui Masquerade Source NAT è distribuito su un IBM Cloud® Virtual Router Appliance, non è possibile utilizzare il firewall per determinare l'accesso per gli host a internet. Questo perché l'indirizzo post NAT è lo stesso.

Per i dispositivi Vyatta 5400, questa operazione era possibile perché il firewalling veniva eseguito prima della NAT, consentendo la limitazione dell'accesso a Internet agli host.

Ordine di lavoro di funzionamento

Per la VRA è richiesto un nuovo schema di routing:

Problematiche della tabella di routing basata sulla politica

La parola "Tabella" nelle configs è opzionale in v5400 routing basato sulla politica. Tuttavia, per la VRA, se l'azione è accept, allora il campo Tabella è obbligatorio. Se l'azione è drop nella configurazione VRA, il campo Table è facoltativo.

Soluzioni di lavoro della tabella di routing basata sulla politica

"Table Main" è un'opzione disponibile in Vyatta 5400 routing basato sulla politica. L'equivalente in VRA è "routing-instance default".

Instradamento basato sulla politica sulle problematiche dell'interfaccia tunnel

Sulla IBM Cloud® Virtual Router Appliance PBR (Policy - Based Routing), le policy possono essere applicate alle interfacce del piano dati per il traffico in entrata, ma non alle interfacce di loopback, tunnel, bridge, OpenVPN, VTI e IP non numerate.

Instradamento basato sulla politica sulle soluzioni di lavoro dell'interfaccia tunnel

Non ci sono attualmente delle soluzioni temporanee per questo problema.

Problematiche OpenVPN

OpenVPN non inizia a funzionare quando si utilizza il parametro push-route su IBM Cloud® Virtual Router Appliance.

Soluzioni di lavoro OpenVPN

Utilizza il parametro openvpn-option invece di push-route.

GRE/VTI su problemi IPSEC + OSPF

• Quando VIF ha più sottoreti configurate, il traffico non può attraversare tali sottoreti nella VRA.
• L'instradamento InterVlan non sta funzionando sulla VRA.

GRE/VTI su IPSEC + OSPF workarounds

Utilizza le regole di consenso implicito per accettare il traffico attraverso le interfacce VIF.

Problematiche IPsec

IPSec (basato sui prefissi) non funziona con il filtro IN.

Soluzioni di lavoro IPsec

Utilizza IPSec (BASATO SU VTI).

IPSEC "match-none" problematiche

Con i dispositivi Vyatta 5400, è consentita la seguente regola firewall:

set firewall name allow rule 10 ipsec

Tuttavia, con IBM Cloud® Virtual Router Appliance, non c'è alcun IPSec.

Soluzioni di lavoro IPSEC "match-none"

Regole alternative possibili per i dispositivi VRA:

   match-ipsec  Inbound IPsec packets
   match-none   Inbound non-IPsec packets                                                                                                                

I problemi di IPSEC "match-ipsec"

Con i dispositivi Vyatta 5400, sono consentite le seguenti regole firewall:

set firewall name OUTSIDE_LOCAL rule 50 action 'accept'
set firewall name OUTSIDE_LOCAL rule 50 ipsec 'match-ipsec'

Tuttavia, con IBM Cloud® Virtual Router Appliance, non c'è alcun IPSec.

IPSEC ' match-ipsec " le soluzioni di lavoro

Aggiungi i protocolli ESP e AH (rispettivamente i protocolli IP 50 e 51).

La regola action può essere accept o drop, come mostrato nel seguente esempio:

set security firewall name <name> rule <rule-no> action accept
set security firewall name <name> rule <rule-no> destination port 500
set security firewall name <name> rule <rule-no> protocol udp
set security firewall name <name> rule <rule-no> action accept
set security firewall name <name> rule <rule-no> destination port 4500
set security firewall name <name> rule <rule-no> protocol udp
set security firewall name <name> rule <rule-no> action accept
set security firewall name <name> rule <rule-no> protocol ah
set security firewall name <name> rule <rule-no> action accept
set security firewall name <name> rule <rule-no> protocol esp

Sito - to - site IPsec con problemi DNAT

IPSec (basato sui prefissi) non funziona con DNAT.

server (10.71.68.245) -- vyatta 1 (11.0.0.1)
===S-S-IPsec=== (12.0.0.1)
vyatta 2 -- client (10.103.0.1)
Tun50 172.16.1.245

Il frammento di codice precedente è un piccolo esempio di setup per la traduzione DNAT dopo che un pacchetto IPsec viene decodificato in una Vyatta 5400. In questo esempio ci sono due Vyattas, vyatta1 (11.0.0.1) e vyatta2 (12.0.0.1). Il peering IPsec viene stabilito tra 11.0.0.1 e 12.0.0.1. In questo caso, il client ha come destinazione 172.16.1.245 originato dall'end-to-end 10.103.0.1. Il comportamento atteso di questo scenario è che l'indirizzo di destinazione 172.16.1.245 si traduce in 10.71.68.245 nell'intestazione del pacchetto.

Inizialmente, il dispositivo Vyatta 5400 stava eseguendo DNAT sull'IPSec in entrata, terminando l'interfaccia e restituendo il traffico normalmente nel tunnel IPsec utilizzando la tabella di traccia della connessione.

Su IBM Cloud® Virtual Router Appliance, la configurazione non funziona nello stesso modo. La sessione viene creata, tuttavia il traffico di restituzione esclude il tunnel IPsec dopo che la tabella di traccia della connessione ha invertito la modifica DNAT.La VRA invia quindi il pacchetto in transito senza la crittografia IPsec. Il dispositivo a monte non si aspetta questo traffico e lo elimina molto probabilmente. Mentre la connettività end-to-end è spezzata, questo è il comportamento previsto.

Sito - to - site IPsec con soluzioni di lavoro DNAT

Per ospitare questo scenario di networking, IBM ha creato un RFE.

Mentre il RFE è attualmente in fase di valutazione, si consiglia il seguente workaround:

Comandi di configurazione dell'interfaccia

set interfaces dataplane dp0p192p1 address '11.0.0.1/30'
set interfaces dataplane dp0p224p1 address '10.0.0.2/30'
set interfaces dataplane dp0p224p1 policy route pbr 'Backwards-DNAT'
set interfaces loopback lo address '169.254.1.1/24'
set interfaces tunnel tun50 address '169.254.240.1/32'
set interfaces tunnel tun50 encapsulation 'gre'
set interfaces tunnel tun50 local-ip '169.254.1.1'
set interfaces tunnel tun50 remote-ip '169.254.1.1'

Comandi di configurazione VPN

set security vpn ipsec esp-group ESP lifetime '30000'
set security vpn ipsec esp-group ESP proposal 1 encryption 'aes128'
set security vpn ipsec esp-group ESP proposal 1 hash 'sha1'
set security vpn ipsec ike-group IKE lifetime '60000'
set security vpn ipsec ike-group IKE proposal 1 encryption 'aes128'
set security vpn ipsec ike-group IKE proposal 1 hash 'sha1'
set security vpn ipsec site-to-site peer 12.0.0.1 authentication mode 'pre-shared-secret'
set security vpn ipsec site-to-site peer 12.0.0.1 authentication pre-shared-secret 'thekey'
set security vpn ipsec site-to-site peer 12.0.0.1 default-esp-group 'ESP'
set security vpn ipsec site-to-site peer 12.0.0.1 ike-group 'IKE'
set security vpn ipsec site-to-site peer 12.0.0.1 local-address '11.0.0.1'
set security vpn ipsec site-to-site peer 12.0.0.1 tunnel 1 local prefix '172.16.1.245/30'
set security vpn ipsec site-to-site peer 12.0.0.1 tunnel 1 remote prefix '10.103.0.0/24'

Comandi di configurazione NAT

set service nat destination rule 10 destination address '172.16.1.245'
set service nat destination rule 10 inbound-interface 'tun50'
set service nat destination rule 10 source address '10.103.0.1'
set service nat destination rule 10 translation address '10.71.68.245'
set service nat source rule 10 destination address '10.103.0.1'
set service nat source rule 10 'log'
set service nat source rule 10 outbound-interface 'tun50'
set service nat source rule 10 source address '10.71.68.245'
set service nat source rule 10 translation address '172.16.1.245'

Comandi di configurazione dei protocolli

set protocols static interface-route 172.16.1.245/32 next-hop-interface 'tun50'
set protocols static table 50 interface-route 0.0.0.0/0 next-hop-interface 'tun50'

Comandi di configurazione PBR

set policy route pbr Backwards-DNAT description 'Get return traffic back to tunnel for DNAT'
set policy route pbr Backwards-DNAT rule 10 action 'accept'
set policy route pbr Backwards-DNAT rule 10 address-family 'ipv4'
set policy route pbr Backwards-DNAT rule 10 destination address '10.103.0.0/24'
set policy route pbr Backwards-DNAT rule 10 source address '10.71.68.0/24'
set policy route pbr Backwards-DNAT rule 10 table '50'

Problematiche PPTP

PPTP non è più supportato in IBM Cloud® Virtual Router Appliance.

PPTP iorkarounds

Utilizza invece il protocollo L2TP.

Script per i problemi di riavvio IPsec

Ogni volta che un indirizzo virtuale VRRP viene aggiunto a una IBM Cloud® Virtual Router Appliance su una VPN ad alta disponibilità, devi reinizializzare il daemon IPsec. Ciò è dovuto al fatto che il servizio IPsec è in ascolto solo per le connessioni agli indirizzi presenti nella VRA quando viene inizializzato il daemon IKE.

Per una coppia di VRAs con VRRP, il router in standby potrebbe non avere l'indirizzo virtuale VRRP presente sul dispositivo durante l'inizializzazione se il router master non ha quell' indirizzo presente. Pertanto, per reinizializzare il daemon IPsec quando si verifica una transizione dello stato VRRP esegui questo comando sui router master e di backup:

interfaces dataplane interface-name vrrp vrrp-group group-id notify

Recente conteggio e problemi del tempo recenti

L'intento della seguente regola è limitare le connessioni SSH a 3 ogni 30 secondi per SSH utilizzando qualsiasi indirizzo:

set firewall name localGateway rule 300 action 'drop'
set firewall name localGateway rule 300 description 'Deter SSH brute force'
set firewall name localGateway rule 300 destination port '22'
set firewall name localGateway rule 300 protocol 'tcp'
set firewall name localGateway rule 300 recent count '3'
set firewall name localGateway rule 300 recent time '30'
set firewall name localGateway rule 300 state new 'enable'

Su IBM Cloud® Virtual Router Appliance, questa regola ha i seguenti problemi:

• L'opzione per il conteggio recente e il tempo recente è stata dichiarata obsoleta.
• A causa del precedente rilascio, la regola non può funzionare come previsto e blocca tutte le connessioni SSH all'interfaccia applicata.

Recenti e recenti soluzioni di lavoro

Utilizza invece CPP.

Impostare i problemi delle problematiche di sistema

set system conntrack expect-table-size '8192'
set system conntrack hash-size '375000'
set system conntrack modules ftp 'disable'
set system conntrack modules 'gre'
set system conntrack modules h323 'disable'
set system conntrack modules nfs 'disable'
set system conntrack modules pptp 'disable'
set system conntrack modules sip 'disable'
set system conntrack modules sqlnet 'disable'
set system conntrack modules tftp 'disable'
set system conntrack table-size '3000000'

Impostare i problemi di timeout di connetttrack

set system conntrack timeout icmp '30'
set system conntrack timeout other '600'
set system conntrack timeout tcp close '10'
set system conntrack timeout tcp close-wait '60'
set system conntrack timeout tcp established '432000'
set system conntrack timeout tcp fin-wait '120'
set system conntrack timeout tcp last-ack '30'
set system conntrack timeout tcp syn-recv '60'
set system conntrack timeout tcp syn-sent '120'
set system conntrack timeout tcp time-wait '60'

Problematiche firewall basate sul tempo

set firewall name PRIV_SERVICE_IN rule 58 action 'accept'
set firewall name PRIV_SERVICE_IN rule 58 description '586427 Acesso a base de dados ate 22-2-18'
set firewall name PRIV_SERVICE_IN rule 58 destination address '10.150.156.57'
set firewall name PRIV_SERVICE_IN rule 58 destination port '3306'
set firewall name PRIV_SERVICE_IN rule 58 protocol 'tcp'
set firewall name PRIV_SERVICE_IN rule 58 source address '10.150.156.104'
set firewall name PRIV_SERVICE_IN rule 58 time startdate '2017-08-22'
set firewall name PRIV_SERVICE_IN rule 58 time stopdate '2018-02-22'

Questioni TCP-MSS

set interfaces tunnel tun3 address '172.17.175.45/30'
set interfaces tunnel tun3 encapsulation 'gre'
set interfaces tunnel tun3 local-ip '169.55.223.76'
set interfaces tunnel tun3 mtu '1476'
set interfaces tunnel tun3 multicast 'disable'
set interfaces tunnel tun3 policy route 'change-mss'(in 18.x unable to apply tcp-mss using PBR only option is to set on interface directly which i believe is not equivalent to pbr .
set interfaces tunnel tun3 remote-ip '104.129.200.34'

set policy route change-mss rule 1 protocol 'tcp'
set policy route change-mss rule 1 set tcp-mss '1436'
set policy route change-mss rule 1 tcp flags 'SYN

Applicazione specifica o porta spezzata in problematiche VPN S-S IPsec

vyatta@v5600dallas09# set security vpn ipsec site-to-site peer 12.0.0.1 tunnel 1 remote
Possible Completions:
   <Enter> Execute the current command
   port    Any TCP or UDP port
   prefix  Remote IPv4 or IPv6 prefix                                                                                                                                     set security vpn ipsec esp-group ESP lifetime '30000'
set security vpn ipsec esp-group ESP proposal 1 encryption 'aes128'
set security vpn ipsec esp-group ESP proposal 1 hash 'sha1'
set security vpn ipsec ike-group IKE lifetime '60000'
set security vpn ipsec ike-group IKE proposal 1 encryption 'aes128'
set security vpn ipsec ike-group IKE proposal 1 hash 'sha1'
set security vpn ipsec site-to-site peer 12.0.0.1 authentication mode 'pre-shared-secret'
set security vpn ipsec site-to-site peer 12.0.0.1 authentication pre-shared-secret 'thekey'
set security vpn ipsec site-to-site peer 12.0.0.1 default-esp-group 'ESP'
set security vpn ipsec site-to-site peer 12.0.0.1 ike-group 'IKE'
set security vpn ipsec site-to-site peer 12.0.0.1 local-address '11.0.0.1'
set security vpn ipsec site-to-site peer 12.0.0.1 tunnel 1 local prefix '172.16.1.245/30'
set security vpn ipsec site-to-site peer 12.0.0.1 tunnel 1 remote prefix '10.103.0.0/24'                                          set security vpn ipsec site-to-site peer 12.0.0.1 tunnel 1 remote port 21 (ftp)

Modifica significativa delle problematiche di funzionamento della registrazione

Si è verificato un importante cambiamento nella modalità di funzionamento della registrazione tra il dispositivo Vyatta 5400 e IBM Cloud® Virtual Router Appliance: da registrazione per sessione a registrazione per pacchetto.

• Registrazione sessione: registra le transizioni di stato delle sessioni con stato
• Registrazione pacchetto: registra tutti i pacchetti che corrispondono alla regola. Poiché la registrazione dei pacchetti viene registrata nel file di log in "unità di pacchetto", vi è una marcata diminuzione della velocità di trasmissione e la pressione della capacità del disco.
• La funzionalità di registrazione del vRouter può essere utilizzata per acquisire l'attività del firewall. Come per qualsiasi altra funzione di registrazione, devi abilitarla solo se stai risolvendo uno specifico problema e disabilitarla appena puoi.

Il firewall stateful, che gestisce le sessioni Firewall / NAT, scrive in "unità di sessione". Si consiglia di utilizzare la registrazione sessione. Viene descritto ogni esempio di impostazione.