IBM Cloud Docs
Gängige Migrationsprobleme mit Vyatta 5400

Gängige Migrationsprobleme mit Vyatta 5400

In den folgenden Abschnitten sind gängige Probleme und Verhaltensänderungen aufgeführt, die nach einer Migration von einem Vyatta 5400-Gerät auf IBM Cloud® Virtual Router Appliance auftreten können. In einigen Fällen sind Problemumgehungen angegeben.

Schnittstellenbasierte Richtlinie mit globalem Status für statusabhängige Firewall

Probleme

Das Verhalten beim Festlegen des Status der Statusrichtlinie für statusabhängige Firewalls aus Release 5.1 wurde geändert. Wenn Sie in Versionen vor Release 5.1 state -global -state -policy für eine statusabhängige Firewall festgelegt haben, fügte der vRouter automatisch eine implizite Allow-Regel für die Rückgabekommunikation der Sitzung hinzu.

In Release 5.1 und späteren Versionen müssen Sie eine Allow-Regeleinstellung in IBM Cloud® Virtual Router Appliance hinzufügen. Die statusabhängige Einstellung funktioniert für Schnittstellen auf Vyatta 5400-Geräten und für Protokolle auf VRA-Geräten.

Behelfslösungen

Falls die Regel firewall-in für eine Ingress-Schnittstelle bzw. innere Schnittstelle gilt, muss die Regel Firewall-out auf die Egress-Schnittstelle oder äußere Schnittstelle angewendet werden. Andernfalls wird der rücklaufende Datenverkehr an der Egress-Schnittstelle bzw. der äußeren Schnittstelle gelöscht.

'state-enable' in Firewallregeln

Probleme mit Statusaktivierung

Falls global-state-policy nicht konfiguriert ist, ist diese Verhaltensänderung nicht betroffen. Wenn Sie statt state enable die Option global-state-policy in jeder einzelnen Regel verwenden, ist diese Verhaltensänderung ebenfalls nicht betroffen.

Zonenbasierte Richtlinie: Handhabung einer lokalen Zone

Probleme bei der Handhabung lokaler Zonen

Es gibt keine Pseudoschnittstelle für eine lokale Zone, die der Zonenrichtlinie hinzugefügt werden kann.

Ausweichlösungen für die Handhabung lokaler Zonen

Dieses Verhalten kann simuliert werden, indem Sie eine zonenbasierte Firewall auf physische Schnittstellen anwenden und eine schnittstellenbasierte Firewall auf die Loopback-Schnittstelle. Die Firewall in der Loopback-Schnittstelle filtert den gesamten Datenverkehr an den und vom Router.

Beispiel:

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" )

Verarbeitungsreihenfolge für Firewalls, NAT, Routing und DNS

Probleme bei der Reihenfolge von Operationen

In einem Szenario, in dem Masquerade-Source-NAT auf IBM Cloud® Virtual Router Appliance bereitgestellt wird, können Sie die Firewall nicht verwenden, um den Internetzugriff für Hosts festzulegen. Der Grund ist, dass die nachfolgende NAT-Adresse dieselbe ist.

Bei Vyatta 5400-Geräten war diese Operation möglich, da die Firewall vor NAT geschaltet und deshalb die Einschränkung des Internetzugriffs für Hosts realisierbar war.

Ausweichlösungen für die Reihenfolge der Operationen

Für die VRA ist ein neues Routing-Schema erforderlich:

Routing-DNS
Routing-Schema

Richtlinienbasierte Routing-Tabelle

Probleme mit richtlinienbasierten Routing-Tabellen

Das Wort 'Table' in den Konfigurationen ist beim richtlinienbasierten Routing von Vyatta 5400 optional. Das Feld acceptTable** ist jedoch für die VRA obligatorisch, wenn die Aktion ** lautet. Wenn die Aktion in der VRA-Konfiguration drop lautet, ist das Feld 'Table' optional.

Ausweichlösungen für richtlinienbasierte Routing-Tabellen

'Table Main' ist eine verfügbare Option beim richtlinienbasierten Routing von Vyatta 5400. Das funktional entsprechende Element in VRA lautet 'routing-instance default'.

Richtlinienbasiertes Routing über die Tunnelschnittstelle

Probleme beim richtlinienbasierten Routing auf der Tunnelschnittstelle

In IBM Cloud® Virtual Router Appliance können Richtlinien für das richtlinienbasierte Routing (PBR) auf Datenebenenschnittstellen für eingehenden Datenverkehr angewendet werden, aber nicht auf Loopback-, Tunnel-, Bridge-, OpenVPN-, VTI- und nicht nummerierte IP-Schnittstellen.

