4

I have a functioning L2L tunnel between two ASA devices (HQ-FW1 and Branch-FW1 on the diagram).

Network Diagram

HQ-PC2 - 192.168.10.21
HQ-FW1 eth0 - 192.168.20.2 (outside)
HQ-FW1 eth1 - 192.168.10.2 (inside)
Branch-FW1 eth0 - 10.1.1.2 (outside)
Branch-FW1 eth1 - 10.1.10.1 (inside)
Branch-PC2 - 10.1.10.3

I have SSH configs which work for both ASAs and from their respective inside networks (Branch-PC2 -> Branch-FW1 and HQ-PC2 -> HQ-FW1) I can successfully connect with authentication performed through the HQ-AAA-Server node. I can also SSH into Branch-PC2 from HQ-PC2 showing that SSH does work over the tunnel.

However I cannot get an SSH connection from HQ-PC2 to Branch-FW1. When I try to connect there is no response and from looking at Wireshark there is no response coming back from Branch-FW1 at all (no SYN-ACK packet).

Console Output

SSH Config:

Branch-FW(config)# show ssh
Timeout: 10 minutes
Version allowed: 2
192.168.10.21 255.255.255.255 inside
192.168.10.2 255.255.255.255 inside
192.168.20.2 255.255.255.255 inside
10.1.10.1 255.255.255.255 inside
10.1.10.3 255.255.255.255 inside

I've added both the outside and inside interface addressed for HQ-FW1 just in case the source address is getting NAT'ed but it hasn't helped. I'm not sure what the issue is?

Edit: Also worth noting that the ASA does not respond to pings from the HQ network to it's inside interface.

Full Config:


: 
: Serial Number: 9A2EL3EHE12
: Hardware:   ASAv, 2048 MB RAM, CPU Pentium II 2000 MHz
: Written by admin at 14:49:01.099 UTC Fri Dec 3 2021
!
ASA Version 9.5(2)204 
!
hostname Branch-FW
domain-name asecuritycompany.com
enable password 8Ry2YjIyt7RRXU24 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
names
!
interface GigabitEthernet0/0
 description TO THE BRANCH ROUTER OUTSIDE 10.1.1.0/30 NETWORK
 nameif outside
 security-level 0
 ip address 10.1.1.2 255.255.255.252 
!
interface GigabitEthernet0/1
 description TO THE BRANCH INSIDE 10.1.10.0/24 NETWORK
 nameif inside
 security-level 100
 ip address 10.1.10.1 255.255.255.0 
!
interface GigabitEthernet0/2
 shutdown
 no nameif
 no security-level
 no ip address
!
interface GigabitEthernet0/3
 shutdown
 no nameif
 no security-level
 no ip address
!
interface GigabitEthernet0/4
 shutdown
 no nameif
 no security-level
 no ip address
!
interface GigabitEthernet0/5
 shutdown
 no nameif
 no security-level
 no ip address
!
interface GigabitEthernet0/6
 shutdown
 no nameif
 no security-level
 no ip address
!
interface Management0/0
 shutdown
 no nameif
 no security-level
 no ip address
!
ftp mode passive
dns server-group DefaultDNS
 domain-name asecuritycompany.com
same-security-traffic permit inter-interface
object network net-local
 subnet 10.1.10.0 255.255.255.0
object network net-outside
 subnet 10.1.1.0 255.255.255.252
object network net-remote
 subnet 192.168.10.0 255.255.255.0
access-list HQFTPACL extended permit ip object net-local object net-remote 
pager lines 23
mtu outside 1500
mtu inside 1500
no failover
no monitor-interface service-module 
icmp unreachable rate-limit 1 burst-size 1
no asdm history enable
arp timeout 14400
no arp permit-nonconnected
nat (inside,outside) source static net-local net-local destination static net-remote net-remote
!
object network net-local
 nat (inside,outside) dynamic interface
object network net-outside
 nat (inside,outside) dynamic interface
route outside 0.0.0.0 0.0.0.0 10.1.1.1 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 sctp 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
aaa-server HQ-TACACS-GROUP protocol tacacs+
aaa-server HQ-TACACS-GROUP (inside) host 192.168.10.10
 key testing123
user-identity default-domain LOCAL
aaa authentication serial console HQ-TACACS-GROUP LOCAL
aaa authentication telnet console HQ-TACACS-GROUP LOCAL
aaa authentication ssh console HQ-TACACS-GROUP LOCAL
aaa authentication enable console HQ-TACACS-GROUP LOCAL
aaa authorization command HQ-TACACS-GROUP LOCAL
aaa accounting ssh console HQ-TACACS-GROUP
aaa accounting enable console HQ-TACACS-GROUP
aaa accounting command HQ-TACACS-GROUP
aaa accounting serial console HQ-TACACS-GROUP
aaa accounting telnet console HQ-TACACS-GROUP
no snmp-server location
no snmp-server contact
crypto ipsec ikev1 transform-set HQFTPTRANS esp-aes-256 esp-sha-hmac 
crypto ipsec security-association pmtu-aging infinite
crypto map HQFTPMAP 1 match address HQFTPACL
crypto map HQFTPMAP 1 set pfs group1
crypto map HQFTPMAP 1 set peer 192.168.20.2 
crypto map HQFTPMAP 1 set ikev1 transform-set HQFTPTRANS
crypto map HQFTPMAP interface outside
crypto ca trustpoint _SmartCallHome_ServerCA
 no validation-usage
 crl configure
