yannosch
Goto Top

VPN Cisco ASA5505 PaloAlto PA-200

Hallo zusammen,

ich würde gerne ein Site-to-Site VPN zwischen den beiden Standorten aufbauen.

PaloAlto PA200
Internetanschluss Deutsche Telekom GK 10/10Mbit
Public IP: XX.XXX.72.66
Inside Network: 192.168.83.0 /24

Cisco ASA5505
KEVAG Kabelanschluss 100Mbit mit Kabelmodem
Public IP: X.XX.193.143
Inside Network: 192.168.0.0 /24

Die Konfigurationen der Palo Alto sind folgende:

Tunnelinterface:
interface

IKE Gateway:
ike
ikegateway advanced

IKE Crypto:
crypto ike

IPsec Crypto:
ipseccrypto

IPsec Tunnel:
ipsectunnel
ipsectunnel_proxy


Die Konfigurationen der Cisco ASA 5505 sind folgende:

: Saved
: 
: Serial Number: JFJHDFGG2347
: Hardware:   ASA5505, 512 MB RAM, CPU Geode 500 MHz
: Written by enable_15 at 07:59:37.708 UTC Tue Feb 20 2018
!
ASA Version 9.1(7)23 
!
hostname ciscoasa
enable password ZZYYXX encrypted
xlate per-session deny tcp any4 any4
xlate per-session deny tcp any4 any6
xlate per-session deny tcp any6 any4
xlate per-session deny tcp any6 any6
xlate per-session deny udp any4 any4 eq domain
xlate per-session deny udp any4 any6 eq domain
xlate per-session deny udp any6 any4 eq domain
xlate per-session deny udp any6 any6 eq domain
passwd XXYYZZ encrypted
names
name 192.168.0.21 PrinterMFP
name 192.168.0.35 COM description COM
name 192.168.0.200 TK description Telfonanalge
name 192.168.83.0 remote-network
name 192.168.0.9 Telefon1 description VoIP Telefon1
name 192.168.0.13 Telefon2 description Telefon2
name 192.168.83.16 Telefon3 description Telefon3
name 192.168.0.18 Telefon4 description Telefon4
name 46.165.159.160 CloudVoIPTK description VoIP TK
ip local pool VPN_Pool 192.168.0.240-192.168.0.245 mask 255.255.255.0
ip local pool IE_VPN_pool 192.168.0.50-192.168.0.55 mask 255.255.255.0
ip local pool IEVPN 192.168.0.230-192.168.0.235 mask 255.255.255.0
!
interface Ethernet0/0
 switchport access vlan 2
!
interface Ethernet0/1
!
interface Ethernet0/2
!
interface Ethernet0/3
!
interface Ethernet0/4
!
interface Ethernet0/5
!
interface Ethernet0/6
!
interface Ethernet0/7
!
interface Vlan1
 nameif inside
 security-level 100
 ip address 192.168.0.1 255.255.255.0 
!
interface Vlan2
 nameif outside
 security-level 0
 ip address dhcp setroute 
!
interface Vlan5
 no nameif
 security-level 50
 ip address 192.168.5.1 255.255.255.0 
!
!
time-range RA_VPN
 periodic daily 0:00 to 23:59
!
boot system disk0:/asa917-23-k8.bin
ftp mode passive
dns domain-lookup inside
dns domain-lookup outside
dns server-group DefaultDNS
 name-server 212.7.160.2
 name-server 212.7.160.3
 name-server 212.7.160.9
object network Telefon2
 host 192.168.0.13
 description Created during name migration
object network Telefon4
 host 192.168.0.18
 description Created during name migration
object network Telefon1
 host 192.168.0.9
 description Created during name migration
object network Telefon3
 host 192.168.83.16
 description Created during name migration
object network obj-192.168.0.240
 subnet 192.168.0.240 255.255.255.248
object network obj-192.168.0.48
 subnet 192.168.0.48 255.255.255.248
object network obj-192.168.0.224
 subnet 192.168.0.224 255.255.255.240
object network obj_any
 subnet 0.0.0.0 0.0.0.0
object network PrinterMFP
 host 192.168.0.21
 description Created during name migration
object network CloudVoIPTK
 subnet 46.165.159.XXX 255.255.255.XXX
 description Created during name migration
object network remote-network
 subnet 192.168.83.0 255.255.255.0
 description Created during name migration
object-group service SMTPOffice365 tcp
 port-object eq 587
object-group network VoIP_Telefone
 description VoIP_Telefone
 network-object object Telefon2
 network-object object Telefon4
 network-object object Telefon1
 network-object object Telefon3
object-group protocol DM_INLINE_PROTOCOL_1
 protocol-object udp
 protocol-object tcp
object-group protocol TCPUDP
 protocol-object udp
 protocol-object tcp
object-group protocol DM_INLINE_PROTOCOL_2
 protocol-object udp
 protocol-object tcp
object-group protocol DM_INLINE_PROTOCOL_3
 protocol-object udp
 protocol-object tcp
object-group protocol DM_INLINE_PROTOCOL_4
 protocol-object udp
 protocol-object tcp
object-group protocol DM_INLINE_PROTOCOL_5
 protocol-object udp
 protocol-object tcp
access-list inside_access_in extended permit tcp object PrinterMFP any4 object-group SMTPOffice365 
access-list inside_access_in extended permit tcp 192.168.0.0 255.255.255.0 any4 eq 587 
access-list inside_access_in extended permit icmp 192.168.0.0 255.255.255.0 any4 
access-list inside_access_in extended permit ip 192.168.0.0 255.255.255.0 any4 
access-list inside_access_in extended permit object-group DM_INLINE_PROTOCOL_1 object-group VoIP_Telefone object CloudVoIPTK 
access-list inside_access_in extended permit object-group DM_INLINE_PROTOCOL_1 object CloudVoIPTK object-group VoIP_Telefone 
access-list RA_VPN_access extended permit ip any4 any4 
access-list RA_VPN_access extended permit ip any4 192.168.0.0 255.255.255.0 
access-list RA_VPN_access extended permit ip any4 host 192.168.0.133 
access-list inside_nat0_outbound extended permit ip any4 192.168.0.240 255.255.255.248 
access-list inside_nat0_outbound extended permit ip any4 192.168.0.48 255.255.255.248 
access-list inside_nat0_outbound extended permit ip any4 192.168.0.224 255.255.255.240 
access-list outside_1_cryptomap extended permit ip 192.168.0.0 255.255.255.0 192.168.83.0 255.255.255.0 
access-list outside_nat0_outbound extended permit ip 192.168.0.0 255.255.255.0 object remote-network 
access-list outside_access_in extended permit object-group DM_INLINE_PROTOCOL_1 object CloudVoIPTK object-group VoIP_Telefone 
pager lines 24
logging asdm informational
mtu inside 1500
mtu outside 1500
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdm-791-151.bin
no asdm history enable
arp timeout 14400
no arp permit-nonconnected
nat (inside,any) source static any any destination static obj-192.168.0.240 obj-192.168.0.240 no-proxy-arp route-lookup
nat (inside,any) source static any any destination static obj-192.168.0.48 obj-192.168.0.48 no-proxy-arp route-lookup
nat (inside,any) source static any any destination static obj-192.168.0.224 obj-192.168.0.224 no-proxy-arp route-lookup
!
object network obj_any
 nat (inside,outside) dynamic interface
access-group inside_access_in in interface inside
access-group outside_access_in in interface outside
route outside remote-network 255.255.255.0 XX.XXX.72.66 1 
timeout xlate 3:00:00
timeout pat-xlate 0:00:30
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
timeout floating-conn 0:00:00
dynamic-access-policy-record DfltAccessPolicy
user-identity default-domain LOCAL
http server enable
http 192.168.0.0 255.255.255.0 inside
no snmp-server location
no snmp-server contact
crypto ipsec ikev1 transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac 
crypto ipsec ikev1 transform-set ESP-DES-MD5 esp-des esp-md5-hmac 
crypto ipsec ikev1 transform-set ESP-AES-192-SHA esp-aes-192 esp-sha-hmac 
crypto ipsec ikev1 transform-set ESP-AES-128-MD5 esp-aes esp-md5-hmac 
crypto ipsec ikev1 transform-set ESP-AES-192-MD5 esp-aes-192 esp-md5-hmac 
crypto ipsec ikev1 transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac 
crypto ipsec ikev1 transform-set ESP-AES-256-MD5 esp-aes-256 esp-md5-hmac 
crypto ipsec ikev1 transform-set ESP-DES-SHA esp-des esp-sha-hmac 
crypto ipsec ikev1 transform-set ESP-3DES-SHA esp-3des esp-sha-hmac 
crypto ipsec ikev1 transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac 
crypto ipsec security-association pmtu-aging infinite
crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set pfs group1
crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set ikev1 transform-set ESP-AES-128-SHA ESP-AES-128-MD5 ESP-AES-192-SHA ESP-AES-192-MD5 ESP-AES-256-SHA ESP-AES-256-MD5 ESP-3DES-SHA ESP-3DES-MD5 ESP-DES-SHA ESP-DES-MD5
crypto map outside_map 1 match address outside_1_cryptomap
crypto map outside_map 1 set pfs group5
crypto map outside_map 1 set peer XX.XXX.72.66 
crypto map outside_map 1 set ikev1 transform-set ESP-AES-256-SHA
crypto map outside_map 1 set nat-t-disable
crypto map outside_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP
crypto map outside_map interface outside
crypto ca trustpool policy
crypto ikev1 enable inside
crypto ikev1 enable outside
crypto ikev1 policy 1
 authentication pre-share
 encryption aes-256
 hash sha
 group 5
 lifetime 86400
crypto ikev1 policy 10
 authentication pre-share
 encryption 3des
 hash sha
 group 1
 lifetime 86400
crypto ikev1 policy 30
 authentication pre-share
 encryption 3des
 hash sha
 group 2
 lifetime 86400
crypto ikev1 policy 50
 authentication pre-share
 encryption des
 hash sha
 group 5
 lifetime 86400
telnet timeout 5
ssh stricthostkeycheck
ssh timeout 5
ssh key-exchange group dh-group1-sha1
console timeout 0

dhcpd auto_config outside
!
dhcpd address 192.168.0.5-COM inside
dhcpd enable inside
!
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
group-policy DfltGrpPolicy attributes
 vpn-idle-timeout none
 vpn-tunnel-protocol ikev1 
group-policy IEVPN internal
group-policy IEVPN attributes
 dns-server value 212.7.160.2 212.7.160.3
 vpn-tunnel-protocol ikev1 
username ZZ password sdfgsdfgsdfg encrypted privilege 0
username ZZ attributes
 vpn-group-policy IEVPN
username XX password sdfgsdfgsdfg encrypted privilege 0
username XX attributes
 vpn-group-policy IEVPN
