encryption gateway vs domain and source ip issues

        (This is the same setup as <a href="https://networkengineering.stackexchange.com/questions/48042/">a previous question</a>.)
My VPN connection was no longer working (for ~4h), so I called the remote end's tech support. While we were talking, the link mysteriously started working again, so with no configuration changes it came back. The hardest problem to troubleshoot, since the logs do not clearly indicate anything. However, they repeatedly said that the source IP for traffic is incorrect per their configuration and expectations. (The link has been working fine for several months, and allegedly neither side has made any changes.) Here is the basic topology:
     -----------
  --/           \--          +--------------+
 /                 \     /---+              |
(   11.11.11.0/16   )----    | 11.11.11.1   |
 \                 /         +------==------+
  --\           /--              === 
     -----------              ===             MY OFFICE
     CLIENT        Internet ==              -----------
                         ===             --/           \--
                      ===               /                 \
             +------==-------+      /--(    10.1.1.0/24    )
             |               |  /---    \                 /
             | 22.22.22.1/30 +--  NAT    --\           /--
             +---------------+              -----------
My configuration (which has worked for several months):
Remote device        : Cisco something
Remote IP            : 11.11.11.1
My device            : Checkpoint
My encryption gateway: 22.22.22.1/30
My encryption domain : 22.22.22.0/30
They sent two reports/logs. The first is during the Phase 2 SA negotiation:
Crypto map tag: CSM_outside_map, seq num: 121, local addr: 11.11.11.1
      access-list CSM_IPSEC_ACL_113 extended permit ip 11.11.11.0 255.255.255.0 22.22.22.0 255.255.255.252
      local ident (addr/mask/prot/port): (11.11.11.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (22.22.22.0/255.255.255.252/0/0)
      current_peer: 22.22.22.1
      #pkts encaps: 2, #pkts encrypt: 2, #pkts digest: 2
      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

Crypto map tag: CSM_outside_map, seq num: 121, local addr: 11.11.11.1
      access-list CSM_IPSEC_ACL_113 extended permit ip 11.11.11.0 255.255.255.0 22.22.22.0 255.255.255.252
      local ident (addr/mask/prot/port): (11.11.11.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (22.22.22.1/255.255.255.255/0/0)
      current_peer: 22.22.22.1
      #pkts encaps: 1, #pkts encrypt: 1, #pkts digest: 1
      #pkts decaps: 199, #pkts decrypt: 199, #pkts verify: 199

Crypto map tag: CSM_outside_map, seq num: 121, local addr: 11.11.11.1
      access-list CSM_IPSEC_ACL_113 extended permit ip 11.11.11.0 255.255.0.0 22.22.22.0 255.255.255.252
      local ident (addr/mask/prot/port): (11.11.11.1/255.255.255.255/0/0)
      remote ident (addr/mask/prot/port): (22.22.22.1/255.255.255.255/0/0)
      current_peer: 22.22.22.1
      #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
      #pkts decaps: 44, #pkts decrypt: 44, #pkts verify: 44
and they said that the "remote ident" in the 2nd and 3rd entry were wrong because they did not "match" the encryption gateway or domain. The second is some log entries that "show" where things are allegedly misconfigured.
Jul 13 04:44:44 someremotehost :  %ASA-...: Teardown TCP connection 123456789 for outside:22.22.22.1/26548 to inside:11.11.11.55/22 duration 0:02:22 bytes 132435465 TCP FINs
Jul 13 05:55:55 someremotehost :  %ASA-...: Teardown TCP connection 123456793 for outside:22.22.22.1/12282 to inside:11.11.11.55/22 duration 0:00:11 bytes 71625343 TCP FINs
Jul 13 14:14:14 someremotehost :  %ASA-...: Teardown TCP connection 123456796 for outside:22.22.22.1/23050 to inside:11.11.11.55/22 duration 0:00:04 bytes 91827 TCP FINs
Jul 13 14:14:48 someremotehost :  %ASA-...: Teardown TCP connection 123456798 for outside:22.22.22.1/22742 to inside:11.11.11.55/22 duration 0:00:02 bytes 84385 TCP FINs
and they cited the problem as being "the source IP is 22.22.22.1/32 and not 22.22.22.0/30". I thought that a "source IP" would always be "/32", since it is a single point. The Phase-2 negotiation appears to show both subnet origin (1st) and single-IP origin (2nd and 3rd).
  1. My device does not give me an ability to set a reporting encr domain. I believe the sensible thing is that it reports what it knows to be the truth. Why do I see both subnet and single-IP origins in the Crypt map tag entries? Is this showing a problem (as far as you can tell)?

  2. I thought that my encryption domain is used just to update the remote routing table. Why, then, is it a concern that the source IP for traversing packets matches just the gateway? Isn't it "fine" that the e.gateway is within the e.domain?

Bottom line for now: it's working, and I want them to change nothing. But I don't understand the lexicon used since it seems to contradict what I "know" about networking and VPNs.

Leave Your Comment

Leave a Reply