crypto ca trustpool policy
 auto-import
crypto ikev1 enable outside
crypto ikev1 policy 10
 authentication pre-share
 encryption aes-256
 hash sha
 group 2
 lifetime 86400
telnet timeout 5
ssh stricthostkeycheck
ssh 192.168.10.21 255.255.255.255 outside
ssh 192.168.10.2 255.255.255.255 outside
ssh 192.168.20.2 255.255.255.255 outside
ssh 10.1.10.1 255.255.255.255 outside
ssh 10.1.10.3 255.255.255.255 outside
ssh 192.168.10.21 255.255.255.255 inside
ssh 192.168.10.2 255.255.255.255 inside
ssh 192.168.20.2 255.255.255.255 inside
ssh 10.1.10.1 255.255.255.255 inside
ssh 10.1.10.3 255.255.255.255 inside
ssh timeout 10
ssh version 2
ssh key-exchange group dh-group14-sha1
console timeout 0
management-access inside
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
dynamic-access-policy-record DfltAccessPolicy
username localadmin password zDkbp36jt66L0Z6u encrypted privilege 15
tunnel-group 192.168.20.2 type ipsec-l2l
tunnel-group 192.168.20.2 ipsec-attributes
 ikev1 pre-shared-key SECRET-KEY
!
class-map inspection_default
 match default-inspection-traffic
!
!
policy-map type inspect dns migrated_dns_map_1
 parameters
  message-length maximum client auto
  message-length maximum 512
policy-map global_policy
 class inspection_default
  inspect dns migrated_dns_map_1 
  inspect ftp 
  inspect h323 h225 
  inspect h323 ras 
  inspect ip-options 
  inspect netbios 
  inspect rsh 
  inspect rtsp 
  inspect skinny  
  inspect esmtp 
  inspect sqlnet 
  inspect sunrpc 
  inspect tftp 
  inspect sip  
  inspect xdmcp 
  inspect icmp 
!
service-policy global_policy global
prompt hostname context 
no call-home reporting anonymous
call-home
 profile CiscoTAC-1
  no active
  destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService
  destination address email [email protected]
  destination transport-method http
  subscribe-to-alert-group diagnostic
  subscribe-to-alert-group environment
  subscribe-to-alert-group inventory periodic monthly
  subscribe-to-alert-group configuration periodic monthly
  subscribe-to-alert-group telemetry periodic daily
 profile License
  destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService
  destination transport-method http
Cryptochecksum:60799b961f095cef738bd26bb9bedc75
: end

Packet tracer command below succeeds from HQ-FW1:

packet-tracer input inside tcp 192.168.10.21 1234 10.1.10.1 22
Improve this question
10
  • 1
    You have to allow the traffic into your HQ firewall before it can then be matched to go over the tunnel. You can use the packet-tracer command I showed you previously, on your HQ firewall, to test that the traffic is allowed in and then to see if it goes over the tunnel.
    – Jesse P.
    Dec 3, 2021 at 15:06
  • 1
    Thanks, I wouldn't have expected that to be the problem! See packet tracer output. So it looks like it gets through the ACL on the inside interface but is dropped at the VPN encryption point. Where would the ACL causing this be? (if it is an ACL causing it?)
    – DavidM
    Dec 3, 2021 at 15:34
  • 1
    Using packet-tracer when dealing with VPN traffic has a catch, and I forgot to mention it earlier. If the tunnel isn’t already established when you run packet-tracer, you’ll see what you saw above, that the tunnel drops it. It’s because the tunnel has to be built and packet-tracer finishes before that happens. So, you have to run the same packet tracer command twice rapidly - the first to initialize the tunnel and the second immediately afterward to see if the traffic really does work or not (assuming the tunnel successfully established).
    – Jesse P.
    Dec 3, 2021 at 15:42
  • 1
    No. You can’t simulate the return traffic. You would have to run the command from the other firewall, but that would not be return/implicit traffic, so it wouldn’t be a valid test. So, if the command is succeeding all the way through, it appears to either be something on the other side killing the traffic or the traffic never leaving the host for some reason. If you capture from the inside interface where the traffic ingresses the HQ firewall, do you see the request coming in from the workstation?
    – Jesse P.
    Dec 3, 2021 at 15:58
  • 1
    Any luck figuring out where it’s getting stopped at?
    – Jesse P.
    Dec 5, 2021 at 21:26

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Browse other questions tagged or ask your own question.