cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8165
Views
23
Helpful
47
Replies

VPN IKev2 with NAT Config Help

m.s.rees1
Level 1
Level 1

Hi, I am trying to establish a VPN connection with Ikev2 and just wanted to check if my config is looking correct. I don't have access to the other side of the VPN unfortunaly so just want to check this side is at least not missing anything important, there is also a NAT in place:

name 1.1.1.1 test

object-group network test
network-object host test

object network test_nat
host 192.168.2.1

Object network test_local
Subnet 0.0.0.0 0.0.0.0

Object network test_remote
Subnet 192.168.1.0 255.255.255.224

access-list acl_test extended permit tcp any host 192.168.1.10 eq ssh
access-list acl_test extended permit tcp any host 192.168.1.2 eq https

access-group acl_test interface outside control-plane

route outside 192.168.1.0 255.255.255.252 180.180.180.126

crypto ipsec ikev2 ipsec-proposal p1
protocol esp encryption aes-256
protocol esp integrity sha-256

crypto ikev2 policy 1
encryption aes-256
integrity sha
group 14
prf sha256
lifetime seconds 86400
Crypto ikev2 enable outside

crypto map outside_tunnels 141 match address acl_test
crypto map outside_tunnels 141 set peer test
crypto map outside_tunnels 141 set ikev2 ipsec-proposal p1
crypto map outside_tunnels 141 set pfs group14

tunnel-group 1.1.1.1 type ipsec-l2l
tunnel-group 1.1.1.1 ipsec-attributes
ikev2 remote-authentication pre-shared-key xxxxxxx
ikev2 local-authentication pre-shared-key xxxxxxx

nat (inside,outside) source static test_local test_nat destination static test_remote test_remote

47 Replies 47

this is the latest debug

@m.s.rees1 well some progress seems to have been made, but looks like the IKEv2 tunnel was killed - "IKEv2-PLAT-4: (115): session manager killed ikev2 tunnel. Reason: Internal Error."

Please provide your latest configuration for review.

Have you confirmed the IKEv2 and IPSec settings with your peer?

You could enable IPSec debugging for information on phase 2 - "debug crypto ipsec 127" and provide the output.

 

 

I haven't confirmed with peer, this could be the issue, I am unable to get through to them at the moment but hopefully will be able to confirm details with them soon. Here is the latest config:

@m.s.rees1 why have you changed the crypto ACL?  As mentioned in a previous response, cisco recommend you should use "ip" instead of "tcp" for the traffic selectors, not all vendors support using port-level encryption ACLs.

Change the following back to the previously agreed configuration.

access-list acl_test extended permit tcp host 192.168.2.1 host 192.168.1.1 eq https

Don't use the same ACL on an interface ACL and the crypto ACL, so remove the following from the crypto ACL

access-list acl_test extended permit udp host 1.1.1.1 eq isakmp host 180.180.180.1
access-list acl_test extended permit udp host 180.180.180.1 eq isakmp host 1.1.1.1
access-list acl_test extended permit udp host 1.1.1.1 eq 4500 host 180.180.180.1
access-list acl_test extended permit udp host 180.180.180.1 eq 4500 host 1.1.1.1

Also the interface ACL is not going to filter IKE/NAT-T, only a control-plane ACL will restrict that traffic destined to the ASA. So those 4 ACE above will not do anything.

I dont add this to last config I share' so as @Rob Ingram  mention there are some acl need to delete (no need since this vpn acl not control acl)

And still wait peer config to check matching 

Ah I must have changed it back, or removed the other entry along the way, sorry. Though I can't access the resources on the other side (guessing that's their side), it has brought the tunnel up :D:

Session-id:22, Status:UP-ACTIVE, IKE count:1, CHILD count:2

Tunnel-id Local Remote Status Role
1471761247 x.x.x.x/500 1.1.1.1/500 READY INITIATOR
Encr: AES-CBC, keysize: 256, Hash: SHA256, DH Grp:14, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/635 sec
Child sa: local selector x.x.x.x/0 - x.x.x.x/65535
remote selector x.x.x.x/0 - x.x.x.x/65535
ESP spi in/out: 0xde050e43/0x6a7aeaff
Child sa: local selector x.x.x.x/0 - x.x.x.x/65535
remote selector x.x.x.x/0 - x.x.x.x/65535
ESP spi in/out: 0x5087ec1c/0xdcca59e7


Global IKEv2 Statistics
Active Tunnels: 1

@m.s.rees1 good the tunnel is up, you can run "show crypto ipsec sa" to confirm whether encap|decap counters and which are not, that usually indicates where the problem lies.

You can also run packet-tracer from the CLI to simulate the traffic flow, this will confirm whether the packet is expected to work and what NAT, ACL rules are matched.

Just want to say, thankyou so much for you help, I really appreciate it!

Ye when I do that command, it seems to be looking good from I can see, nothing in the errors:

Crypto map tag: outside_tunnels, seq num: 141, local addr: x.x.x.x

