RAVPN - Accessing remote l2l's - what's wrong?

[dwhyte1985]

Hello,

Please find attached.

VPN (192.168.70.0/24) can connect to Internal LAN (192.168.10.0/23) but not the connected sites. These are working fine as can be pinged on the inside interface. When RAVPN tries it times out. Assuming remote end is correctly configured with same ACLS, what am I missing?

Very frustrating, a wealth of information online but alot of it is very hard to 'get'.

Simply I want remote the RAVPN clients to be able to get to remote sites, it works to the internal.

[Jouni Forss]

Hi,

I think you need the following command atleast

same-security-traffic permit intra-interface

It allows the traffic leave the same interface its arrived

From Cisco material:

same-security-traffic intra-interface
 command lets traffic enter and exit the same interface, which is  normally not allowed. This feature might be useful for VPN traffic that  enters an interface, but is then routed out the same interface. The VPN  traffic might be unencrypted in this case, or it might be reencrypted  for another VPN connection. For example, if you have a hub and spoke VPN  network, where the ASA is the hub, and remote VPN networks are spokes,  for one spoke to communicate with another spoke, traffic must go into  the ASA and then out again to the other spoke. 

Also on that note, why is your outside interface also at security-level 100?

You also seems to have some extra networks in the first NAT rule

nat (Outside,Outside) source static DM_INLINE_NETWORK_1 DM_INLINE_NETWORK_1 destination static NETWORK_OBJ_192.168.70.0_24 NETWORK_OBJ_192.168.70.0_24 no-proxy-arp route-lookup

The DM_INLINE_NETWORK_1 includes your local LAN network which isnt located outside. Not sure if it really matters if its there but just something that I noticed when looking at the configurations.

- Jouni

[dwhyte1985]

Hello,

Changed it back to 0, can't remember why it was changed.

I've added the command (although certain it was in that config already).

I've done as you've said with the nat command, still no joy.

Cheers,

[Jouni Forss]

Hey,

I think I actually looked the NAT wrong originally.

Think you have the source and destination networks the wrong way. Alteast when looking from the point of view of the VPN Client. I guess it should still be bi-directional but im not sure. Would seem logical to have the VPN Client pool as the source though.

Maybe you could try to change the places of the DM_INLINE_NETWORK_1 and NETWORK_OBJ_192.168.70.0_24 in the NAT statement for (Outside,Outside)

- Jouni

[Jouni Forss]

Also,

Monitoring the connections through ASDM at the  sametime would maybe give some clue whats happening to the connections  if they are not going through.

When the VPN Client tries to connect a remote L2L VPN network can you see any SA forming for the L2L VPN in question? Are any packets beeing encapsulated from the added VPN Client network 192.168.70.0 to the L2L VPN remote network of 192.168.60.0/24?

- Jouni

[dwhyte1985]

OK, have changed as per your suggestion and traced ASDM... ping says it is creating then tearing down, it shows no problems throughout.

[Jouni Forss]

Hi,

If you issue "show crypto ipsec sa peer 212.156.210.204" on the ASA can you copy/paste here the output where you see the statistics for the VPN-Pool network and the L2L VPN remote network.

- Jouni

[dwhyte1985]