username YY password sdfgsdfgsdfg encrypted privilege 0
username YY attributes
 vpn-group-policy IEVPN
tunnel-group IEVPN type remote-access
tunnel-group IEVPN general-attributes
 address-pool IEVPN
 default-group-policy IEVPN
tunnel-group IEVPN ipsec-attributes
 ikev1 pre-shared-key *****
tunnel-group XX.XXX.72.66 type ipsec-l2l
tunnel-group XX.XXX.72.66 ipsec-attributes
 ikev1 pre-shared-key *****
 peer-id-validate nocheck
 isakmp keepalive disable
!
class-map inspection_default
 match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum client auto
  message-length maximum 512
policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map 
  inspect ftp 
  inspect h323 h225 
  inspect h323 ras 
  inspect rsh 
  inspect rtsp 
  inspect esmtp 
  inspect sqlnet 
  inspect skinny  
  inspect sunrpc 
  inspect xdmcp 
  inspect sip  
  inspect netbios 
  inspect tftp 
  inspect ip-options 
  inspect icmp 
  inspect icmp error 
!
service-policy global_policy global
prompt hostname context 
no call-home reporting anonymous
Cryptochecksum:ae6814d5e23498756983745987349587

Ich habe mich bei der Konfiguration an diese Anleitunggehalten.
Leider bekomme ich aber keine Verbindung established. Scheint also ein grundlegender Fehler in der Konfiguration zu sein - ich komme aber leider nicht alleine drauf.
ike gateway

Ich bin für jeden Tipp dankbar!

EDIT: Auf der ASA ist ebenfalls ein c2s VPN über Shrewsoft eingerichtet, also nicht verwirren lassen.

liebe Grüße
Yannosch
ike

Content-Key: 365349

Url: https://administrator.de/contentid/365349

Ausgedruckt am: 19.03.2024 um 05:03 Uhr

Mitglied: brammer
brammer 20.02.2018 um 11:14:31 Uhr
Goto Top
Hallo,

was sagt den auf der ASA ein

sh crypto ipsec 
sh crypto isakmp

Welche ASA Software Version läuft?

brammer
Mitglied: heilgecht
heilgecht 20.02.2018 um 11:37:53 Uhr
Goto Top
Mitglied: Yannosch
Yannosch 20.02.2018 aktualisiert um 11:54:24 Uhr
Goto Top
Zitat von @brammer:

Hallo,

was sagt den auf der ASA ein

> sh crypto ipsec 
> sh crypto isakmp
> 

sh crypto ipsec:

ciscoasa# sh crypto ipsec
ERROR: % Incomplete command

sh crypto isakmp:

ciscoasa# sh crypto isakmp

There are no IKEv1 SAs

There are no IKEv2 SAs

Global IKEv1 Statistics
  Active Tunnels:              0
  Previous Tunnels:            0
  In Octets:                  64
  In Packets:                  1
  In Drop Packets:             1
  In Notifys:                  0
  In P2 Exchanges:             0
  In P2 Exchange Invalids:     0
  In P2 Exchange Rejects:      0
  In P2 Sa Delete Requests:    0
  Out Octets:                 76
  Out Packets:                 1
  Out Drop Packets:            0
  Out Notifys:                 1
  Out P2 Exchanges:            0
  Out P2 Exchange Invalids:    0
  Out P2 Exchange Rejects:     0
  Out P2 Sa Delete Requests:   0
  Initiator Tunnels:           0
  Initiator Fails:             0
  Responder Fails:             1
  System Capacity Fails:       0
  Auth Fails:                  0
  Decrypt Fails:               0
  Hash Valid Fails:            0
  No Sa Fails:                 0

IKEV1 Call Admission Statistics
  Max In-Negotiation SAs:                 25
  In-Negotiation SAs:                      0
  In-Negotiation SAs Highwater:            1
  In-Negotiation SAs Rejected:             0

Global IKEv2 Statistics
  Active Tunnels:                          0
  Previous Tunnels:                        0
  In Octets:                               0
  In Packets:                              0
  In Drop Packets:                         0
  In Drop Fragments:                       0
  In Notifys:                              0
  In P2 Exchange:                          0
  In P2 Exchange Invalids:                 0
  In P2 Exchange Rejects:                  0
  In IPSEC Delete:                         0
  In IKE Delete:                           0
  Out Octets:                              0
  Out Packets:                             0
  Out Drop Packets:                        0
  Out Drop Fragments:                      0
  Out Notifys:                             0
  Out P2 Exchange:                         0
  Out P2 Exchange Invalids:                0
  Out P2 Exchange Rejects:                 0
  Out IPSEC Delete:                        0
  Out IKE Delete:                          0
  SAs Locally Initiated:                   0
  SAs Locally Initiated Failed:            0
  SAs Remotely Initiated:                  0
  SAs Remotely Initiated Failed:           0
  System Capacity Failures:                0
  Authentication Failures:                 0
  Decrypt Failures:                        0
  Hash Failures:                           0
  Invalid SPI:                             0
  In Configs:                              0
  Out Configs:                             0
  In Configs Rejects:                      0
  Out Configs Rejects:                     0
  Previous Tunnels:                        0
  Previous Tunnels Wraps:                  0
  In DPD Messages:                         0
  Out DPD Messages:                        0
  Out NAT Keepalives:                      0
  IKE Rekey Locally Initiated:             0
  IKE Rekey Remotely Initiated:            0
  CHILD Rekey Locally Initiated:           0
  CHILD Rekey Remotely Initiated:          0

IKEV2 Call Admission Statistics
  Max Active SAs:                   No Limit
  Max In-Negotiation SAs:                 12
  Cookie Challenge Threshold:          Never
  Active SAs:                              0
  In-Negotiation SAs:                      0
  Incoming Requests:                       0
  Incoming Requests Accepted:              0
  Incoming Requests Rejected:              0
  Outgoing Requests:                       0
  Outgoing Requests Accepted:              0
  Outgoing Requests Rejected:              0
  Rejected Requests:                       0
  Rejected Over Max SA limit:              0
  Rejected Low Resources:                  0
  Rejected Reboot In Progress:             0
  Cookie Challenges:                       0
  Cookie Challenges Passed:                0
  Cookie Challenges Failed:                0

Global IKEv1 IPSec over TCP Statistics
--------------------------------
Embryonic connections: 0
Active connections: 0
Previous connections: 0
Inbound packets: 0
Inbound dropped packets: 0
Outbound packets: 0
Outbound dropped packets: 0
RST packets: 0
Recevied ACK heart-beat packets: 0
Bad headers: 0
Bad trailers: 0
Timer failures: 0
Checksum errors: 0
Internal errors: 0


Welche ASA Software Version läuft?


ASA Version 9.1(7)23

brammer
Grüße und Danke für die Hilfe!
Yannosch
Mitglied: brammer
brammer 20.02.2018 um 12:16:39 Uhr
Goto Top
Hallo,

okay.. da läuft wohl nicht mal ein DEBUG, oder?

debug cry isa 
debug cry ipsec

und dann mal ein sh log posten...

brammer
Mitglied: Yannosch
Yannosch 20.02.2018 aktualisiert um 12:52:39 Uhr
Goto Top
Zitat von @brammer:

Hallo,

okay.. da läuft wohl nicht mal ein DEBUG, oder?

Debug hab ich noch nicht gemacht nein.


> debug cry isa 
> debug cry ipsec
> 

habe ich ausgeführt


und dann mal ein sh log posten...
ciscoasa# sh log

Syslog logging: enabled
    Facility: 20
    Timestamp logging: disabled
    Hide Username logging: enabled
    Standby logging: disabled
    Debug-trace logging: disabled
    Console logging: disabled
    Monitor logging: disabled
    Buffer logging: disabled
    Trap logging: disabled
    Permit-hostdown logging: disabled
    History logging: disabled
    Device ID: disabled
    Mail logging: disabled
    ASDM logging: level informational, 2467 messages logged

Wo finde ich den genauen von dir gewollten log?


brammer
Mitglied: Yannosch
Yannosch 20.02.2018 um 13:21:47 Uhr
Goto Top
Ich bekomme
Debug-trace logging: disabled

nicht enabled ... und habe somit auch keine Ergebnisse für sh log.

Was regt mich dieses Kackding auf!

Sorry...

Bitte versuch mir doch nur kurz zu sagen was ich machen muss damit ich die passenden Logs generieren kann.
Mitglied: brammer
brammer 20.02.2018 um 13:22:29 Uhr
Goto Top
Hallo,

einfach bis zum Ende durchblättern.... mit der "Enter Taste" Zeilenweise.... mit der "Freizeichen Taste" seitenweise.

brammer
Mitglied: Yannosch
Yannosch 20.02.2018 um 13:36:20 Uhr
Goto Top
Habe ich nicht die möglichkeit ... da ist ende ... kann nicht weitergehen
Mitglied: brammer
brammer 20.02.2018 um 13:48:47 Uhr
Goto Top
Hallo ,


ASDM logging: level informational, 2467 messages logged

Habe ich nicht die möglichkeit ... da ist ende ... kann nicht weitergehen

das bezweifle ich ....


https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-ne ...

brammer
Mitglied: Yannosch
Yannosch 20.02.2018 aktualisiert um 14:35:02 Uhr
Goto Top
Zitat von @brammer:

Hallo ,


ASDM logging: level informational, 2467 messages logged

Habe ich nicht die möglichkeit ... da ist ende ... kann nicht weitergehen

das bezweifle ich ....


In der CLI geht es da aber wirklich nicht weiter.


Bin jetzt mit dem gesamten Artikel fertig und leider bin ich auch nicht schlauer.

Hier ein Ausschnitt vom Real Time Log Viewer:
logs

Unter der Rubrik Debugging finde ich da nix... nur dass ich den Befehl
debug cry ipsec
ausgeführt habe.


brammer

Gruß Yannosch
Mitglied: aqui
aqui 20.02.2018 aktualisiert um 15:54:25 Uhr
Goto Top
Versuchs doch mal auf der anderen Seite !
Was sagt das Log der Palo Alto beim Tunnelaufbau ???

Ansonsten ist es beim Cisco wie immer show log und um den IPsec Status zu sehen sh crypto isakmp sa
Wenn du Debug Kommandos über eine Telnet oder SSH Session machst vergiss nicht VORHER immer terminal monitor einzugeben, denn sonst wandern die Debug Outputs immer auf die serielle Konsole.

Einen groben Fehler in der Konfig oben hast du schon gemacht ! Der Exchange Mode bei Hersteller fremden Geräten ist bei IPsec VPNs immer aggressive und niemals der Main Mode !
Das solltest du in jedem Falle korrigieren in der Konfig und zwar auf BEIDEN Seiten !