Problemumgehungen für richtlinienbasiertes Routing auf der Tunnelschnittstelle

Für dieses Problem gibt es momentan keine Problemumgehungen.

OpenVPN

OpenVPN-Probleme

OpenVPN wird nicht gestartet, wenn der Parameter push-route in IBM Cloud® Virtual Router Appliance verwendet wird.

Ausweichlösungen für OpenVPN

Verwenden Sie den Parameter openvpn-option anstelle von push-route.

GRE/VTI über IPSEC + OSPF

Probleme bei GRE/VTI über IPSEC + OSPF

  • Wenn für VIF mehrere Teilnetze konfiguriert sind, kann der Datenverkehr diese Teilnetze in der VRA nicht durchqueren.
  • InterVLAN-Routing funktioniert in der VRA nicht.

Ausweichlösungen für GRE/VTI über IPSEC + OSPF

Verwenden Sie implizite 'Allow'-Regeln, um Datenverkehr über VIF-Schnittstellen hinweg zu akzeptieren.

IPsec

IPsec-Probleme

IPsec (präfixbasiert) funktioniert nicht mit IN-Filter.

IPsec-Ausweichlösungen

Verwenden Sie IPsec (VTI-basiert).

IPSEC "match-none"

Probleme mit IPSEC "match-none"

Auf Vyatta 5400-Geräten ist die folgende Firewallregel zulässig:

set firewall name allow rule 10 ipsec

Bei IBM Cloud® Virtual Router Appliance gibt es jedoch kein IPsec.

Ausweichlösungen für IPSEC "match-none"

Mögliche alternative Regeln für VRA-Geräte:

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

IPSEC 'match-ipsec"

Probleme mit IPSEC "match-ipsec"

Auf Vyatta 5400-Geräten sind die folgenden Firewallregeln zulässig:

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

Bei IBM Cloud® Virtual Router Appliance gibt es jedoch kein IPsec.

Ausweichlösungen für IPSEC "match-ipsec"

Fügen Sie die Protokolle ESP und AH (IP-Protokolle 50 bzw. 51) hinzu.

Die Regel action kann die Werte accept oder drop haben, wie im folgenden Beispiel dargestellt:

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

Site-to-Site IPsec mit DNAT

Probleme bei Site-to-site IPsec mit DNAT

IPsec (präfixbasiert) funktioniert nicht mit 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

Das Snippet oben ist ein kurzes Beispiel für die Konfiguration der DNAT-Umsetzung, nachdem ein IPsec-Paket auf einem Vyatta 5400-Gerät verschlüsselt wurde. In diesem Beispiel gibt es zwei Vyatta-Geräte, vyatta1 (11.0.0.1) und vyatta2 (12.0.0.1). IPsec-Peering ist zwischen 11.0.0.1 und 12.0.0.1 eingerichtet. In diesem Fall verwendet der Client 172.16.1.245 als Ziel, abgeleitet von 10.103.0.1 End-to-End.Das erwartete Verhalten in diesem Szenario ist, dass die Zieladresse 172.16.1.245 im Paketheader in 10.71.68.245 umgesetzt wird.

Ursprünglich führte das Vyatta 5400-Gerät DNAT für den eingehenden IPsec aus, beendete die Schnittstelle und gab den Datenverkehr unter Verwendung der Tabelle zum Nachverfolgen von Verbindungen an den IPsec-Tunnel zurück.

Bei IBM Cloud® Virtual Router Appliance funktioniert die Konfiguration nicht auf diese Weise. Die Sitzung wird erstellt, aber der rücklaufende Datenverkehr umgeht den IPsec-Tunnel, nachdem die Tabelle zum Nachverfolgen von Verbindungen die DNAT-Änderung rückgängig gemacht hat.VRA sendet das Paket dann ohne IPsec-Verschlüsselung.Das vorgeschaltete Gerät erwartet diesen Datenverkehr nicht und löscht ihn höchstwahrscheinlich.Die End-to-End-Konnektivität wird unterbrochen, aber dieses Verhalten ist beabsichtigt.

Ausweichlösungen für Site-to-site IPsec mit DNAT

Für dieses Netzbetriebsszenario hat IBM eine RFE (Request for Enhancement) erstellt.

Während diese RFE ausgewertet wird, wird die folgende Problemumgehung empfohlen:

Schnittstellenkonfigurationsbefehle

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'

VPN-Konfigurationsbefehle

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'

NAT-Konfigurationsbefehle

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'

Protokollkonfigurationsbefehle

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'

PBR-Konfigurationsbefehle

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'

PPTP

