Solved: Re: ASA 5516 VPN on two or mor interfaces

MarioRules · ‎05-16-2020

Hello

I'm stuck with vpn config on ASA and hope someone of you will be able to help me :)

Problem description:

I would like to establish 2 vpn connections, vpn1 via "outside" interface and vpn2 via other interface named "vpn2"

For now I can see that ASA is using only outside interface for VPN connection and do not even try to establish second tunnel.

Please check my config below

4 interfaces

- outside 1.1.1.1
- inside 192.168.0.1
- vpn2 172.18.1.10
- lab 10.0.0.1

vpn tunnel

vpn1 - from inside to 192.168.5.0/24 via outside peer 2.2.2.2

vpn2 - from inside to 192.168.10.0/24 via vpn2 peer 172.18.1.22

Results

vpn1 -

ping 192.168.5.5 from 10.0.0.10 (lab test host)
it is ok I can observe traffic on outside to 2.2.2.2 / ISAKMP

vpn2 -

ping 192.168.10.10 from 10.0.0.10 (lab test host)
no traffic on vpn2 interface
packet observed on outside interface as ICMP from 10.0.0.10 to 192.168.10.10

Question
What am I doing wrong ?
ASA config attached

ngkin2010 · ‎05-16-2020

hi,

route outside 0.0.0.0 0.0.0.0 1.1.1.2 1
route vpn2 172.18.0.0 255.255.0.0 172.18.1.1 1
route vpn2 192.168.10.0 255.255.255.0 172.18.1.22

Adding the red static route could make the traffic leaving on interface vpn2, and trigger the crypto-map to encrypt the packet.

Otherwise, the packet going to 192.168.10.0/24 will routed by the default route, then going out from outside interface. However, the none of crypto-map on outside is matched for the traffic 192.168.10.0/24. So, it will simply forwarded out without encryption.

View solution in original post

ngkin2010 · ‎05-16-2020

hi,

route outside 0.0.0.0 0.0.0.0 1.1.1.2 1
route vpn2 172.18.0.0 255.255.0.0 172.18.1.1 1
route vpn2 192.168.10.0 255.255.255.0 172.18.1.22

Adding the red static route could make the traffic leaving on interface vpn2, and trigger the crypto-map to encrypt the packet.

Otherwise, the packet going to 192.168.10.0/24 will routed by the default route, then going out from outside interface. However, the none of crypto-map on outside is matched for the traffic 192.168.10.0/24. So, it will simply forwarded out without encryption.

MarioRules · ‎05-16-2020

Hi

I added the route, after this change traffic do not leave ASA at all - checked on all interfaces

Even after added permission on FW any to any IP on all interface

ngkin2010 · ‎05-16-2020

Hi,

After you ping from 10.0.0.0/8 to 192.168.10.10, do you see the ike negotiation over the interface vpn2? (e.g. show crypto ikev1 sa) And the IPSec phase 2 negotiation? (e.g. show crypto ipsec sa)

Please also try a packet tracer on ASA and kindly post the result here. ( packet-tracer input lab match icmp 10.0.0.2 1 1 192.168.10.10 )

MarioRules · ‎05-16-2020

I an see that traffic is blocked by ACL which one ?

Do I need something more?

I'm thinking that i allowed everything

sh acces-list

access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096)
alert-interval 300
access-list outside_access_in; 1 elements; name hash: 0x6892a938
access-list outside_access_in line 1 extended permit ip any any (hitcnt=0) 0x7e78c5c4
access-list outside_cryptomap; 1 elements; name hash: 0x39bea18f
access-list outside_cryptomap line 1 extended permit ip 10.0.0.0 255.255.255.0 object vpn1_dest (hitcnt=0) 0xc466a4e1
access-list outside_cryptomap line 1 extended permit ip 10.0.0.0 255.255.255.0 192.168.5.0 255.255.255.0 (hitcnt=0) 0xc466a4e1
access-list vpn2_cryptomap; 1 elements; name hash: 0xf218891d
access-list vpn2_cryptomap line 1 extended permit ip 10.0.0.0 255.255.255.0 object vpn2_dest (hitcnt=22) 0xec0c280d
access-list vpn2_cryptomap line 1 extended permit ip 10.0.0.0 255.255.255.0 192.168.10.0 255.255.255.0 (hitcnt=22) 0xec0c280d
access-list vpn2_access_in; 1 elements; name hash: 0xdd179f64
access-list vpn2_access_in line 1 extended permit ip any any (hitcnt=0) 0xa019e803
access-list lab_access_in; 1 elements; name hash: 0x169da28f
access-list lab_access_in line 1 extended permit ip any any (hitcnt=8) 0x6ab7aa3a
access-list inside_access_in; 1 elements; name hash: 0x433a1af1
access-list inside_access_in line 1 extended permit ip any any (hitcnt=0) 0xa925365e

packet-tracker results

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 172.18.1.22 using egress ifc vpn2

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group lab_access_in in interface lab
access-list lab_access_in extended permit ip any any
Additional Information:

Phase: 3
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
class-map inspection_default
match default-inspection-traffic
policy-map global_policy
class inspection_default
inspect icmp
service-policy global_policy global
Additional Information:

Phase: 6
Type: QOS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:

Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:

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

vpn ikev1 show

