Lan-2-Lan VPN between Checkpoint (static IP) to ASA 5506 (PPPoE) - packets not encrypted in phase2

[maktala007]

Hi,

We have a scenario as below:

Site A (static IP) : Checkpoint (R77.20 )

Site B (ADSL pppoe DHCP) : Cisco ASA5506 9.8(2)

Site A  <<< Lan-2-Lan VPN >>> Site B

We are seeing tunnel is getting 'up' (both phase 1 & 2), but don't see any traffic in the tunnel:

Attached is the running config and 'sh cry..' output for your immediate reference.

Does anyone have idea if this setup really works. Or am I missing any configuration ?

Any suggestion would be really appreciated.

Thanks in advance

Rajender

[balaji.bandi]

High level there is no traffic initiated ? from allowed source ?

#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

can you post the configuration and ACL and interesting traffic allowed both the side?

[maktala007]

Thanks for the quick response. I have already attached the configuration and also initiated the traffic from end host as well as packet tracer from ASA. Let me know if you need more details.

[Rob Ingram]

Hi,
Can you run packet-tracer from local network to remote network and provide the output for review. Need to ensure traffic is hitting the NAT exemption rule.

HTH

[maktala007]

Though the Packet tracer output is there in the attachment, I am pasting it here again:

PPPOE-ASA# packet-tracer input inside_7 tcp 192.168.255.10 3389 3.193.0.2 5555

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside_7,outside) source static Jump_host Jump_host destination static SEN_VPN SEN_VPN no-proxy-arp
Additional Information:
NAT divert to egress interface outside
Untranslate 3.193.0.2/5555 to 3.193.0.2/5555

Phase: 2
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside_7,outside) source static Jump_host Jump_host destination static SEN_VPN SEN_VPN no-proxy-arp
Additional Information:
Static translate 192.168.255.10/3389 to 192.168.255.10/3389

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: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

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

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

Result:
input-interface: inside_7
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

[Rob Ingram]

Sorry I missed the attached first time around. Your ASA configuration looks ok as far as I can tell.

Is that output of the packet-tracer result run just once? To get an accurate result, packet-tracer needs to be run twice (the first packet-tracer test will bring up the tunnel and the second will actually simulate traffic sent over the tunnel).

[maktala007]

I have run packet tracer multiple times (also initiated traffic from end host multiple times) but still no luck.

Please see attached logs.

[Rob Ingram]

The remote ident selector is 3.192.0.0/255.255.0.0 therefore 3.193.0.0 would not match, that is despite you defining the correct mask of 255.224.0.0 in your ACL. Check the configuration on the Check Point end.

access-list outside_cryptomap extended permit ip host 192.168.255.10 3.192.0.0 255.224.0.0 
local ident (addr/mask/prot/port): (192.168.255.10/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (3.192.0.0/255.255.0.0/0/0)

Attempt to packet-tracer to any IP address within the 3.192.x.x network, just to confirm that works.

HTH

[maktala007]

Verified with remote network admin. He confirmed that

network 3.192.0.0/11 is allowed in the VPN acl to the destination 3.195.136.110 (which they NATed to 192.168.255.10).

They have a seperate NAT rule: whenever src:3.192.0.0/11  dst: 3.195.136.110 , src will be original and dst will be 192.168.255.10.

Tried with 3 different IPs from the same network. Please see attachment for more logs:

3.195.0.2
access-list outside_cryptomap extended permit ip host 192.168.255.10 3.192.0.0 255.224.0.0
local ident (addr/mask/prot/port): (192.168.255.10/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (3.195.0.2/255.255.255.255/0/0)

3.192.0.2
access-list outside_cryptomap extended permit ip host 192.168.255.10 3.192.0.0 255.224.0.0
local ident (addr/mask/prot/port): (192.168.255.10/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (3.192.0.0/255.255.0.0/0/0)

3.194.13.60
access-list outside_cryptomap extended permit ip host 192.168.255.10 3.192.0.0 255.224.0.0
local ident (addr/mask/prot/port): (192.168.255.10/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (3.194.13.60/255.255.255.255/0/0)

[maktala007]

20191218-UPDATE:

I have sent the information about 'remote ident..' to the network admin of other end and asked him to verify the config on Checkpoint one more time.

After some time, I have seen logs on my ASA (he might have initiated traffic from other end )as below (for full logs, please see attachment):

interface: outside
Crypto map tag: outside_map, seq num: 2, local addr: 7.139.95.7

access-list outside_cryptomap extended permit ip host 192.168.255.10 3.192.0.0 255.224.0.0
local ident (addr/mask/prot/port): (192.168.255.10/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (3.192.0.0/255.224.0.0/0/0)
current_peer: 95.2.36.40

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 21, #pkts decrypt: 21, #pkts verify: 21
#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.: 7.139.95.7/500, remote crypto endpt.: 95.2.36.40/500

Whereas, when I run the packet-tracer from my ASA, it still the same issue as earlier.

[maktala007 · Accepted solution]

This is problem is resolved. Apparently the issue was found on the local server (192.168.255.10) which is behind the 'inside' of ASA.

The issue was identified as follows. I have enabled the packet capture on 'inside' interface of ASA. And initiated traffic to remote host. VPN tunnel was triggered and I was seeing packets in ipsec phase 2. But I don't see any reply from remote host nor echo reply in the packet capture:

#pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
#pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4

9: 09:37:52.340817 192.168.255.10 > 3.194.223.246: icmp: echo request
10: 09:37:57.176794 192.168.255.10 > 3.194.223.246: icmp: echo request
11: 09:38:02.163489 192.168.255.10 > 3.194.223.246: icmp: echo request

Then, I captured the logs on local server and asked the remote admin to initiate the traffic from remote host.

VPN tunnel triggered, I am seeing the packets in phase 2 and in packet capture on ASA. But no packet were seen on the local server.

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

9: 10:44:23.842928 3.194.223.246 > 192.168.255.10: icmp: echo request
10: 10:44:25.393305 3.194.223.246 > 192.168.255.10: icmp: echo request

Then, me and remote admin agreed to add new host (192.168.255.111) to VPN ACL for testing and isolating the issue.

This works like a charm :-) 

1: 10:58:12.235812 3.194.223.246.3742 > 192.168.255.111.3389: S 3566128414:3566128414(0) win 16384 <mss 536,nop,wscale 0,nop,nop,timestamp 1465992661 0>
2: 10:58:12.236437 192.168.255.111.3389 > 3.194.223.246.3742: S 132589075:132589075(0) ack 3566128415 win 64000 <mss 1460,nop,wscale 0>
3: 10:58:12.267365 3.194.223.246.3742 > 192.168.255.111.3389: . ack 132589076 win 16616

Thank you all.

Rajender