PPTP-Probleme

PPTP wird bei IBM Cloud® Virtual Router Appliance nicht mehr unterstützt.

PPTP-Ausweichlösungen

Verwenden Sie stattdessen das L2TP-Protokoll.

Script für den Neustart von IPsec

Script für IPsec-Neustartprobleme

Immer wenn eine virtuelle VRRP-Adresse zu IBM Cloud® Virtual Router Appliance in einem Hochverfügbarkeits-VPN hinzugefügt wird, müssen Sie den IPsec-Dämon reinitialisieren. Der Grund ist, dass der IPsec-Service nur Verbindungen mit Adressen überwacht, die in VRA vorhanden sind, wenn der IKE-Servicedämon initialisiert wird.

Für ein Paar von VRA-Instanzen mit VRRP verfügt der Standby-Router möglicherweise nicht über die virtuelle VRRP-Adresse, die auf dem Gerät während der Initialisierung vorhanden ist, falls diese Adresse nicht auf dem Master-Router vorhanden ist. Führen Sie deshalb den folgenden Befehl auf den Master- und Backup-Routern aus, um den IPsec-Dämon zu reinitialisieren, wenn eine VRRP-Statusänderung auftritt:

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

Aktuelle Anzahl und aktuelle Zeit

Probleme mit aktuellster Anzahl und aktuellster Zeit

Der Zweck der folgenden Regel besteht darin, SSH-Verbindungen auf 3 alle 30 Sekunden für alle SSH-Adressen zu beschränken:

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'

Bei IBM Cloud® Virtual Router Appliance führt diese Regel zu den folgenden Problemen:

  • Die Option für die aktuelle Anzahl ('recent count') und die aktuelle Zeit ('recent time') wird nicht mehr verwendet.
  • Die Regel funktioniert folglich nicht wie erwartet und blockiert alle SSH-Verbindungen zur angewandten Schnittstelle.

Ausweichlösungen für aktuellste Anzahl und aktuellste Zeit

Verwenden Sie stattdessen CPP.

Probleme beim Festlegen der Nachverfolgung von Verbindungen auf dem System

Probleme beim Festlegen der Systemverbindungsüberwachung

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'

Zeitlimitüberschreitung beim Festlegen der Nachverfolgung von Verbindungen auf dem System

Probleme beim Festlegen des Zeitlimits für die Systemverbindung

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'

Zeitbasierte Firewall

Zeitbasierte Firewallprobleme

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'

TCP-MSS

TCP-MSS-Probleme

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

Bestimmte Anwendung oder Port in S-S-IPsec-VPN unterbrochen

Probleme mit bestimmter Anwendung oder unterbrochenem Port in S-S-IPsec-VPN

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)

Signifikante Änderung des Protokollierungsverhaltens

Probleme bei wesentlicher Änderung beim Protokollierungsverhalten

Das Protokollierungsverhalten zwischen Vyatta 5400-Gerät und IBM Cloud® Virtual Router Appliance hat sich signifikant geändert, nämlich von einer sitzungsbasierten Protokollierung in eine paketbasierte Protokollierung.

  • Sitzungsprotokollierung: Zeichnet Statusübergänge von statusbehafteten Sitzungen auf.
  • Paketprotokollierung: Zeichnet alle Pakete auf, die mit der Regel übereinstimmen. Da die Paketprotokollierung in der Protokolldatei in sogenannten Paketeinheiten aufgezeichnet wird, gibt es einen deutlichen Rückgang des Durchsatzes und der Belastung der Datenträgerkapazität.
  • Die Protokollierungsfunktion des vRouters kann zum Erfassen der Firewallaktivität verwendet werden. Wie bei jeder Protokollierungsfunktion sollten Sie dies nur aktivieren, um ein bestimmtes Problem zu beheben, und die Protokollierung anschließend so schnell wie möglich wieder inaktivieren.

Die statusabhängige Firewall, die Firewall-/NAT-Sitzungen verwaltet, schreibt in sogenannten Sitzungseinheiten. Sitzungsprotokollierung wird empfohlen. Für die einzelnen Einstellungen gibt es jeweils eine Beschreibung.

Sitzung/Protokollierung

  • security firewall session-log <protocol>
  • system syslog file <filename> facility <facility> level <level>

Firewall für Paketprotokollierung

  • security firewall name <name> default-log <action>
  • security firewall name <name> rule <rule-number> log

NAT

  • service nat destination rule <rule-number> log
  • service nat source rule <rule-number> log PBR
  • policy route pbr <name> rule <rule-number> log

SQ

  • policy qos name <policy-name> shaper class <class-id> match <rule-name>