ASA1111# May 16 19:37:39 [IKEv1 DEBUG]Pitcher: received a key acquire message, spi 0x0
May 16 19:37:39 [IKEv1]IP = 172.18.1.22, IKE Initiator: New Phase 1, Intf lab, IKE Peer 172.18.1.22 local Proxy Address 10.0.0.0, remote Proxy Address 192.168.10.0, Crypto map (vpn2_map)
May 16 19:37:39 [IKEv1 DEBUG]IP = 172.18.1.22, constructing ISAKMP SA payload
May 16 19:37:39 [IKEv1 DEBUG]IP = 172.18.1.22, constructing NAT-Traversal VID ver 02 payload
May 16 19:37:39 [IKEv1 DEBUG]IP = 172.18.1.22, constructing NAT-Traversal VID ver 03 payload
May 16 19:37:39 [IKEv1 DEBUG]IP = 172.18.1.22, constructing NAT-Traversal VID ver RFC payload
May 16 19:37:39 [IKEv1 DEBUG]IP = 172.18.1.22, constructing Fragmentation VID + extended capabilities payload
May 16 19:37:39 [IKEv1]IP = 172.18.1.22, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 324
May 16 19:37:47 [IKEv1]IP = 172.18.1.22, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 324
May 16 19:37:55 [IKEv1]IP = 172.18.1.22, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 324
May 16 19:38:03 [IKEv1]IP = 172.18.1.22, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 324
May 16 19:38:11 [IKEv1 DEBUG]IP = 172.18.1.22, IKE MM Initiator FSM error history (struct &0x00007f3ea1696160) <state>, <event>: MM_DONE, EV_ERROR-->MM_WAIT_MSG2, EV_RETRY-->MM_WAIT_MSG2, EV_TIMEOUT-->MM_WAIT_MSG2, NullEvent-->MM_SND_MSG1, EV_SND_MSG-->MM_SND_MSG1, EV_START_TMR-->MM_SND_MSG1, EV_RESEND_MSG-->MM_WAIT_MSG2, EV_RETRY
May 16 19:38:11 [IKEv1 DEBUG]IP = 172.18.1.22, IKE SA MM:1dd5451a terminating: flags 0x01000022, refcnt 0, tuncnt 0
May 16 19:38:11 [IKEv1 DEBUG]IP = 172.18.1.22, sending delete/delete with reason message

ngkin2010 · ‎05-16-2020

Hi,

May 16 19:37:39 [IKEv1]IP = 172.18.1.22, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 324
May 16 19:37:47 [IKEv1]IP = 172.18.1.22, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 324
May 16 19:37:55 [IKEv1]IP = 172.18.1.22, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 324
May 16 19:38:03 [IKEv1]IP = 172.18.1.22, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 324
May 16 19:38:11 [IKEv1 DEBUG]IP = 172.18.1.22, IKE MM Initiator FSM error history (struct &0x00007f3ea1696160) <state>, <event>: MM_DONE, EV_ERROR-->MM_WAIT_MSG2, EV_RETRY-->MM_WAIT_MSG2, EV_TIMEOUT-->MM_WAIT_MSG2, NullEvent-->MM_SND_MSG1, EV_SND_MSG-->MM_SND_MSG1, EV_START_TMR-->MM_SND_MSG1, EV_RESEND_MSG-->MM_WAIT_MSG2, EV_RETRY
May 16 19:38:11 [IKEv1 DEBUG]IP = 172.18.1.22, IKE SA MM:1dd5451a terminating: flags 0x01000022, refcnt 0, tuncnt 0
May 16 19:38:11 [IKEv1 DEBUG]IP = 172.18.1.22, sending delete/delete with reason message

After adding the route, IKE are now trying to negotiate with peer 172.18.1.22.

But there is no response from peer 172.18.1.22, please review the IPSec phase 1 proposals and have a check on peer firewall 172.18.1.22 to see why was it not responding.

Here I found a diagram to show you which state you stuck at.

IKE_Phase1_MSGs

https://www.tunnelsup.com/isakmp-ike-phase-1-status-messages/

MarioRules · ‎05-17-2020

HI

You missed one issue - no traffic is observed on link between ASA vpn2 interface and 172.18.1.22 interface on the other site of the tunnel. I can see that traffic hit crypto but not leave the ASA.

To establish connection is not the point here I just would like to observe when the ASA is trying / sending packets via vpn2.

It is enough for me.

Phase: 8
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:

Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:

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

ngkin2010 · ‎05-17-2020

Hi,

As long as you have established IPSec connection and the Interesting Traffic's ACL is match with other end, then packet-tracer's result will show "permitted" for outbound traffic. Thus, no need to focus on the "(acl-drop) Flow is denied by configured rule".

You should focus on the IPSec tunnel establishment before ASA could send encrypted traffic to the remote peer.

According to my previous reply, you should see ASA was trying to send IKE (UDP500) to remote peer for building the VPN tunnel. If you just want to confirm it's negotiating via vpn2 interface, then you could capture those traffic by :

capture VPN_TRAFFIC interface vpn2 match ip any host 172.18.1.22

<issue a ping from 10.0.0.0/8 to 192.168.10.0/24>

show capture VPN_TRAFFIC

You should see the UDP500 traffic sending to 172.18.1.22 via vpn2. If not, check your routing table, see whether 172.18.1.22 is routed via interface vpn2.