Ansonsten findest du hier noch ein paar grundlegende Infos:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Mitglied: Yannosch
Yannosch 20.02.2018 um 16:19:27 Uhr
Goto Top
Hallo zusammen,

danke Aqui für den Hinweis! Ich arbeite nämlich per SSH/Putty auf der Kiste.
Ich habe jetzt erst
terminal monitor

und dann
debug cry ipsec

gibt aber nach einem show log wieder die selbe Ausgabe ... also nichts spezifisches.

Der Befehl
sh crypto isakmp sa
gibt folgendes aus:
There are no IKEv1 SAs

There are no IKEv2 SAs
@aqui deine angesprochenen Änderungen bzgl des Exchangemode werde ich sofort umstezen und anschließend berichten.
Mitglied: Yannosch
Yannosch 20.02.2018 um 17:12:59 Uhr
Goto Top
@aqui

ich weißt leider nicht genau weswegen es jetzt funktioniert, bzw. der Tunnel steht, aber das hier habe ich gemacht:

  • Deine Änderungen
  • und den Befehl "test vpn ipsec-sa tunnel" [soll laut PaloAlto den Tunnel neu initiieren]

Und der Tunnel wird mit auf der ASA und auf der Palo Alto als active angezeigt. Leider vermute ich, dass es hier mehr Glück wie Verstand gewesen ist. Deswegen schaue ich mir die Sache nochmal genauer an.

Leider kann ich nicht hin und her pingen, bzw. die IP Kommunikation funktioniert noch nicht wie sie soll. Aber das Probiere ich erstmal alleine.

Naja ... erstmal danke bis hierhin - ich melde mich nochmal wenn ich nicht mehr weiter komme.

LG & vielen Dank
Yannosch
Mitglied: aqui
aqui 20.02.2018 aktualisiert um 17:40:05 Uhr
Goto Top
Leider vermute ich, dass es hier mehr Glück wie Verstand gewesen ist.
Könnte sein, aber egal...wenns jetzt funktioniert ist doch erstmal alles gut face-wink
Jetzt müsste bei bestehendem Tunnel dann aber ein sh crypto isakmp sa in jedem Falle den aktiven Tunnel angezeigen ? Tut es das ?
Leider kann ich nicht hin und her pingen,
Das liegt vermutlich daran das das ICMP Protokoll geblockt ist. Das ist üblich bei Firewalls. Ohne ICMP natürlich dann kein Ping ! Da musst du wie immer das FW Regelwerk entsprechend auf beiden Seiten anpassen.

Hier findest du sonst noch ein paar nützliche Tips:
https://blog.webernetz.net/ipsec-site-to-site-vpn-palo-alto-cisco-asa/
Mitglied: Yannosch
Yannosch 21.02.2018 aktualisiert um 09:46:02 Uhr
Goto Top
Zitat von @aqui:

Leider vermute ich, dass es hier mehr Glück wie Verstand gewesen ist.
Könnte sein, aber egal...wenns jetzt funktioniert ist doch erstmal alles gut face-wink
Jetzt müsste bei bestehendem Tunnel dann aber ein sh crypto isakmp sa in jedem Falle den aktiven Tunnel angezeigen ? Tut es das ?

Yes, siehe hier:

ciscoasa# sh crypto isakmp

IKEv1 SAs:

   Active SA: 1
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1   IKE Peer: XX.XXX.72.66
    Type    : L2L             Role    : initiator
    Rekey   : no              State   : AM_ACTIVE

There are no IKEv2 SAs

Global IKEv1 Statistics
  Active Tunnels:              1
  Previous Tunnels:            1
  In Octets:               11060
  In Packets:                 46
  In Drop Packets:             2
  In Notifys:                 19
  In P2 Exchanges:             1
  In P2 Exchange Invalids:     0
  In P2 Exchange Rejects:      0
  In P2 Sa Delete Requests:   19
  Out Octets:              10736
  Out Packets:                48
  Out Drop Packets:            0
  Out Notifys:                 2
  Out P2 Exchanges:           19
  Out P2 Exchange Invalids:    0
  Out P2 Exchange Rejects:     0
  Out P2 Sa Delete Requests:   0
  Initiator Tunnels:           0
  Initiator Fails:             0
  Responder Fails:             2
  System Capacity Fails:       0
  Auth Fails:                  0
  Decrypt Fails:               0
  Hash Valid Fails:            0
  No Sa Fails:                 0

IKEV1 Call Admission Statistics
  Max In-Negotiation SAs:                 25
  In-Negotiation SAs:                      0
  In-Negotiation SAs Highwater:            1
  In-Negotiation SAs Rejected:             0

Global IKEv2 Statistics
  Active Tunnels:                          0
  Previous Tunnels:                        0
  In Octets:                               0
  In Packets:                              0
  In Drop Packets:                         0
  In Drop Fragments:                       0
  In Notifys:                              0
  In P2 Exchange:                          0
  In P2 Exchange Invalids:                 0
  In P2 Exchange Rejects:                  0
  In IPSEC Delete:                         0
  In IKE Delete:                           0
  Out Octets:                              0
  Out Packets:                             0
  Out Drop Packets:                        0
  Out Drop Fragments:                      0
  Out Notifys:                             0
  Out P2 Exchange:                         0
  Out P2 Exchange Invalids:                0
  Out P2 Exchange Rejects:                 0
  Out IPSEC Delete:                        0
  Out IKE Delete:                          0
  SAs Locally Initiated:                   0
  SAs Locally Initiated Failed:            0
  SAs Remotely Initiated:                  0
  SAs Remotely Initiated Failed:           0
  System Capacity Failures:                0
  Authentication Failures:                 0
  Decrypt Failures:                        0
  Hash Failures:                           0
  Invalid SPI:                             0
  In Configs:                              0
  Out Configs:                             0
  In Configs Rejects:                      0
  Out Configs Rejects:                     0
  Previous Tunnels:                        0
  Previous Tunnels Wraps:                  0
  In DPD Messages:                         0
  Out DPD Messages:                        0
  Out NAT Keepalives:                      0
  IKE Rekey Locally Initiated:             0
  IKE Rekey Remotely Initiated:            0
  CHILD Rekey Locally Initiated:           0
  CHILD Rekey Remotely Initiated:          0

IKEV2 Call Admission Statistics
  Max Active SAs:                   No Limit
  Max In-Negotiation SAs:                 12
  Cookie Challenge Threshold:          Never
  Active SAs:                              0
  In-Negotiation SAs:                      0
  Incoming Requests:                       0
  Incoming Requests Accepted:              0
  Incoming Requests Rejected:              0
  Outgoing Requests:                       0
  Outgoing Requests Accepted:              0
  Outgoing Requests Rejected:              0
  Rejected Requests:                       0
  Rejected Over Max SA limit:              0
  Rejected Low Resources:                  0
  Rejected Reboot In Progress:             0
  Cookie Challenges:                       0
  Cookie Challenges Passed:                0
  Cookie Challenges Failed:                0

Global IKEv1 IPSec over TCP Statistics
--------------------------------
Embryonic connections: 0
Active connections: 0
Previous connections: 0
Inbound packets: 0
Inbound dropped packets: 0
Outbound packets: 0
Outbound dropped packets: 0
RST packets: 0
Recevied ACK heart-beat packets: 0
Bad headers: 0
Bad trailers: 0
Timer failures: 0
Checksum errors: 0
Internal errors: 0

Leider kann ich nicht hin und her pingen,
Das liegt vermutlich daran das das ICMP Protokoll geblockt ist. Das ist üblich bei Firewalls. Ohne ICMP natürlich dann kein Ping ! Da musst du wie immer das FW Regelwerk entsprechend auf beiden Seiten anpassen.

Also da kenne ich mich schon eher aus. Auch dass ICMP allowed werden muss, ist für mich klar.
Ich werde mal das Regelwerk erweitern & sehen ob es dann funktioniert face-smile Vielen Dank auf jeden Fall erstmal!


Hier findest du sonst noch ein paar nützliche Tips:
https://blog.webernetz.net/ipsec-site-to-site-vpn-palo-alto-cisco-asa/

Den Beitrag kenne ich schon - darauf basierend habe ich meine Konfiguration vorgenommen. :-P (Siehe mein Eröffnungspost)

LG

Yannosch
Mitglied: Yannosch
Yannosch 21.02.2018 um 10:15:14 Uhr
Goto Top
Zitat von @aqui:

Leider vermute ich, dass es hier mehr Glück wie Verstand gewesen ist.
Könnte sein, aber egal...wenns jetzt funktioniert ist doch erstmal alles gut face-wink
Jetzt müsste bei bestehendem Tunnel dann aber ein sh crypto isakmp sa in jedem Falle den aktiven Tunnel angezeigen ? Tut es das ?
Leider kann ich nicht hin und her pingen,
Das liegt vermutlich daran das das ICMP Protokoll geblockt ist. Das ist üblich bei Firewalls. Ohne ICMP natürlich dann kein Ping ! Da musst du wie immer das FW Regelwerk entsprechend auf beiden Seiten anpassen.

Ich glaube eher dass da was mit dem Routing nicht stimmt, da ich mit dem Tracert gar nicht erst Richtung Runnel komme.

Ich habe folgende Routen auf beiden Seiten eingetragen:

ASA: [geschwärzte IP ist die Öffentliche von der Gegenstelle (Palo Alto)]
routeasa

Palo Alto (Virtueller Router):
routepalo

Beim Firewall Regelwerk habe ich einfach in beide Richtungen alles erlaubt.

Trotzdem steht der Tunnel nach wie vor doch es ist 0,0 Kommunikation von Netz zu Netz möglich ... face-confused


Vielleicht fällt jemandem etwas auf den ersten Blick auf...

liebe Grüße & vielen Dank schonmal bis hierhin!
Yannosch
Mitglied: aqui
aqui 21.02.2018 aktualisiert um 12:46:59 Uhr
Goto Top
Ich habe folgende Routen auf beiden Seiten eingetragen:
Das ist Unsinn, wenn die beiden Firewall die Default Router sind. IPsec injiziert selber die entsprechenden Routen automatisch bei Tunnelaufbau.
Deine statischen Routen sind deshalb Blödsinn, auch da du niemals private RFC 1918 IP Netze an öffentliche IP Adressen routen kannst. Das ist eher kontraproduktiv und solltest du besser schnell wieder entfernen.
RFC 1918 IPs werden im Internet NICHT geroutet ! In sofern hilft die Route eher wenig.
Wenn dann müpsste es an die jeweilige RFC 1918 Tunnel IP von Gegenüber geroutet werden niemals aber an die öffentliche IP. RFC 1918 dürfen niemals nach draußen (outside) gelangen.
Sind die FW denn immer die Default Gateways für ALLE Endgeräte an beiden Enden ?
Kannst du direkt auf den Firewalls das jeweils lokale LAN Interface der gegenüberliegenden FW pingen ? Das sollte immer gehen sofern ICMP erlaubt ist.
Mitglied: Yannosch
Yannosch 21.02.2018 um 11:09:58 Uhr
Goto Top
Zitat von @aqui:

Ich habe folgende Routen auf beiden Seiten eingetragen:
Das ist Unsinn, wenn die beiden Firewall die Default Router sind. IPsec injiziert selber die entsprechenden Routen automatisch bei Tunnelaufbau.
Deine statischen Routen sind deshalb Blödsinn, auch da du niemals private RFC 1918 IP Netze an öffentliche IP Adressen routen kannst. Das ist eher kontraproduktiv und solltest du besser schnell wieder entfernen.

Okay ... im genannten Beispiel war es halt so konfiguriert. Ich werde es natürlich wieder entfernen.

RFC 1918 IPs werden im Internet NICHT geroutet ! In sofern hilft die Route eher wenig.
Wenn dann müpsste es an die jeweilige RFC 1918 Tunnel IP von Gegenüber geroutet werden niemals aber an die öffentliche IP. RFC 1918 dürfen niemals nach draußen (outside) gelangen.
Sind die FW denn immer die Defasult Gateways für ALLE Endgeräte an beiden Enden ?

Aktuell sind an beiden Enden die Firewalls auch die Standartgateways.

Im Palo Alto Netz die 192.168.83.254

Im ASA Netz die 192.168.0.1

Ist das denn ein großes Problem?

Grüße
Yannosch
Mitglied: Yannosch
Yannosch 21.02.2018 aktualisiert um 12:00:08 Uhr
Goto Top
Hi @aqui,

also nachdem ich die Routen entfernt habe, habe ich immernoch

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.83.11, timeout is 2 seconds:
?????
Success rate is 0 percent (0/5)

Wenn ich den ping von der ASA auf einen Server im PA-Netz durchführe.

Grüße
Yannosch

EDIT

Ein Tracert von einem Server im PA Netz zu einem Host ins ASA Netz bringt folgendes Ergebnis:

Tracing route to 192.168.0.8 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  192.168.83.254
  2     1 ms    <1 ms    <1 ms  XX.XXX.72.65
  3  XX.XXX.72.65  reports: Destination host unreachable.

Trace complete.

Warum ich hier allerdings eine Antwort von XX.XXX.72.65 und nicht meine Outside IP mit der 66 bekomme ist mir ein Rätsel.
Mitglied: aqui
aqui 21.02.2018 aktualisiert um 12:55:21 Uhr
Goto Top
Ist das denn ein großes Problem?
Nein ! Ganz im Gegenteil das schliesst dann andere Routing Fehler erstmal sicher aus !
Was sagt denn die Routing Tabelle auf beiden Seiten ?? Werden dort die jeweils gegenüber liegenden lokalen LANs angezeigt ?
Beim Cisco ist das sh ip route.
Warum ich hier allerdings eine Antwort von XX.XXX.72.65 und nicht meine Outside IP mit der 66 bekomme ist mir ein Rätsel.
Dort dürfte gar keine öffentliche IP zu sehen sein !! Klar, denn die lokalen RFC 1918 IP Adressen dürfen niemals im Routing Pfad der öffentlichen Adressen auftauchen aus naheliegenden Gründen !
Sieht dann eher so aus als ob die lokalen RFC 1918 LAN Netze nicht in den Tunnel geroutet werden face-sad
Wie gesagt pinge erstmal ausschliesslich nur auf und zu den FWs. Keine externen Rechner.
Bedenke hier immer das du dazu zwingend die Absender IP mit angeben musst...jedenfalls bei Cisco !
Dazu machst du einen sog. extended Ping.
Du gibts das Kommando ping ein und dann return. Dann wird alles per Menü abgefragt, was du alles abnickst. Nur bei der Frage extended commands antwortest du mit einem "yes" und bei der Frage der Source IP gibst du dann die lokale LAN IP an. Alles andere wieder abnicken.
Ansonsten nimmt der Cisco eine andere Source IP und dann pingt er nicht durch den Tunnel !!
Mitglied: Yannosch
Yannosch 21.02.2018 aktualisiert um 15:09:58 Uhr
Goto Top
Hi @aqui,

ich glaube hier liegt der Watz begraben.

Das ist die Routingtabelle meiner PaloAlto [teilweise völliger Käse dabei m.M.n.]

admin@indus-PAN01> show routing route

flags: A:active, ?:loose, C:connect, H:host, S:static, ~:internal, R:rip, O:ospf, B:bgp,
       Oi:ospf intra-area, Oo:ospf inter-area, O1:ospf ext-type-1, O2:ospf ext-type-2, E:ecmp


VIRTUAL ROUTER: VR_01 (id 2)
  ==========
destination                                 nexthop                                 metric flags      age   interface          next-AS
0.0.0.0/0                                   XX.XXX.72.65                            10     A S              ethernet1/2
80.154.72.64/29                             XX.XXX.72.66                            0      A C              ethernet1/2
80.154.72.66/32                             0.0.0.0                                 0      A H
192.168.80.0/24                             192.168.80.254                          0      A C              tunnel.1
192.168.80.1/32                             192.168.80.1                            10     A S              tunnel.1
192.168.80.2/31                             192.168.80.2                            10     A S              tunnel.1
192.168.80.4/30                             192.168.80.4                            10     A S              tunnel.1
192.168.80.8/29                             192.168.80.8                            10     A S              tunnel.1
192.168.80.16/28                            192.168.80.16                           10     A S              tunnel.1
192.168.80.32/27                            192.168.80.32                           10     A S              tunnel.1
192.168.80.64/26                            192.168.80.64                           10     A S              tunnel.1
192.168.80.128/26                           192.168.80.128                          10     A S              tunnel.1
192.168.80.192/27                           192.168.80.192                          10     A S              tunnel.1
192.168.80.224/28                           192.168.80.224                          10     A S              tunnel.1
192.168.80.240/29                           192.168.80.240                          10     A S              tunnel.1
192.168.80.248/30                           192.168.80.248                          10     A S              tunnel.1
192.168.80.252/31                           192.168.80.252                          10     A S              tunnel.1
192.168.80.254/32                           0.0.0.0                                 0      A H
192.168.83.0/24                             192.168.83.254                          0      A C              ethernet1/1
192.168.83.254/32                           0.0.0.0                                 0      A H
total routes shown: 20

Tunnel.1 ist der Client-To-Site VPN Tunnel.
Der Tunnel für das Site-2-Site wäre der Tunnel.11
Der ist allerdings nirgends zu sehen ... was ich auch schon etwas komisch finde...
Die erste Regel finde ich auch komisch?!... [ist in der GUI auch als einzige STATISCHE ROUTE definiert mit dem Namen "default 10Mbit"]

Ein tracert auf google.de zeigt das hier [aus dem PA Netz]

C:\Users\netzadmin>tracert google.de

Tracing route to google.de [216.58.210.3]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.83.254
  2    <1 ms    <1 ms    <1 ms  XX.XXX.72.65

Da ist auch schon wieder die 65er statt der zu erwartenden 66er zu sehen. [weil die XX.XXX.72.66 ist ja eigentlich meine öffentliche IP]

Die Routing Tabelle der Cisco ASA sieht folgendermaßen aus: [show route]
Bisschen dünn würde ich sagen...

C    5.57.193.0 255.255.255.0 is directly connected, outside
C    192.168.0.0 255.255.255.0 is directly connected, inside
d*   0.0.0.0 0.0.0.0 [1/0] via 5.57.193.1, outside
Mitglied: aqui
aqui 21.02.2018 um 18:00:01 Uhr
Goto Top
Der Tunnel für das Site-2-Site wäre der Tunnel.11
Der ist im PA ja gar nicht vorhanden ?! Da ist es dann klar das das in die Hose geht !

Die Cisco Tabelle sieht auch etwas spartanisch aus. Das Kommando lautet übrigens NICHT show route sondern show ip route
Vermutlich werden die IPsec Routen da aber nicht angezeigt.
Poste bitte mal ein sh crypto ipsec sa auf dem Cisco.
Mitglied: Yannosch
Yannosch 22.02.2018 aktualisiert um 08:45:04 Uhr
Goto Top
Hi @aqui,

Hier das Ergebnis von sh crypto ipsec sa:

interface: outside
    Crypto map tag: outside_map, seq num: 1, local addr: X.XX.193.143

      access-list outside_1_cryptomap extended permit ip 192.168.0.0 255.255.255                           .0 192.168.83.0 255.255.255.0
      local ident (addr/mask/prot/port): (192.168.0.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (remote-network/255.255.255.0/0/0)
      current_peer: XX.XXX.72.66


      #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #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.: X.XX.193.143/0, remote crypto endpt.: XX.XXX.72.66/0
      path mtu 1500, ipsec overhead 74(44), media mtu 1500
      PMTU time remaining (sec): 0, DF policy: copy-df
      ICMP error validation: disabled, TFC packets: disabled
      current outbound spi: 926E34CB
      current inbound spi : 5A144517

    inbound esp sas:
      spi: 0x5A144517 (1511277847)
         transform: esp-aes-256 esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 5, IKEv1, }
         slot: 0, conn_id: 8192, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (4374000/611)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001
    outbound esp sas:
      spi: 0x926E34CB (2456696011)
         transform: esp-aes-256 esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 5, IKEv1, }
         slot: 0, conn_id: 8192, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (4374000/610)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001

Der Befehl show ip route klappt aber nicht über SSH bei meiner ASA.

ciscoasa# show ip route
                  ^
ERROR: % Invalid input detected at '^' marker.  
ciscoasa#

Ich denke das alles klappt einfach nur nicht, weil die jeweiligen Clients überhaupt nicht wissen welchen Tunnel Sie nehmen müssen um ins andrere Netz zu kommen. Weil routentechnisch ist da auf beiden Seiten ja quasi nichts vorhanden ...

liebe Grüße
Yannosch
Mitglied: aqui
aqui 22.02.2018 aktualisiert um 08:58:28 Uhr
Goto Top
Doch das ist doch durch die IP Zieladresse des Client seitigen Datentraffics vollkommen klar !
Anhand der Ziel IP "weiß" doch die Firewall sofort in welchen Tunnel das muss. Das ist also nicht das Problem.
Die ASA forwardet ja alles was von 192.168.0.0 255.255.255.0 auf 192.168.83.0 255.255.255.0 geht.
Das zeigt das Show Kommando ja explizit an oben.
Dieser Tunnel ist also etabliert und richtig.
Irgendwie fehlt aber ein ACL die den Traffic .0.0 zu .83.0 in den VPN Tunnel klassifiziert. Oder hab ich das jetzt übersehen in der Konfig ?! Das ist das was unter "Traffic Selection" im ASA Screenshot steht.
Du kannst ja sehen das die Traffic Counter für den Tunneltraffic komplett auf 0 stehen. Es geht also kein einziges Paket in den Tunnel !
Hast du den extended Ping mal gemacht von der ASA direkt indem du als Ziel die 192.168.83er LAN IP der PA angibst und bei extended Commands dann als Source die eigene 192.168.0er LAN IP der ASA ?
Dann generierst du dediziert diesen Traffic.
Mitglied: Yannosch
Yannosch 22.02.2018 aktualisiert um 09:17:41 Uhr
Goto Top
Danke schonmal für deine Geduld!

eine Source IP beim extended ping anzugeben war mir leider nicht möglich .... leider hat es auch so nicht funktioniert...

ciscoasa# ping
TCP Ping [n]:
Interface: Outside
Target IP address: 192.168.83.254
Repeat count: [5]
Datagram size: [100]
Timeout in seconds: [2]
Extended commands [n]: yes
Verbose? [no]:
Validate reply data? [no]:
Data pattern [0xabcd]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.83.254, timeout is 2 seconds:
?????
Success rate is 0 percent (0/5)

Wusste leider nicht von welchem Interface auszugehen ist ,... deswegen habe ich inside auch noch versucht .. mit dem selben Ergebnis:

ciscoasa# ping
TCP Ping [n]:
Interface: inside
Target IP address: 192.168.83.254
Repeat count: [5]
Datagram size: [100]
Timeout in seconds: [2]
Extended commands [n]: yes
Verbose? [no]:
Validate reply data? [no]:
Data pattern [0xabcd]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.83.254, timeout is 2 seconds:
?????
Success rate is 0 percent (0/5)
ciscoasa#

EDIT
Bei traceroute kann ich auch eine source IP angeben ...

EDIT2
bei einem simplen traceroute auf eine IP im 83.er Netz sieht man, dass er hier über unseren externen Provider DNS versucht zu gehen.

ciscoasa# traceroute 192.168.83.254

Type escape sequence to abort.
Tracing the route to 192.168.83.254

 1  10.200.160.1 10 msec 10 msec 10 msec
 2  gw-gh-xe-2-0-2-901.pop-goldhausen.ww.net.ktk.de (212.7.161.33) 0 msec 10 mse                           c 10 msec
 3  gw-eh-ae-1-901.ehpop.ww.net.ktk.de (212.7.161.185) 10 msec 10 msec 10 msec
 4   *  *  *
 5   *  *  *
 6   *  *  *

Ähnliches vorgehen also wie bei einem traceroute auf google.de

ciscoasa# traceroute google.de

Type escape sequence to abort.
Tracing the route to 216.58.210.3

 1  10.200.160.1 10 msec 0 msec 10 msec
 2  gw-gh-xe-2-0-2-901.pop-goldhausen.ww.net.ktk.de (212.7.161.33) 10 msec 0 msec 0 msec
 3  gw3-ae-0-901.hv-fb.ko.net.ktk.de (212.7.161.189) 10 msec 10 msec 10 msec
 4  gw2-xe-2-0-1.kl90.ffm.net.ktk.de (212.7.161.29) 10 msec 0 msec 10 msec
 5  212.7.161.26 10 msec 10 msec 10 msec
 6   *  *  *
 7  209.85.251.239 0 msec
    216.239.40.57 0 msec
    209.85.251.239 10 msec
 8  google.de (216.58.210.3) 10 msec 10 msec 10 msec
Mitglied: Yannosch
Yannosch 26.02.2018 um 08:35:04 Uhr
Goto Top
@aqui,

hast du zufälligerweise noch was gefunden?
Bekomme es leider nicht zum laufen den Kram.

lg Yannosch
Mitglied: aqui
aqui 26.02.2018 aktualisiert um 09:53:43 Uhr
Goto Top
eine Source IP beim extended ping anzugeben war mir leider nicht möglich
Doch ! Du hast leider den Menü Dialog nicht gelesen face-wink
ciscoasa# ping
TCP Ping [n]:
Interface: inside

Inside ist das Source Interface. Der Dialog ist bei der ASA etwas anders als beim Router...sorry. Inside ist also richtig wenn das das Interface des lokalen LANs ist.
Fakt ist aber das die ICMPs ja nicht durchkommen. Nun stellt sich die Frage woran das liegt...
  • ICMP geblockt auf der ASA Seite ?
  • ICMP geblockt auf der PA Seite ?
Da die VPN Tunnel mit den korrekten SAs ja aufgebaut sind kann es nur noch einer der Firewall Regeln sein.
Ggf. testest du mal mit Traceroute und TCP statt ICMP.
traceroute -T -p 80 <webGUI_IP>
schickt z.B. TCP Traceroutes auf einen Webserver so das die Falle ICMP hier nicht lauert.
Alternativ einen TCP Ping von der Firewall machen oben im Extended Menü.
Du musst jetzt rausfinden wo und auf welcher Seite deine fehlende oder falsche ACL bzw. Firewall Regel ist die die Kommunikation zwischen diesen beiden Netzen blockiert.
Auf der ASA kann man dazu mal die ACL debuggen und sehen ob die Hits oder Blocks melden usw.
Mitglied: Yannosch
Yannosch 26.02.2018 um 12:31:48 Uhr
Goto Top
Hi @aqui,

danke erstmal für deine Geduld.
Ich glaube allerdings dass es nicht an einer einfachen ACL Rule liegt. Hier stimmt etwas grundlegend nicht.

Zitat von @aqui:

eine Source IP beim extended ping anzugeben war mir leider nicht möglich
Doch ! Du hast leider den Menü Dialog nicht gelesen face-wink ciscoasa# ping
TCP Ping [n]:
Interface: inside

Inside ist das Source Interface. Der Dialog ist bei der ASA etwas anders als beim Router...sorry. Inside ist also richtig wenn das das Interface des lokalen LANs ist.

Leider klappt das aber auch nicht - definitv sogar - ich habe es gerade getestet.

Fakt ist aber das die ICMPs ja nicht durchkommen. Nun stellt sich die Frage woran das liegt...
  • ICMP geblockt auf der ASA Seite ?
  • ICMP geblockt auf der PA Seite ?

Es ist auf beiden Seiten erlaubt. Zu 100%

Da die VPN Tunnel mit den korrekten SAs ja aufgebaut sind kann es nur noch einer der Firewall Regeln sein.
Ggf. testest du mal mit Traceroute und TCP statt ICMP.
traceroute -T -p 80 <webGUI_IP>
schickt z.B. TCP Traceroutes auf einen Webserver so das die Falle ICMP hier nicht lauert.

Dieser Befehl funktioniert nicht über die SSH CLI.

Alternativ einen TCP Ping von der Firewall machen oben im Extended Menü.

Über das Extended Menü konnte ich den TCP Ping starten. Habe allerdings eine success rate von 0,0%

Du musst jetzt rausfinden wo und auf welcher Seite deine fehlende oder falsche ACL bzw. Firewall Regel ist die die Kommunikation zwischen diesen beiden Netzen blockiert.

Es fängt doch schon da an, dass ich beim Tracert aus dem Palo Alto Netz bei der IP XX.XXX.72.65 statt auf der öffentlichen IP XX.XXX.72.66 lande. Das kann ich schonmal nicht nachvollziehen, das diese zweite IP da zu suchen hat.

Außerdem bekomme ich keine Informationen aus irgendwelchen tracerts, traceroutes oder pings weil ALLES nicht funktioniert. Quasie alsob es den Tunnel [der immernoch aktiv & grün ist] gar nicht gibt.

Auf der ASA kann man dazu mal die ACL debuggen und sehen ob die Hits oder Blocks melden usw.

ciscoasa# packet-tracer input inside tcp 192.168.0.1 80 192.168.83.16 80 ?

  detailed  Dump more detailed information
  xml       Output in xml format
  <cr>
ciscoasa# packet-tracer input inside tcp 192.168.0.1 80 192.168.83.16 80

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         outside

Phase: 3
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

ciscoasa#

Das sieht halt wieder nach einer ACL Rule aus .... ich weiß langsam echt nicht mehr weiter ...
Mitglied: aqui
aqui 26.02.2018 um 12:57:57 Uhr
Goto Top
Dieser Befehl funktioniert nicht über die SSH CLI.
Nein, kann er auch nicht. Das ist ein Unix Kommando. Winblows kann m.E. auch keinen TCP basierten Ping. Ggf. nur mit externer Software. Siehe dazu auch hier:
https://www.heise.de/ct/ausgabe/2018-4-Server-Verfuegbarkeit-und-Sicherh ...
dass ich beim Tracert aus dem Palo Alto Netz bei der IP XX.XXX.72.65 statt auf der ..lande
WO ist denn diese IP XX.XXX.72.65 ??
Eigentlich darf die im internen Ping der lokalen LAN Netze niemals sichtbar bzw. involviert sein. Klar, denn die könnten ja niemals RFC 1918 IP Netze routen.
Hier stimmt m.E. also generell schon was nicht in der Routing Tabelle. Möglich das PA es so anzeigt (ich kenne die HW nicht) aber es wäre sehr ungewöhnlich.
Nur noch ein Tip zur ASA:
Hier musst du zwingend darauf aufpassen das das Zielnetzwerk 192.168.83.0 /24 vom NAT Prozess am outbound Interface ausgeschlossen ist. (Beim Router das "nat overload" Kommando) Ansonsten routet die ASA das via Outbound NAT zum Provider und es gelangt nie in den VPN Tunnel !
Das gleiche gilt natürlich auch auf der PA Seite.
Mitglied: Yannosch
Yannosch 27.02.2018 um 09:09:05 Uhr
Goto Top
Zitat von @aqui:

Dieser Befehl funktioniert nicht über die SSH CLI.
Nein, kann er auch nicht. Das ist ein Unix Kommando. Winblows kann m.E. auch keinen TCP basierten Ping. Ggf. nur mit externer Software. Siehe dazu auch hier:
https://www.heise.de/ct/ausgabe/2018-4-Server-Verfuegbarkeit-und-Sicherh ...

Genau das selbe denke ich auch ... nur ohne zu wissen wo die öfftl. IPs herkommen wirds schwierig ...

dass ich beim Tracert aus dem Palo Alto Netz bei der IP XX.XXX.72.65 statt auf der ..lande
WO ist denn diese IP XX.XXX.72.65 ??
Eigentlich darf die im internen Ping der lokalen LAN Netze niemals sichtbar bzw. involviert sein. Klar, denn die könnten ja niemals RFC 1918 IP Netze routen.

die ersten 3 Einträge der Routing Table der Palo Alto machen mich schon stutzig irgendwie ...

VIRTUAL ROUTER: VR_01 (id 2)
  ==========
destination                                 nexthop                                 metric flags      age   interface          next-AS
0.0.0.0/0                                   XX.XXX.72.65                            10     A S              ethernet1/2
XX.XXX.72.64/29                             XX.XXX.72.66                            0      A C              ethernet1/2
XX.XXX.72.66/32                             0.0.0.0                                 0      A H

Hier stimmt m.E. also generell schon was nicht in der Routing Tabelle. Möglich das PA es so anzeigt (ich kenne die HW nicht) aber es wäre sehr ungewöhnlich.

Da stimme ich zu. Nur ich weiß leider nicht wie die erste Regel zu Interpretieren ist... & vor allem weiß ich nicht welches Gerät/Interface die diese omninösen IP Adressen haben soll.

Wenn ich aus dem PA Netz auf www.wieistmeineip.de zugreife bekomme ich die XX.XXX.72.66 angezeigt.
Auch das Outside Interface hat die XX.XXX.72.66 als IP angezeigt. Daher habe ich wirklich KEINE Ahnung woher diese 65er herkommt. geschweige denn die 64er die ebenfalls in der Routingtable vorhanden ist.

Das ist halt wenn man so ne Bruchbude hingeworfen bekommt...

Nur noch ein Tip zur ASA:
Hier musst du zwingend darauf aufpassen das das Zielnetzwerk 192.168.83.0 /24 vom NAT Prozess am outbound Interface ausgeschlossen ist. (Beim Router das "nat overload" Kommando) Ansonsten routet die ASA das via Outbound NAT zum Provider und es gelangt nie in den VPN Tunnel !

Genau das wird noch fehlen. Diese Outbound Regel werde ich noch nachpflegen, sollte auch kein Problem sein ... nur denke ich muss die Sache mit der Palo Alto Routerei noch in den Griff bekommen werden ...

Das gleiche gilt natürlich auch auf der PA Seite.

Stimme zu.

Danke für deine Hilfe bis hierher.
Aber ich blicke da nicht durch ...
Mitglied: aqui
aqui 27.02.2018 um 10:20:37 Uhr
Goto Top
nur ohne zu wissen wo die öfftl. IPs herkommen wirds schwierig ...
Es sieht ja so aus als ob du die öffentlichen IP Adressen im Internet Port (vlan 2) irgendwie per DHCP beziehst.
Ein Blick in die FW Konfig sollte dir dann die aktuelle per DHCP Adresse und auch das dortige Default Gateway zeigen. Oder auch ein show ip int brief.
Nebenbei ist es schon komisch das die FW im VPN Umfeld dynamsiche IP Adressen bekommt. Wie willst du denn damit statische Tunnel sicherstellen ? Oder gibt es dort ein Mac Adress Nailing auf die Mac Adresse der FW im vlan 2 Interface ?
Gut möglich das also diese IP das Provider Default Gateway ist was die Sache dann aber umso schlimmer macht, zeigt es ja dann eindeutig das interne VPN Pings ins öffentliche Internet gehen, was nie sein darf.
Das Internet Segment hat einen /29 Prefix was dann also die IP Adressen XX.XXX.72.65 bis XX.XXX.72.70 inkludiert.
Der Provider nimmt sich immer in der Regel die erste .65 als Default Gateway. Das würde dann passen, denn die Default Route zeigt ja dorthin.
Sehr merkwürdig ist aber das Interface eth 1/2 ??
Die .66 könnte man noch so interpretieren das das die Interface IP ist mit der 32er Maske aber was die .64 dann da zu suchen hat ist schon komisch. Das sieht in der Tat irgendwie merkwürdig aus als ob da irgendwas nicht stimmt.
auf www.wieistmeineip.de zugreife bekomme ich die XX.XXX.72.66 angezeigt.
Das würde die obige Vermutung bestätigen das die .66 die WAN IP Adfresse der PA ist.
Nur woher kommt dann die .64, die dann auch noch die .66 als Gateway hat. Das ist vollkommen wirr.
Sind da ggf. noch irgendwelche nicht bereinigten Konfig "Leichen" auf der PA ?
Daher habe ich wirklich KEINE Ahnung woher diese 65er herkommt
Das kann man noch gut erklären, denn das ist vermutlich das Provider Gateway. Da zeigt ja der Routing Hop hin.
Bekommt die PA hier auch die IP Adressen per DHCP oder irgend einer Dynmaik oder ist die statisch definiert ? Dynamische Vergaben wären in einem VPN Umfeld ja eher unüblich, deshalb auch die Frage bei der ASA wo das ja auch der Fall zu sein scheint ?!
geschweige denn die 64er die ebenfalls in der Routingtable vorhanden ist.
Das ist in der Tat die große Frage....das gehört da ganz sicher NICHT hin und wird vermutlich die Wurzel des Übels sein !
muss die Sache mit der Palo Alto Routerei noch in den Griff bekommen werden ...
Richtig ! Zur Not nochmal nackig machen und Step für Step neu aufsetzen wenn das möglich ist.
Mitglied: Yannosch
Yannosch 27.02.2018 um 10:35:59 Uhr
Goto Top
Zitat von @aqui:

nur ohne zu wissen wo die öfftl. IPs herkommen wirds schwierig ...
Es sieht ja so aus als ob du die öffentlichen IP Adressen im Internet Port (vlan 2) irgendwie per DHCP beziehst.
Ein Blick in die FW Konfig sollte dir dann die aktuelle per DHCP Adresse und auch das dortige Default Gateway zeigen. Oder auch ein show ip int brief.
Nebenbei ist es schon komisch das die FW im VPN Umfeld dynamsiche IP Adressen bekommt. Wie willst du denn damit statische Tunnel sicherstellen ? Oder gibt es dort ein Mac Adress Nailing auf die Mac Adresse der FW im vlan 2 Interface ?
Gut möglich das also diese IP das Provider Default Gateway ist was die Sache dann aber umso schlimmer macht, zeigt es ja dann eindeutig das interne VPN Pings ins öffentliche Internet gehen, was nie sein darf.
Das Internet Segment hat einen /29 Prefix was dann also die IP Adressen XX.XXX.72.65 bis XX.XXX.72.70 inkludiert.
Der Provider nimmt sich immer in der Regel die erste .65 als Default Gateway. Das würde dann passen, denn die Default Route zeigt ja dorthin.
Sehr merkwürdig ist aber das Interface eth 1/2 ??
Die .66 könnte man noch so interpretieren das das die Interface IP ist mit der 32er Maske aber was die .64 dann da zu suchen hat ist schon komisch. Das sieht in der Tat irgendwie merkwürdig aus als ob da irgendwas nicht stimmt.
auf www.wieistmeineip.de zugreife bekomme ich die XX.XXX.72.66 angezeigt.
Das würde die obige Vermutung bestätigen das die .66 die WAN IP Adfresse der PA ist.
Nur woher kommt dann die .64, die dann auch noch die .66 als Gateway hat. Das ist vollkommen wirr.
Sind da ggf. noch irgendwelche nicht bereinigten Konfig "Leichen" auf der PA ?

Ich glaube die Route mit der .64 ist eine Leiche & die .65 ist dann definitv das Providergateway.

Daher habe ich wirklich KEINE Ahnung woher diese 65er herkommt
Das kann man noch gut erklären, denn das ist vermutlich das Provider Gateway. Da zeigt ja der Routing Hop hin.

So wird es vermutlich sein, ja.

Bekommt die PA hier auch die IP Adressen per DHCP oder irgend einer Dynmaik oder ist die statisch definiert ? Dynamische Vergaben wären in einem VPN Umfeld ja eher unüblich, deshalb auch die Frage bei der ASA wo das ja auch der Fall zu sein scheint ?!

Die ASA bekommt die IP Dynamisch vom Thomson Modem davor zugewiesen. Diese änderte sich in den letzten 2 Jahren nicht einmal [providerbedingt] , selbst nach Neustart der ASA & des Thompsons.

Die PA hat die .65er Adresse auf Interface eth 1/2 STATISCH konfiguriert.

Ist also eigentlich eine schlüssige Erklärung, dass es sich bei der .65er um das Provider Gateway handelt.
Tut das der Sache einen Abbruch?

geschweige denn die 64er die ebenfalls in der Routingtable vorhanden ist.
Das ist in der Tat die große Frage....das gehört da ganz sicher NICHT hin und wird vermutlich die Wurzel des Übels sein !

Dann werde ich diese in einer ruhigen Minute einmal entfernen.

muss die Sache mit der Palo Alto Routerei noch in den Griff bekommen werden ...
Richtig ! Zur Not nochmal nackig machen und Step für Step neu aufsetzen wenn das möglich ist.
Leider nicht möglich da nahezu 24/7 per C2S VPN in dem PA Netz gearbeitet wird & eine neue PA "sicherlich zu teuer wäre".
Mitglied: aqui
aqui 27.02.2018 um 17:38:48 Uhr
Goto Top
Tut das der Sache einen Abbruch?
Nein, wenn die ASA immer die gleiche IP, unter welchen Bedingungen auch immer, vom Kabel TV Modem bekommt dann ist alles gut. Das ist ja dann quasi wie eine statische IP face-wink
Leider nicht möglich da nahezu 24/7
Ist ja auch kein Problem. Wenn du die Reste alter Konfigs die da ihr Unwesen treiben vollständig alle entfernst sollte ja auch so ein sauberer Stand errreicht werden.
Viel Erfolg !
Mitglied: Yannosch
Yannosch 01.03.2018 aktualisiert um 10:21:32 Uhr
Goto Top
Zitat von @aqui:

Tut das der Sache einen Abbruch?
Nein, wenn die ASA immer die gleiche IP, unter welchen Bedingungen auch immer, vom Kabel TV Modem bekommt dann ist alles gut. Das ist ja dann quasi wie eine statische IP face-wink
Leider nicht möglich da nahezu 24/7
Ist ja auch kein Problem. Wenn du die Reste alter Konfigs die da ihr Unwesen treiben vollständig alle entfernst sollte ja auch so ein sauberer Stand errreicht werden.

Ich kann die Routen nicht mal löschen face-big-smile ... ich geb's auf. Ich frage & bezahle jetzt jemanden von PaloAlto. Das frustriert mich zu sehr.

XX.154.72.64/29                             XX.154.72.66                            0      A C              ethernet1/2

Die Route kann ich sehen, da es aber keine statische Route ist, kann ich sie auch nicht löschen.

Viel Erfolg !
Mitglied: brammer
brammer 01.03.2018 um 10:26:31 Uhr
Goto Top
Hallo,

Leider nicht möglich da nahezu 24/7 per C2S VPN in dem PA Netz gearbeitet wird & eine neue PA "sicherlich zu teuer wäre".

bei nahezu 24/7 würde ich die PA heute Nacht per Task einfach mal durchstarten lassen.

brammer
Mitglied: Yannosch
Yannosch 01.03.2018 um 10:41:42 Uhr
Goto Top
Frage mich nur was das bringen soll.