show crypto ipsec sa peer 164.40.208.30
peer address: 164.40.208.30
    Crypto map tag: Outside_map, seq num: 1, local addr: 195.74.159.97

      access-list Outside_cryptomap extended permit ip 192.168.10.0 255.255.254.0 192.168.20.0 255.255.255.0
      local ident (addr/mask/prot/port): (192.168.10.0/255.255.254.0/0/0)
      remote ident (addr/mask/prot/port): (192.168.20.0/255.255.255.0/0/0)
      current_peer: 164.40.208.30

      #pkts encaps: 287091, #pkts encrypt: 287163, #pkts digest: 287163
      #pkts decaps: 388758, #pkts decrypt: 388758, #pkts verify: 388758
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 287091, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 72, #pre-frag failures: 0, #fragments created: 144
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 177
      #send errors: 0, #recv errors: 1345

      local crypto endpt.: 195.74.159.97/0, remote crypto endpt.: 164.40.208.30/0
      path mtu 1500, ipsec overhead 58, media mtu 1500
      current outbound spi: FB2135F6
      current inbound spi : 0A88192A

    inbound esp sas:
      spi: 0x0A88192A (176691498)
         transform: esp-des esp-md5-hmac no compression
         in use settings ={L2L, Tunnel, }
         slot: 0, conn_id: 195604480, crypto-map: Outside_map
         sa timing: remaining key lifetime (sec): 1420
         IV size: 8 bytes
         replay detection support: Y
         Anti replay bitmap:
          0xFFFFFFFF 0xFFFFFFFF
    outbound esp sas:
      spi: 0xFB2135F6 (4213257718)
         transform: esp-des esp-md5-hmac no compression
         in use settings ={L2L, Tunnel, }
         slot: 0, conn_id: 195604480, crypto-map: Outside_map
         sa timing: remaining key lifetime (sec): 1417
         IV size: 8 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001

I did it on another ip as i know this is fully configured, so i've been pinging 192.168.20.1.

[Jouni Forss]

Hey,

That output doesnt include traffic from your VPN pool of  192.168.70.x.

It seems to be the output of your LANs traffic to the L2L VPN remote network

With the command you entered above, you should also see a section where the vpn pool network of 192.168.70.x is mentioned.

If you cant see that even after trying to the connections, either your connection attempt still arent handled correctly on the ASA or the remote end hasnt added configurations regarding your 192.168.70.0 network in the L2L VPN configurations

- Jouni

[dwhyte1985]

Hmm.

I'm starting to think this could be our hardware at the other end, it's not Cisco.

[dwhyte1985]

Unless you can think of any simple tests or checks, it works fine l2l but when adding the new subnet .70.0 to the remote firewall/routers it doesn't seem to want to play ball.

[Jouni Forss]

Well,

Personally I would first check the configurations on both sides. In this case the encryption domains configured networks and the NAT translations for them. After that I would check through ASDM what happens to the connectiong through the logs. If that still wouldnt give me any results I would probably debug the actual L2L VPN connections and see if it gave any hint on the problem.

I'm not sure if the "packet-tracer" command would help in this situation.

- Jouni

[dwhyte1985]

Finally a bit more information!

Tunnel Manager has failed to establish an L2L SA.  All configured IKE versions failed to establish the tunnel. Map Tag= Outside_map.  Map Sequence Number = 1.
IKEv1 was unsuccessful at setting up a tunnel.  Map Tag = Outside_map.  Map Sequence Number = 1.
Group = 164.40.208.30, IP = 164.40.208.30, Removing peer from correlator table failed, no match!
Group = 164.40.208.30, IP = 164.40.208.30, QM FSM error (P2 struct &0xae49c120, mess id 0x42a8d8fc)!

So, I'm guessing... that this is because the encryption challenge on 192.168.70.0/24 RAVPN is different to 192.168.20.0/24 l2l (where the subnet has been placed). Would that make sense?

EDIT. Resetting up with same psk has stopped that error, still no comms though :S

[Jouni Forss · Accepted solution]

Just to double check one thing.

In the very first reply I mentioned you need to apply that one setting with the command

same-security-traffic permit intra-interface

Are you sure you added that command?

I mean you said you remembered already having that setting on. I'm just wondering if you missread the command I menioned in the my first post.

The setting you have on in the configuration attached is:

same-security-traffic permit inter-interface

Which basically allows traffic between 2 ASA interfaces that are of equal security-level. This setting in your case would make sense as you had both inside/outside at level 100.

Now the command that I posted was

same-security-traffic permit intra-interface

Which basically means that traffic can come in and go out on the same interface. In this case it would be the outside interface.

If you could just double check this Think the command in CLI format is "show run same-security-traffic"

- Jouni

[dwhyte1985]

Here is the output:

show run same-security-traffic

same-security-traffic permit inter-interface

same-security-traffic permit intra-interface

I did read it . Now I have no crypto issues on the ASA but still not showing 192.168.70.0/24 when i run:

show crypto ipsec sa peer 164.40.208.30