04-11-2012 08:19 AM - edited 03-11-2019 03:52 PM
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.
Solved! Go to Solution.
04-12-2012 08:10 AM
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
04-12-2012 01:45 AM
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
04-12-2012 01:57 AM
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,
04-12-2012 02:11 AM
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
04-12-2012 02:15 AM
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
04-12-2012 02:42 AM
OK, have changed as per your suggestion and traced ASDM... ping says it is creating then tearing down, it shows no problems throughout.
04-12-2012 02:48 AM
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
04-12-2012 02:54 AM
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.
04-12-2012 03:03 AM
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
04-12-2012 03:10 AM
Hmm.
I'm starting to think this could be our hardware at the other end, it's not Cisco.
04-12-2012 04:55 AM
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.
04-12-2012 05:07 AM
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
04-12-2012 07:31 AM
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
04-12-2012 08:10 AM
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
04-12-2012 08:34 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide