60
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:
IKE Gateway:
IKE Crypto:
IPsec Crypto:
IPsec Tunnel:
Die Konfigurationen der Cisco ASA 5505 sind folgende:
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.
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
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:
IKE Gateway:
IKE Crypto:
IPsec Crypto:
IPsec Tunnel:
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:ae6814d5e23498756983745987349587Ich 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.
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 365349
Url: https://administrator.de/forum/vpn-cisco-asa5505-paloalto-pa-200-365349.html
Ausgedruckt am: 23.12.2024 um 18:12 Uhr
60 Kommentare
Neuester Kommentar
Hallo,
was sagt den auf der ASA ein
Welche ASA Software Version läuft?
brammer
was sagt den auf der ASA ein
sh crypto ipsec
sh crypto isakmpWelche ASA Software Version läuft?
brammer
Hallo,
hier: https://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiatio ...
und hier: http://firewalltipss.blogspot.de/2010/05/cisco-vpn-troubleshooting-guid ...
sind gute IPSEC Anleitungen für Fehlersuche.
MfG
hier: https://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiatio ...
und hier: http://firewalltipss.blogspot.de/2010/05/cisco-vpn-troubleshooting-guid ...
sind gute IPSEC Anleitungen für Fehlersuche.
MfG
sh crypto ipsec:
ciscoasa# sh crypto ipsec
ERROR: % Incomplete commandsh 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: 0Welche ASA Software Version läuft?
ASA Version 9.1(7)23
brammer
Grüße und Danke für die Hilfe!Yannosch
Hallo,
okay.. da läuft wohl nicht mal ein DEBUG, oder?
und dann mal ein sh log posten...
brammer
okay.. da läuft wohl nicht mal ein DEBUG, oder?
debug cry isa
debug cry ipsecund dann mal ein sh log posten...
brammer
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 loggedWo finde ich den genauen von dir gewollten log?
brammer
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.
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.
Hallo,
einfach bis zum Ende durchblättern.... mit der "Enter Taste" Zeilenweise.... mit der "Freizeichen Taste" seitenweise.
brammer
einfach bis zum Ende durchblättern.... mit der "Enter Taste" Zeilenweise.... mit der "Freizeichen Taste" seitenweise.
brammer
Habe ich nicht die möglichkeit ... da ist ende ... kann nicht weitergehen
Hallo ,
das bezweifle ich ....
https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-ne ...
brammer
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
Zitat von @brammer:
Hallo ,
das bezweifle ich ....
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:
Unter der Rubrik Debugging finde ich da nix... nur dass ich den Befehl
debug cry ipsecbrammer
Gruß Yannosch
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
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
Hallo zusammen,
danke Aqui für den Hinweis! Ich arbeite nämlich per SSH/Putty auf der Kiste.
Ich habe jetzt erst
und dann
gibt aber nach einem show log wieder die selbe Ausgabe ... also nichts spezifisches.
Der Befehl
gibt folgendes aus:
@aqui deine angesprochenen Änderungen bzgl des Exchangemode werde ich sofort umstezen und anschließend berichten.
danke Aqui für den Hinweis! Ich arbeite nämlich per SSH/Putty auf der Kiste.
Ich habe jetzt erst
terminal monitorund dann
debug cry ipsecgibt aber nach einem show log wieder die selbe Ausgabe ... also nichts spezifisches.
Der Befehl
sh crypto isakmp saThere are no IKEv1 SAs
There are no IKEv2 SAs
@aqui
ich weißt leider nicht genau weswegen es jetzt funktioniert, bzw. der Tunnel steht, aber das hier habe ich gemacht:
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
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
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 
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/
Zitat von @aqui:
Jetzt müsste bei bestehendem Tunnel dann aber ein sh crypto isakmp sa in jedem Falle den aktiven Tunnel angezeigen ? Tut es das ?
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 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: 0Leider 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
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
Zitat von @aqui:
Jetzt müsste bei bestehendem Tunnel dann aber ein sh crypto isakmp sa in jedem Falle den aktiven Tunnel angezeigen ? Tut es das ?
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 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)]
Palo Alto (Virtueller Router):
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 ...
Vielleicht fällt jemandem etwas auf den ersten Blick auf...
liebe Grüße & vielen Dank schonmal bis hierhin!
Yannosch
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.
Zitat von @aqui:
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.
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 ?
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
Hi @aqui,
also nachdem ich die Routen entfernt habe, habe ich immernoch
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:
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.
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.
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
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 !!
Hi @aqui,
ich glaube hier liegt der Watz begraben.
Das ist die Routingtabelle meiner PaloAlto [teilweise völliger Käse dabei m.M.n.]
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]
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...
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: 20Tunnel.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.65Da 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, outsideDer 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.
Hi @aqui,
Hier das Ergebnis von sh crypto ipsec sa:
Der Befehl show ip route klappt aber nicht über SSH bei meiner ASA.
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
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 0x00000001Der 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
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.
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.
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...
Wusste leider nicht von welchem Interface auszugehen ist ,... deswegen habe ich inside auch noch versucht .. mit dem selben Ergebnis:
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.
Ähnliches vorgehen also wie bei einem traceroute auf google.de
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
@aqui,
hast du zufälligerweise noch was gefunden?
Bekomme es leider nicht zum laufen den Kram.
lg Yannosch
hast du zufälligerweise noch was gefunden?
Bekomme es leider nicht zum laufen den Kram.
lg Yannosch
eine Source IP beim extended ping anzugeben war mir leider nicht möglich
Doch ! Du hast leider den Menü Dialog nicht gelesen 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 ?
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.
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.
Leider klappt das aber auch nicht - definitv sogar - ich habe es gerade getestet.
Es ist auf beiden Seiten erlaubt. Zu 100%
Dieser Befehl funktioniert nicht über die SSH CLI.
Über das Extended Menü konnte ich den TCP Ping starten. Habe allerdings eine success rate von 0,0%
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.
Das sieht halt wieder nach einer ACL Rule aus .... ich weiß langsam echt nicht mehr weiter ...
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:
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.
eine Source IP beim extended ping anzugeben war mir leider nicht möglich
Doch ! Du hast leider den Menü Dialog nicht gelesen ciscoasa# pingTCP 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.
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 ...
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.
Zitat von @aqui:
https://www.heise.de/ct/ausgabe/2018-4-Server-Verfuegbarkeit-und-Sicherh ...
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 HHier 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 !
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 ...
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.Zitat von @aqui:
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.
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 ?
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.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 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 !
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 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
... 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/2Die Route kann ich sehen, da es aber keine statische Route ist, kann ich sie auch nicht löschen.
Viel Erfolg !
Hallo,
bei nahezu 24/7 würde ich die PA heute Nacht per Task einfach mal durchstarten lassen.
brammer
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
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
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
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
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
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.
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.
Leider bin ich jetzt nur nicht schlauer als vorher ...
Das wäre nicht die Erste Gurke die erst nach einem Neustart sauber arbeitet... auch wenn das nicht sein sollte.
brammer
brammer
Grüße
Yannosch
Hallo,
was sagt den ein
auf der ASA?
brammer
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 0x00000001Sagt dir das was ?
LG & schonmal danke für deine Hilfe!
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 !
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 !
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
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
Habe folgende Regel erstellt:
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:
Im Detail:
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.
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:
Im Detail:
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.
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...?!
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...?!
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...?!
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.
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.
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
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
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 !
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 !
Hi Aqui,
Vom 0er zum 0er ? oder sollte das zweite das 83.er sein? Sonst blick ich die Regel irgendwie nicht.
Okay ... Permit zum Schluss ... & die Syntac ist genauso?
Gibt es auch einen Befehl der mir alle ACLs zeigt ?
LG Yannosch
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
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
Vom 0er zum 0er ?
Sieh mal genau auf die Maske 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.
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
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
Ja, die ASA nutz ja eine Definition statt dedizierter Interface Bezeichnungen.
Muss ich meine olle ASA hier mal rauskramen und checken...
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
Muss ich meine olle ASA hier mal rauskramen und checken...
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
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 ... Kommt mir das nur so vor oder ist Cisco irgendwie sau kompliziert?
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
... Kommt mir das nur so vor oder ist Cisco irgendwie sau kompliziert?
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.
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.
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:
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.
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:
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
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.0Danach 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.
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:
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
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 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 !
Zitat von @aqui:
Wäre komisch, denn das LAN Interface ist ja gar nicht betroffen ??
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 gar kein Problem
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 !
385,00 € wäre schon ein strammer Stundensatz gewesen
Grüße
Yannosch
Bin ein wenig verunsichert ....
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
Super Danke für alles!!!
LG
Yannosch
LG
Yannosch