Die Fakten sind aus dem gesamten Verlauf zu erlesen.

Alles läuft wie es soll, bis auf den fehlenden traffic im l2l Tunnel.

Wenn du einen Konkreten Hinweis hast zur genannten Konstellation - dann sag ihn mir bitte. Äußerungen wie "schon mal mit Ein- und Ausschalten versucht" bringen mein Gemüt nur weiter zum kochen. Sorry, aber der Kram frustet so sehr - dass kann man kaum in Worte fassen!

Gruß
Yannosch
Mitglied: brammer
brammer 01.03.2018 um 13:55:33 Uhr
Goto Top
Hallo,

da du aktuell wohl davon ausgehst das du Leichen in der Konfiguration hast, ist der Versuch die PA einmal durchzustarten eine Möglichkeit diese loszuwerden.
Daher ist mein Hinweis nicht als "schon mal mit Ein- und Ausschalten versucht" zu verstehen.
Das wäre nicht die Erste Gurke die erst nach einem Neustart sauber arbeitet... auch wenn das nicht sein sollte.

brammer
Mitglied: Yannosch
Yannosch 01.03.2018 um 15:51:06 Uhr
Goto Top
Zitat von @brammer:

Hallo,

da du aktuell wohl davon ausgehst das du Leichen in der Konfiguration hast, ist der Versuch die PA einmal durchzustarten eine Möglichkeit diese loszuwerden.
Daher ist mein Hinweis nicht als "schon mal mit Ein- und Ausschalten versucht" zu verstehen.

Ich wage es gar nicht auszusprechen ... aber ich habe nach dem Neustart beider Endpunkte zumindest RX Traffic auf der ASA zu verzeichnen.

Ein Ping vom PA Netz zum ASA Netz geht trotzdem noch nicht, aber es scheint wenigstens schonmal was über den Tunnel geschoben zu werden.

traffic

Leider bin ich jetzt nur nicht schlauer als vorher ... face-confused

Das wäre nicht die Erste Gurke die erst nach einem Neustart sauber arbeitet... auch wenn das nicht sein sollte.

brammer

Grüße
Yannosch
Mitglied: brammer
brammer 01.03.2018 um 15:59:57 Uhr
Goto Top
Hallo,

was sagt den ein

sh cry ipsec SA peer <peer_ip>

auf der ASA?

brammer
Mitglied: Yannosch
Yannosch 01.03.2018 um 16:10:58 Uhr
Goto Top
Zitat von @brammer:

Hallo,

was sagt den ein

sh cry ipsec SA peer <peer_ip>

auf der ASA?

brammer

Folgendes ...

peer address: ?0.154.72.66
    Crypto map tag: outside_map, seq num: 1, local addr: ?.57.193.143

      access-list outside_1_cryptomap extended permit ip 192.168.0.0 255.255.255.0 192.168.83.0 255.255.255.0 
      local ident (addr/mask/prot/port): (192.168.0.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (remote-network/255.255.255.0/0/0)
      current_peer: ?0.154.72.66


      #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
      #pkts decaps: 253, #pkts decrypt: 253, #pkts verify: 253
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #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.: ?.57.193.143/0, remote crypto endpt.: ?0.154.72.66/0
      path mtu 1500, ipsec overhead 74(44), media mtu 1500
      PMTU time remaining (sec): 0, DF policy: copy-df
      ICMP error validation: disabled, TFC packets: disabled
      current outbound spi: F0D6763C
      current inbound spi : 3953C35D

    inbound esp sas:
      spi: 0x3953C35D (961790813)
         transform: esp-aes-256 esp-sha-hmac no compression 
         in use settings ={L2L, Tunnel, PFS Group 5, IKEv1, }
         slot: 0, conn_id: 4096, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (3914986/2132)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap: 
          0xFFFFFFFF 0xFFFFFFFF
    outbound esp sas:
      spi: 0xF0D6763C (4040586812)
         transform: esp-aes-256 esp-sha-hmac no compression 
         in use settings ={L2L, Tunnel, PFS Group 5, IKEv1, }
         slot: 0, conn_id: 4096, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (3915000/2132)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap: 
          0x00000000 0x00000001

Sagt dir das was ?

LG & schonmal danke für deine Hilfe!
Mitglied: Yannosch
Yannosch 01.03.2018 um 17:21:02 Uhr
Goto Top
UPDATE:

Habe die NAT Regel auf der Cisco nochmal angepasst ... jetzt komme ich vom ASA Netz auf die Palo Alto Seite mit allem.

Danke für die Hilfe bis hierher ... wenn noch was unklar ist melde ich mich nochmal !
Mitglied: brammer
brammer 01.03.2018 um 17:27:18 Uhr
Goto Top
Hallo,

Wenn du jetzt noch mal den Befehl von oben auf der ASA eingibst sollte der Counter bei "packet encaps" auch hochzählen.

Was genau hast du an der NAT Regel den angepasst?

Brammer
Mitglied: Yannosch
Yannosch 01.03.2018 aktualisiert um 18:25:11 Uhr
Goto Top
Habe folgende Regel erstellt:

speichern

aber jetzt habe ich mit meinem Rechner zwar Zugriff auf das PaloAlto Netz aber alles andere ist tot...

EDIT:

Wenn ich folgende NAT-Regel reinmache:
nat

Im Detail:
nat2

Dann funktioniert es am TestClient [192.168.0.10] reibungslos.

Wenn ich jedoch das gesamte Inside-Network statt dem Test Client nehme [sprich 192.168.0.1/24] - haben diverse Rechner kein Netzwerk mehr, die VoIP Telefone funktionieren nicht mehr ... also im Grunde klappt dann gar nichts mehr.

Heißt das im Umkehrschluss, dass ich für jeden Host eine einzelne NAT Regel machen muss?
Würde doch einen enormen Aufwand bedeuten wenn ich mich nicht irre.

Wunder mich echt nur dass am TestClient alles funktioniert.

Alles in Allem eher mehr Zufallsprodukte.
Mitglied: aqui
aqui 02.03.2018 aktualisiert um 09:32:07 Uhr
Goto Top
Warum denn NAT ??
Du musst die VPN Netze selber doch keinesfalls NATen ! Diese Netze müssen zwingend aus der NAT Regel ausgenommen werden wie oben ja schon mehrfach gesagt.
Das ist dann ziemlich kontraproduktiv weil die NAT Firewall dir dann das Routing der internen IP Netze in eine Einbahnstrasse verwandelt.
VPN Netze, sprich also die lokalen Netze die über VPN verbunden sind, werden doch niemals geNATet !
Da stimmt dann generell was nicht an deinem Design, was die Vewränderung der NAT Regel ja schon erahnen lässt.
Oder haben wir das jetzt missverstanden hier...?!
Mitglied: Yannosch
Yannosch 02.03.2018 um 09:41:40 Uhr
Goto Top
Zitat von @aqui:

Warum denn NAT ??
Du musst die VPN Netze selber doch keinesfalls NATen ! Diese Netze müssen zwingend aus der NAT Regel ausgenommen werden wie oben ja schon mehrfach gesagt.
Das ist dann ziemlich kontraproduktiv weil die NAT Firewall dir dann das Routing der internen IP Netze in eine Einbahnstrasse verwandelt.
VPN Netze, sprich also die lokalen Netze die über VPN verbunden sind, werden doch niemals geNATet !
Da stimmt dann generell was nicht an deinem Design, was die Vewränderung der NAT Regel ja schon erahnen lässt.
Oder haben wir das jetzt missverstanden hier...?!

Hi ich glaube eher etwas missverstanden.
Ich habe doch eine NAT Exemption Regel angelegt.

Das von dem TestClient zum Remote Netz die Source addresse beim Original bleibt
Sollte aus der NAT Regel ersichtlich sein.

Wenn ich die NAT Regel jetzt so verändere, dass das gesamte Insidenetwork zum Remote Network aus dem NAT genommen wird Klappt gar nichts mehr irgendwie ... also was das netzwerk betrifft.
Mitglied: aqui
Lösung aqui 02.03.2018 aktualisiert um 10:01:14 Uhr
Goto Top
dass das gesamte Insidenetwork zum Remote Network aus dem NAT genommen wird Klappt gar nichts mehr
Das ist aber sehr ungewöhnlich ! Das sollte nicht so sein !
Hier als Beispiel mal eine Overload NAT ACL von einem Cisco Router:
access-list 101 deny ip 172.16.1.0 0.0.0.255 172.16.0.0 0.0.255.255
access-list 101 deny ip 172.16.11.0 0.0.0.255 172.16.0.0 0.0.255.255
access-list 101 deny ip 172.16.111.0 0.0.0.255 172.16.0.0 0.0.255.255
access-list 101 permit ip 172.16.11.0 0.0.0.255 any

Die lokalen Netze sind .1.0, .11.0 und .111.0 die mit weiteren remoten /24er IP Netzen mit einem 172.16er Prefix über die VPN Tunnel kommunizieren. Das .11er darf ins Internet.
Die ACL nimmt diese explizit aus dem NAT Prozess auch natürlich auf der Gegenseite. Das muss auch so sein, ansonsten würde das NAT ja ein transparentes Routing dieser internen IP Netze verhindern.
Nicht das das das Grundübel ist bei dir ?!
So ein bischen riecht es danach ja, denn wenn Tunnel usw. sauber aufgebaut ist kann es am eigentlichen VPN nicht mehr liegen. Dafür sprechen die nur einseitigen Traffic Counter bei dir und wenn du an der NAT Regel manipulierst das es dann mal geht und mal nicht. Diese Symptome würden in das Fehlerbild passen.
Natürlich musst du nicht alle Hosts einzeln eintragen. Es reichen natürlich die IP Netze mit den korrekten Masken die über den Tunnel kommunizieren.
Mitglied: Yannosch
Yannosch 02.03.2018 aktualisiert um 10:05:31 Uhr
Goto Top
Nur leider habe ich sowas nicht über die CLI gemacht bisher ...

Kannst du mir sagen wie ich es in meinem Fall anlegen müsste?

Inside Network ASA [alle sollen dann über den eigenen Internetanschluss gehen]
192.168.0.0/24

Remote Network Palo Alto
192.168.83.0/24

Syntax müsste für meine ASA ja die selbe sein.

Dann versuche ich es am Wochenende mal.

Will halt jetzt ungern auf gut Glück versuchen.

LG Yannosch
Mitglied: aqui
Lösung aqui 02.03.2018 aktualisiert um 10:13:48 Uhr
Goto Top
Wenn du intern nur 192.168.er IP Netze hast dann reicht eine NAT ACL die sagt:
DENY ip 192.168.0.0 255.255.255.0 --> 192.168.0.0 255.255.0.0
PERMIT ip 192.168.0.0 255.255.255.0 --> any


Das verbietet dann das NAT bei allen Zielnetzen im 192.168er Bereich mit dem das .0.0er Netz via VPN Tunnel redet und alles andere was sonstwohin geht aus dem .0.0er Netz wird outbound geNATet.
Wichtig ist hier natürlich wieder die Reihenfolge. Das DENY Statement muss wie immer natürlich ganz an den Anfang der ACL !
Mitglied: Yannosch
Yannosch 02.03.2018 um 10:18:13 Uhr
Goto Top
Hi Aqui,


Zitat von @aqui:

Wenn du intern nur 192.168.er IP Netze hast dann reicht eine NAT ACL die sagt: DENY ip 192.168.0.0 255.255.255.0 --> 192.168.0.0 255.255.0.0

Vom 0er zum 0er ? oder sollte das zweite das 83.er sein? Sonst blick ich die Regel irgendwie nicht.

PERMIT ip 192.168.0.0 255.255.255.0 --> any

Okay ... Permit zum Schluss ... & die Syntac ist genauso?

Gibt es auch einen Befehl der mir alle ACLs zeigt ?

LG Yannosch
Mitglied: aqui
Lösung aqui 02.03.2018 aktualisiert um 10:39:38 Uhr
Goto Top
Vom 0er zum 0er ?
Sieh mal genau auf die Maske face-wink
Dort ist eine /16er Maske fürs Ziel angegeben. D.h. er denied vom NAT alles was vom .0.0er Netz in alle anderen 192.168er Netze geht.
Gibt es auch einen Befehl der mir alle ACLs zeigt ?
Beim Cisco IOS ist das show (ip) access-list bei der ASA Syntax wird das vermutlich etwas anders sein.
Mitglied: Yannosch
Yannosch 02.03.2018 aktualisiert um 10:47:47 Uhr
Goto Top
Ahh okay ...

aber Syntax wäre dann bestimmt beim Erstellen einer ACL bei der ASA auch eine andere oder?

Danke für die Infos ich versuche es am Wochenende mal damit ... muss nur schauen wo ich die korrekte Syntax herbekomme ...

Danke nochmals!
LG Yannosch
Mitglied: aqui
Lösung aqui 02.03.2018 aktualisiert um 10:59:06 Uhr
Goto Top
Ja, die ASA nutz ja eine Definition statt dedizierter Interface Bezeichnungen.
Muss ich meine olle ASA hier mal rauskramen und checken... face-smile
Google auf der Cisco Seite mal nach ASA Konfig und NAT da gibts zuhauf Beispielkonfigs aus denen die Syntax ersichtlich ist.
Hier findet man auch was dazu:
http://www.firewall.cx
Mitglied: Yannosch
Yannosch 02.03.2018 um 11:05:48 Uhr
Goto Top
Das habe ich bei Cisco gefunden:

The following examples show how to configure NAT exemption.

To exempt an inside network when accessing any destination address, enter the following command:

hostname(config)# access-list EXEMPT permit ip 10.1.2.0 255.255.255.0 any

hostname(config)# nat (inside) 0 access-list EXEMPT

To use dynamic outside NAT for a DMZ network, and exempt another DMZ network, enter the following command:

hostname(config)# nat (dmz) 1 10.1.2.0 255.255.255.0 outside dns

hostname(config)# global (inside) 1 10.1.1.45

hostname(config)# access-list EXEMPT permit ip 10.1.3.0 255.255.255.0 any

hostname(config)# nat (dmz) 0 access-list EXEMPT

To exempt an inside address when accessing two different destination addresses, enter the following commands:

hostname(config)# access-list NET1 permit ip 10.1.2.0 255.255.255.0 209.165.201.0
255.255.255.224

hostname(config)# access-list NET1 permit ip 10.1.2.0 255.255.255.0 209.165.200.224
255.255.255.224

hostname(config)# nat (inside) 0 access-list NET1


Leider weiß ich da nicht was was ist face-big-smile ... Kommt mir das nur so vor oder ist Cisco irgendwie sau kompliziert?
Mitglied: aqui
Lösung aqui 02.03.2018 um 17:22:55 Uhr
Goto Top
Na ja wie man es nimmt...
Das Kommando nat (inside) 0 access-list EXEMPT ist analog zu dem ip nat-inside unter IOS nur das man bei der ASA eine ACL gleich mitgeben kann.
Die ACL mit dem Namen EXEMPT nimmt also das 10.1.2.0 /24 Netz vom NAT aus.
Da müsstest du entweder 192.168.0.0 /16 nehmen oder alle /24 internen Subnetze aufführen.
Bestes Beispiel dazu ist das letzte mit der NET1 ACL
Bei dir müsste also stehen:
access-list NET1 permit ip 192.168.0.0 255.255.255.0 192.168.0.0 255.255.0.0
(Alle 192.168er Netze werden ausgenommen)
Oder die Netze einzeln
access-list NET1 permit ip 192.168.0.0 255.255.255.0 192.168.83.0 255.255.255.0
access-list NET1 permit ip 192.168.0.0 255.255.255.0 192.168.xy.0 255.255.255.0
usw.
Mitglied: Yannosch
Yannosch 04.03.2018 aktualisiert um 14:00:10 Uhr
Goto Top
Hi Aqui,

nach ASA Software 8.4 sind ist nat (inside) 0 access-list EXEMPT nicht mehr möglich.

So sind leider nur noch statische NAT Regeln möglich.

Folgendes habe ich von einer Seite aus dem Netz übernommen:

object network obj-10.0.8.0
   subnet 10.0.8.0 255.255.255.0

object network obj-172.16.20.0
   subnet 172.16.20.0 255.255.255.0

nat (inside,any) source static obj-10.0.8.0 obj-10.0.8.0 destination static obj-172.16.20.0 obj-172.16.20.0

Danach funktioniert es bei mir am Rechner, nur alle anderen Clients im Netz bekommen keine IP Adresse zugewiesen, was ich äußerst komisch finde... Ist leider der aktuelle Stand der Dinge. Mit der Regel funktioniert es, aber andere Störungen treten auf.

natsogood

Ich starte das Ding jetzt nochmal neu, vielleicht klappt es ja dann. Aber scheinbar ist es so nicht möglich umzusetzen.

Nochmals betont, nach dem Starten bekommen andere Netzwerkgeräte keine IP mehr zugewiesen & sind somit komplett tot was das Netzwerk betrifft.

Vielleicht hast du eine Idee?

LG Yannosch


EDIT:

Ein IPScan zeigt mir das an - total komisch ... alle Adressen als alive & Hersteller Cisco.... was läuft hier denn falsch??? Oh man....


EDIT2:

arp

Nachdem der Haken gesetzt wurde funktioniert alles ... bzw. vom ASA Netz ins PaloAlto Netz funktioniert es wunderbar. RDP usw. alles möglich.

Lag scheinbar an diesem einen Haken ...

Technisch weiß ich leider allerdings nicht warum.

LG Yannosch
Mitglied: aqui
Lösung aqui 04.03.2018 aktualisiert um 16:52:04 Uhr
Goto Top
nur alle anderen Clients im Netz bekommen keine IP Adresse zugewiesen,
Per DHCP oder wie meinst du das ? Vergibt die ASA selber die IPs an die lokalen PCs per DHCP ?
Wäre komisch, denn das LAN Interface ist ja gar nicht betroffen ??
Lag scheinbar an diesem einen Haken ...
Mist hätt ich wissen müssen....denn darauf bin ich auch schon mal böse reingefallen face-sad
IPsec Konfig zur Client Einwahl am Cisco und 4 Wochen einen Wolf gesucht warum es nicht ging.
Letztlich war es der Eintrag no ip proxy-arp am lokalen LAN Interface. Entfernt und danach lief alles wie geschnitten Brot.
IPsec braucht Proxy ARP da es mit unnumbered Adressen auf dem lokalen LAN arbeitet. Jedenfalls in der Cisco Konfig....
Klasse wenns nun klappt. Hast ja jetzt ne Menge Geld gespart ! face-big-smile
Mitglied: Yannosch
Yannosch 04.03.2018 aktualisiert um 18:28:01 Uhr
Goto Top
Zitat von @aqui:

nur alle anderen Clients im Netz bekommen keine IP Adresse zugewiesen,
Per DHCP oder wie meinst du das ? Vergibt die ASA selber die IPs an die lokalen PCs per DHCP ?
Wäre komisch, denn das LAN Interface ist ja gar nicht betroffen ??

Die ASA macht auch DHCP auf dem internen Interface, ja. Ja keine Ahnung was da genau dazu geführt hat, aber siehe Screenshot oben ...
Alle Adressen wurden als "alive" angezeigt ... und alle Clients bekamen nur eine autoconfigured IP auf die NIC.

Lag scheinbar an diesem einen Haken ...
Mist hätt ich wissen müssen....denn darauf bin ich auch schon mal böse reingefallen face-sad

gar kein Problem face-big-smile jetzt wissen wirs... werde vielleicht mal für genau diese Konstellation mal einen Beitrag schreiben.

IPsec Konfig zur Client Einwahl am Cisco und 4 Wochen einen Wolf gesucht warum es nicht ging.

War bei mir genauso .... bin jetzt 1 Monat dran ... gibt es nicht.

Letztlich war es der Eintrag no ip proxy-arp am lokalen LAN Interface. Entfernt und danach lief alles wie geschnitten Brot.

Moment ....

IPsec braucht Proxy ARP da es mit unnumbered Adressen auf dem lokalen LAN arbeitet. Jedenfalls in der Cisco Konfig....

Ich habe aber den Haken bei "Disable Proxy ARP on Egress Interface" GESETZT nicht entfernt. In diesem Fall würde es die Cisco ja NICHT brauchen für das Site to Site VPN. Hast du dich verschrieben oder funktioniert mein VPN jetzt auf Basis einer fehlerhaften Konfig?

Klasse wenns nun klappt. Hast ja jetzt ne Menge Geld gespart ! face-big-smile

385,00 € wäre schon ein strammer Stundensatz gewesen face-big-smile

Grüße
Yannosch
Mitglied: Yannosch
Yannosch 05.03.2018 um 10:58:57 Uhr
Goto Top
Bin ein wenig verunsichert ....
Mitglied: aqui
Lösung aqui 05.03.2018 aktualisiert um 11:02:11 Uhr
Goto Top
Ich habe aber den Haken bei "Disable Proxy ARP on Egress Interface" GESETZT nicht entfernt
Auf dem Outbound Interface ist das auch so richtig. Dort gehört Proxy ARP auch aus !
Bei mir war es auch auf dem ingress (inbound) Interface aktiviert und da muss es an sein für IPsec wenn man mit unnumbered arbeitet.
Alles gut also face-wink
Mitglied: Yannosch
Yannosch 05.03.2018 um 11:06:38 Uhr
Goto Top
Super Danke für alles!!!

LG
Yannosch