access-list acl_test extended permit ip host x.x.x.x host x.x.x.x
local ident (addr/mask/prot/port): (x.x.x.x/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (x.x.x.x/255.255.255.255/0/0)
current_peer: test


#pkts encaps: 23, #pkts encrypt: 23, #pkts digest: 23
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 23, #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.x.x.x/500, remote crypto endpt.: mosaic/500
path mtu 1500, ipsec overhead 78(44), media mtu 1500
PMTU time remaining (sec): 0, DF policy: clear-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: DCCA59E7
current inbound spi : 5087EC1C

inbound esp sas:
spi: 0x5087EC1C (1351085084)
SA State: active
transform: esp-aes-256 esp-sha-256-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 14, IKEv2, }
slot: 0, conn_id: 1158, crypto-map: outside_tunnels
sa timing: remaining key lifetime (kB/sec): (4055040/27128)
IV size: 16 bytes
replay detection support: N
outbound esp sas:
spi: 0xDCCA59E7 (3704248807)
SA State: active
transform: esp-aes-256 esp-sha-256-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 14, IKEv2, }
slot: 0, conn_id: 1158, crypto-map: outside_tunnels
sa timing: remaining key lifetime (kB/sec): (4193278/27121)
IV size: 16 bytes
replay detection support: N

@m.s.rees1 there are encaps so you are sending and encrypting the traffic, but there are no decaps which means the peer is not sending back any traffic.

#pkts encaps: 23, #pkts encrypt: 23, #pkts digest: 23
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

You should troubleshoot this with the 3rd party, ask them to confirm if traffic is permitted in their ACL and whether they are decrypting and encrypted traffic, possibly a NAT or routing issue on their end.

I finally managed to speak to the 3rd party. They were not able to initiaite the tunnel from their side, though as you know I can my side. He sent across some of his config and it contained no ACLs, which I queried and he has said that he shouldn't need any at this stage... is that correct? - he was trying a connection to my NAT address.

object network test_nat
host 10.10.190.34 255.255.255.255

Object network test_local
Subnet 0.0.0.0 0.0.0.0

Object network test_remote
Subnet 10.10.190.0 255.255.255.224

nat (inside,outside) source static test_local test_nat destination static test_remote test_remote

I have attached the debug from my side (when he initiated the connection). There might be some descrepencies of IPs from above, as I have done a find and replace for security reasons.

@m.s.rees1 the only scenario where you would not need a crypto ACL that defines the interesting traffic is if the VPN is a route based VPN, which uses tunnel interfaces and routes. You are using an ACL to define the interesting traffic, which is a policy based VPN.

If the peer is also running a policy based VPN then they do need an ACL (or equivalent depending on the manfacturer) to define the traffic to be encrypted over the VPN.

Ask the peer if they are using a policy based VPN or a routed based VPN. If they are running a policy based VPN, then they need to configure the interesting traffic (hosts/networks) to mirror your configuration.

It turns out they did have the ACL in place

They are unable to bring up the tunnel (though I can from my side). I can't access the web address though, it will just hang. So still not right. I have asked them for a debug, when attempting to bring up the tunnel and they get this:

IKEv2-PROTO-2: (6601): Maximum number of retransmissions reached
IKEv2-PROTO-7: (6601): SM Trace-> SA: I_SPI=F0F4C9C95C5BF906 R_SPI=0000000000000000 (I) MsgID = 00000000 CurState: INIT_DONE Event: EV_FAIL
IKEv2-PROTO-4: (6601): Failed SA init exchange
IKEv2-PROTO-2: (6601): Initial exchange failed
IKEv2-PROTO-2: (6601): Initial exchange failed
IKEv2-PROTO-7: (6601): SM Trace-> SA: I_SPI=F0F4C9C95C5BF906 R_SPI=0000000000000000 (I) MsgID = 00000000 CurState: EXIT Event: EV_ABORT
IKEv2-PROTO-7: (6601): SM Trace-> SA: I_SPI=F0F4C9C95C5BF906 R_SPI=0000000000000000 (I) MsgID = 00000000 CurState: EXIT Event: EV_CHK_PENDING_ABORT
IKEv2-PROTO-7: (6601): SM Trace-> SA: I_SPI=F0F4C9C95C5BF906 R_SPI=0000000000000000 (I) MsgID = 00000000 CurState: EXIT Event: EV_UPDATE_CAC_STATS
IKEv2-PROTO-4: (6601): Abort exchange
IKEv2-PROTO-4: (6601): Deleting SA

Reload the asa  this conut below is wrong and I think you need reload asa 

#pkts not compressed: 

Just wanted to say thankyou to you also for helping out with this. Appreciate it.

I won't be able to reload the ASA anytime soon, so might liaise with the 3rd party first and see if we get anyway. I have a meeting with them next week, so hopefully we can figure it.

You are welcome 

Have nice weekend 

Enjoy 

MHM