force the IPSec tunnel to stay in place even if no traffic

Hello

We had exactly the same problem, as already described here;

https://supportforums.Cisco.com/discussion/11666661/can-we-automatically...

We actually run ASA 9.1 and the remote peer is a Fortigate. There is a new feature that has been introduced since the post on the forum above or fact creating an sla is the only way to follow IPsec tunnel.

Concerning

Nothing new was built in the SAA to take account of this requirement.

I also had good results a script running on an internal host to send a "tcp" ping to a remote host, thus making sure traffic interesting was often enough to maintain the tunnel.

Tags: Cisco Security

Similar Questions

Create the Ipsec tunnel using digital certificates

Hello

I try to open the IPSEC tunnel between 2 3800 of Cisco routers using additional 3800 router as a CA server.

Before that I added the CA server all go smoothly.

Attached is my configuration, attached debug commands from the configuration of server and router CA

It seems that the routers does not receive the certificate of the CA (R3) router because I see the certificate is awaiting status:

#
R3 #.
R3 #show cryptographic pki certificate cisco talkative
CA
Status: available
Version: 3
Certificate serial number (hex): 01
Use of certificates: Signature
Issuer:
CN = cisco1. Cisco.com L\ = RTP it\ = US
Object:
CN = cisco1. Cisco.com L\ = RTP it\ = US
Validity date:
start date: 10:12:13 UTC Sep 8 2013
end date: 10:12:13 UTC Sep 7 2016
Subject key information:
Public key algorithm: rsaEncryption
RSA Public Key: (512 bits)
Signature algorithm: MD5 with RSA encryption
Fingerprint MD5: FAB9FFF7 87B580F3 7A65627E 56A378C9
Fingerprint SHA1: F26CD817 91F8129D A9E46671 07E26F1E 55422DCD
X509v3 extensions:
X509v3 Key use: 86000000
Digital signature
Key Cert sign
Signature of the CRL
X509v3 subject Key ID: 56F091F7 7016A63F B 89, 46900 B13E6719 8B0D548E
X509v3 Basic Constraints:
CA: TRUE
X509v3 Authority Key ID: 56F091F7 7016A63F B 89, 46900 B13E6719 8B0D548E
Access to information the authority:
Related Trustpoints: cisco
Storage: nvram:cisco1ciscoc #4CA.cer

R3 #.

Appreciate your support and I will send additional if necessary evidence

TX

Roee

I didn't look at your configuration, but accroding to your description, it seems that you have not approved the certificate requests pending on your router CA. Here are the commands that you need:

To view the pending requests:

information cryptographic pki server router 'CA '.

To grant requests pending:

Info Server 'CA' router cryptographic pki grant all

Can I use private as Source IPs from a remote network IP addresses while building the IPSec tunnel?

Can I use private as Source IPs from a remote network IP addresses while building the IPSec tunnel? If not why? If so, how?

Your explanation is much appreciated.

Hi Deepak,

In such a situation, you usually NAT traffic that goes to the internet, but exempt traffic that goes through the VPN, because it will be wrapped in packages with public IP (tunnel) addresses. You can use the same IP address on your interface in the face of internet for the NAT/PAT and source of IPSEC Tunnel.

I can weight of the IPSec Tunnels between ASAs

Hello

Remote site: link internet NYC 150 MB/s

Local site: link internet Baltimore 400 MB/s

Backup site: link internet Washington 200 Mb/s

My main site and my backup site are connected via a gigabit Ethernet circuit between the respective base site switches. Each site has its own internet connection and my OSPF allows to switch their traffic to the backup site if the main website is down. We are opening an office in New York with one ASA unique connected to 150 Mbps FIOS internet circuit. We want to set up an IPSec tunnel on the main site and the backup on the remote site, but want the remote site to prefer the tunnel in Baltimore, except if it is down.

Interesting traffic would be the same for the two tunnels

I know that ASA cannot be a GRE endpoint. How can I force the New York traffic through the tunnel in Baltimore as long as it works? An IPSec tunnel can be weighted?

Thank you

It is not in itself weighting, but you can create up to 10 backup over LAN to LAN VPN IPsec peers.

For each tunnel, the security apparatus tried to negotiate with the first peer in the list. If this peer does not respond, the security apparatus made his way to the bottom of the list until a peer responds, or there is no peer more in the list.

Reference.

DROP in flow of the IPSec tunnel

Hello

I am trying to use a VPN, who worked on one connection ASA months on ASA9.1 (2). I've updated to ASA9.1 11 (6) and it has stopped working.

This is the remote ASA5505s making an IPSEC connection-a network head 5520. I can ride preceding and following 2 and 11 9.1 9.1 (6) and while the configuration does not change, the VPN starts working on 9.1 2

Vpn connects, but there is no packets sent or received...

I get this packet tracer...

Output of the command: "packet - trace entry tcp teeessyou 192.168.190.2 5000 192.168.195.1 detail 80.

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit rule
Additional information:
Direct flow from returns search rule:
ID = 0xae1308e8, priority = 1, domain = allowed, deny = false
hits = 622, user_data = 0 x 0, cs_id = 0 x 0, l3_type = 0 x 8
Mac SRC = 0000.0000.0000, mask is 0000.0000.0000
DST = 0000.0000.0000 Mac, mask is 0100.0000.0000
input_ifc = teeessyou, output_ifc = any

Phase: 2
Type: UN - NAT
Subtype: static
Result: ALLOW
Config:
NAT (teeessyou, outside) static source all all static destination teeessyou_ENCODERS teeessyou_ENCODERS
Additional information:
NAT divert on exit to the outside interface
Untranslate 192.168.195.1/80 to 192.168.195.1/80

Phase: 3
Type: ACCESS-LIST
Subtype: Journal
Result: ALLOW
Config:
Access-group teeessyou_access_in in the teeessyou interface
teeessyou_access_in of access allowed any ip an extended list
Additional information:
Direct flow from returns search rule:
ID = 0xae24d310, priority = 13, area = allowed, deny = false
hits = 622, user_data is 0xab6b23c0, cs_id = 0 x 0, use_real_addr, flags = 0 x 0 = 0 protocol
IP/ID=0.0.0.0 SRC, mask = 0.0.0.0, port = 0, = 0 tag
IP/ID=0.0.0.0 DST, mask is 0.0.0.0, port = 0, tag = 0, dscp = 0 x 0
input_ifc = teeessyou, output_ifc = any

Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
NAT (teeessyou, outside) static source all all static destination teeessyou_ENCODERS teeessyou_ENCODERS
Additional information:
Definition of static 192.168.190.2/5000 to 192.168.190.2/5000
Direct flow from returns search rule:
ID = 0xae1ea5a8, priority = 6, area = nat, deny = false
hits = 622, user_data is 0xae1e9c58, cs_id = 0 x 0, flags = 0 x 0 = 0 protocol
IP/ID=0.0.0.0 SRC, mask = 0.0.0.0, port = 0, = 0 tag
IP/ID=192.168.192.0 DST, mask is 255.255.224.0, port = 0, tag = 0, dscp = 0 x 0
input_ifc = teeessyou, output_ifc = external

Phase: 5
Type: NAT
Subtype: volatile
Result: ALLOW
Config:
Additional information:
Direct flow from returns search rule:
ID = 0xa9678858, priority = 1, domain = nat-volatile, deny = true
hits = 105, user_data = 0 x 0, cs_id = 0 x 0, reverse, use_real_addr, flags = 0 x 0, Protocol = 6
IP/ID=0.0.0.0 SRC, mask = 0.0.0.0, port = 0, = 0 tag
IP/ID=0.0.0.0 DST, mask is 0.0.0.0, port = 0, tag = 0, dscp = 0 x 0
input_ifc = none, output_ifc = any

Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional information:
Direct flow from returns search rule:
ID = 0xae136910, priority = 0, sector = inspect-ip-options, deny = true
hits = 622, user_data = 0 x 0, cs_id = 0 x 0, reverse, flags = 0 x 0 = 0 protocol
IP/ID=0.0.0.0 SRC, mask = 0.0.0.0, port = 0, = 0 tag
IP/ID=0.0.0.0 DST, mask is 0.0.0.0, port = 0, tag = 0, dscp = 0 x 0
input_ifc = teeessyou, output_ifc = any

Phase: 7
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional information:
Direct flow from returns search rule:
ID = 0xaeec4328, priority = 70, domain = encrypt, deny = false
hits = 65, user_data is 0xb7dc, cs_id = 0 x 0, reverse, flags = 0 x 0 = 0 protocol
IP/ID=0.0.0.0 SRC, mask = 0.0.0.0, port = 0, = 0 tag
IP/ID=192.168.195.0 DST, mask is 255.255.255.0, port = 0, tag = 0, dscp = 0 x 0
input_ifc = none, output_ifc = external

Phase: 8
Type: NAT
Subtype: rpf check
Result: ALLOW
Config:
NAT (teeessyou, outside) static source all all static destination teeessyou_ENCODERS teeessyou_ENCODERS
Additional information:
Direct flow from returns search rule:
ID = 0xae1eae48, priority = 6, area = nat-reversed, deny = false
hits = 129, user_data is 0xae1e9d10, cs_id = 0 x 0, use_real_addr, flags = 0 x 0 = 0 protocol
IP/ID=0.0.0.0 SRC, mask = 0.0.0.0, port = 0, = 0 tag
IP/ID=192.168.192.0 DST, mask is 255.255.224.0, port = 0, tag = 0, dscp = 0 x 0
input_ifc = teeessyou, output_ifc = external

Phase: 9
Type: VPN
Subtype: ipsec-tunnel-flow
Result: DECLINE
Config:
Additional information:
Reverse flow from returns search rule:
ID = 0xaea9f6b0, priority = 69 = ipsec-tunnel-flow area, deny = false
hits = 129, user_data = 0 x 0, cs_id = 0xaea999c0, reverse, flags = 0 x 0 = 0 protocol
IP/ID=192.168.192.0 SRC, mask = 255.255.224.0, port = 0, = 0 tag
IP/ID=192.168.190.0 DST, mask is 255.255.255.0, port = 0, tag = 0, dscp = 0 x 0
input_ifc = out, output_ifc = any

Hello Spencerallsop,

I recommend to add the keyword "no-proxy-arp" the end of the NAT statement, so the ASA try to answer queries ARP for the traffic(VPN interesting traffic), also this last phase 9 usually shows ignored due to a filter VPN defined in sometimes group policy, make sure you have not a filter VPN in a group policy that affect this tunnel then you will need to do the following:

1. remove the NAT statement:

-no nat (teeessyou, outside) static source all all static destination teeessyou_ENCODERS teeessyou_ENCODERS

2 fix the NAT statement with the keyword "No.-proxy-arp" :

-nat (teeessyou, outside) static source any any destination static teeessyou_ENCODERS teeessyou_ENCODERS non-proxy-arp

3 disable the VPN ISA SA:

-claire crypto ikev1 his

4. run the packet tracer to check that the L2L has developed,

To be honest I wouldn't recommend move you to 9.1.7 since it has some problems with the ARP entries, and it affects AnyConnect SSL somehow, which is still under investigation.

In fact, this bug affects 9.1.7 (may affect your environment):

- https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuy28710

Please don't forget to rate and score as of this post, keep me posted!

Kind regards

David Castro,

Help: Adding to the IPsec Tunnel encryption field Questions

Good evening everyone,

I'm looking for help and/or advise in what concerns adding more networking in the field of encryption of an existing IPsec site-to-site tunnel. Both sides of the tunnel are of ASA. The client on the remote end is eager to access the networks more on my end. They have already updated their ACL crypto map to include the new networks. When they perform "show crypto IPsec his counterpart x.x.x.x" it shows already encap packets attempting to join my network.

On my side, I updated my ACL crypto map to reference the new 2 networks, created the double NAT and added the ACL needed to allow the inbound access through ports they want. When I perform a 'see the crypto IPsec his counterpart x.x.x.x' output is NOT up-to-date with the new networks added to the field of encryption. When I run a tracer of package of supply of one of the servers in the new network, the traffic is translated as he should, but a fall when it hits the outgoing interface for the VPN tunnel.

Am I missing something here? Can I bounce the tunnel so that the new networks must be recognized in the surveillance society?

Thanks in advance.

Hello

You must bounce the tunnel when you change the interesting traffic, otherwise the new SA will not be created, is a little funny that you say that SA is already build on the remote side, SA cannot be established only on one side, is like building a new tunnel, if you don't have it on one side, it can not simply prevail and create the entry of SA. In addition, adding new networks and bounce the tunnel you need to generate traffic to trigger the ITS new or you will never see that it created. Check your no nats and routing and it should work.

Best regards, please rate.

Outgoing PAT to the IPSec Tunnel

Hello

Situation is with range of IP private tunnel of 3rd party who already uses the same private beach, but not with any of the hosts that we need to connect to. All traffic from the office to the 3rd party must be secure.

We want to configure an IPSec tunnel between the two sites (easy) and then use PAT on the PIX Office (6.3 (5)) to make all traffic office appear to be a single private address different.

We tried to do with PDM, but it insists on having no NAT (with an exclusionary rule), or static NAT, but does not seem to allow Pat.

I have attached a copy sanitized the office configuration. Any standard room in PIX have been removed for brevity

I would like constructive guidance on where I'm wrong.

See you soon

Hello

The PIX / ASA will make the NAT translation on the steps below. First, it will check if no no (order No. - nat) nat is configured, then it will check the static nat translation and finally, it will check the translation PAT.

In your configuration, there is a NAT (0) command indicating not to translate any IP of 192.168.0.0 to the remote ip address range, then the PIX won't do the translation and the package is passed to the destination.

Remove the NAT (0) command and edit list access outside_cryptomap_10 with the ip dried up to the remote ip address for this access list is responsible for interesting traffic that needs to be encrypted.

pls control and dream of return.

How to determine the cause of the ipsec tunnel fall on ASA 5510

Is there an easy way to determine the cause of tunnel VPN ipsec l2l fall on one asa 5510? I have enabled logging, but the buffer is full so fast, I can't find something when it is 24 hours later. I'm working on obtaining a server/aggregator syslog configuration but... until it is complete I need a temporary measure. Suggestions?

Hi Jessica.

For the buffering limit, you can try:

Increase the maximum buffer size.

limit the newspapers to the class of vpn:

Buffered Debug class vpn connection.

On the other hand, you can try him debugs:

Debug crypto peer peer_address condition

debugging cry isa 128

debugging ipsec 128 cry

If you lose the ssh session debugging is disabled. Finally for the vpn tunnels usually it goes down due to:

Idle time-out

the dead peer detection

remove it from the other end.

HTH.

NAT in the IPSec tunnel between 2 routers x IOS (877)

Hi all

We have a customer with 2 x 877 routers connected to the internet. These routers are configured with an IPSec tunnel (which works fine). The question is the inbound static NAT translation problems with the tunnel - port 25 is mapped to the address inside the mail server. The existing configuration works very well for incoming mail, but prevents users from access to the direct mail server (using the private IP address) on port 25.

Here is the Config NAT:

nat INET_POOL netmask 255.255.255.252 IP pool

IP nat inside source map route INET_NAT pool INET_POOL overload

IP nat inside source static tcp 10.10.0.8 25 25 expandable

IP nat inside source static tcp 10.10.0.8 80 80 extensible

IP nat inside source static tcp 10.10.0.8 443 443 extensible

IP nat inside source static tcp 10.10.0.7 1433 1433 extensible

IP nat inside source static tcp 10.10.0.7 extensible 3389 3389

allowed INET_NAT 1 route map

corresponds to the IP 101

access-list 101 deny ip 10.10.0.0 0.0.0.255 192.168.1.0 0.0.0.255

access-list 101 permit ip 10.10.0.0 0.0.0.255 any

On the SAA, I would setup a NAT exemption, but how do I get the same thing in the IOS?

See you soon,.

Luke

Take a look at this link:

http://www.Cisco.com/en/us/docs/iOS/12_2t/12_2t4/feature/guide/ftnatrt.html

Concerning

Farrukh

packet loss on the ipsec tunnel

I currently have 2 routers (one at each site). The two are running 12.3 (9th). A router is a 2621 and the other is a 2611XM.

This is the relevant config:

Router

crypto ISAKMP policy 10

BA 3des

preshared authentication

isakmp encryption key * address x.x.x.98 No.-xauth

!

!

Crypto ipsec transform-set farm-jc-ts esp-3des esp-md5-hmac

!

farm-jc 10 ipsec-isakmp crypto map

the value of x.x.x.98 peer

the value of the transform-set farm-jc-ts

address acl_farm-jc-tunnel to match

!

!

interface FastEthernet0/0

DHCP IP address

NAT outside IP

automatic duplex

automatic speed

card crypto farm-jc

!

interface FastEthernet0/1

192.168.4.1 IP address 255.255.255.0

IP nat inside

automatic duplex

automatic speed

!

IP nat Stateful IDs 11

overload of IP nat inside source list acl_nat interface FastEthernet0/0

IP classless

IP route 0.0.0.0 0.0.0.0 FastEthernet0/0

Route IP 10.1.1.0 255.255.255.0 FastEthernet0/0

tunnel-jc-acl_farm extended IP access list

allow icmp 192.168.4.0 0.0.0.255 10.1.0.0 0.0.255.255

permit tcp 192.168.4.0 0.0.0.255 10.1.1.0 0.0.0.255 eq www

permit tcp 192.168.4.0 0.0.0.255 10.1.1.0 0.0.0.255 eq 443

permit tcp 192.168.4.0 0.0.0.255 10.1.1.0 0.0.0.255 eq 22

acl_nat extended IP access list

refuse the 192.168.4.0 ip 0.0.0.255 10.1.1.0 0.0.0.255

ip licensing 192.168.4.0 0.0.0.255 any

Router b:

crypto ISAKMP policy 10

BA 3des

preshared authentication

isakmp encryption key * address x.x.x.199 No.-xauth

!

!

Crypto ipsec transform-set BC-farm-ts esp-3des esp-md5-hmac

!

JC-farm-10 ipsec-isakmp crypto map

the value of x.x.x.199 peer

the value of the transform-set BC-farm-ts

address acl_jc-farm-tunnel to match

!

!

!

!

interface FastEthernet0/0

10.1.1.5 IP address 255.255.255.0

IP nat inside

automatic duplex

automatic speed

!

interface FastEthernet0/1

IP address x.x.x.98 255.255.255.224

NAT outside IP

automatic speed

full-duplex

card crypto jc-farm

!

overload of IP nat inside source list acl_nat interface FastEthernet0/1

IP classless

IP route 0.0.0.0 0.0.0.0

IP route 10.1.0.0 255.255.0.0 FastEthernet0/0

IP route 192.168.4.0 255.255.255.0 FastEthernet0/1

!

tunnel-farm-acl_jc extended IP access list

allow icmp 10.1.0.0 0.0.255.255 192.168.4.0 0.0.0.255

permit tcp 10.1.1.0 0.0.0.255 192.168.4.0 0.0.0.255 eq www

permit tcp 10.1.1.0 0.0.0.255 192.168.4.0 0.0.0.255 eq 443

permit tcp 10.1.1.0 0.0.0.255 192.168.4.0 0.0.0.255 eq 22

acl_nat extended IP access list

refuse the 10.1.1.0 ip 0.0.0.255 192.168.4.0 0.0.0.255

ip licensing 10.1.1.0 0.0.0.255 any

IP 10.1.2.0 allow 0.0.0.255 any

10.1.3.0 IP allow 0.0.0.255 any

IP 10.1.4.0 allow 0.0.0.255 any

IP 10.1.5.0 allow 0.0.0.255 any

I can ping in front of each private LAN to others, but its about 50% packet losses.

out of HS cry is that his watch QM_IDLE on both sides.

Hello

Try the following commands on the interfaces:

no ip route cache

no ip mroute-cache

no ip-cache cef route

no ip route-cache flow

And global:

no ip cef

Please rate if this helped.

Kind regards

Daniel

Interpret what is allowed on the VPN tunnel

Hello

I work with Cisco PIX equipment for the first time and I'm trying to understand what is allowed on one of the VPN tunnels which are established on the PIX.

I interpret this PIX did by reading the running configuration. I was able to understand most of it (with the help of the cisco site), so I'm starting to get comfortable with it. I'm looking for more help in the interpretation of what is allowed by a good VPN tunnel. Here are some details:

map Cyril 2 ipsec-isakmp crypto

Cyril 2 crypto card matches the acl-vpntalk address

access list acl-vpntalk allowed ip object-group my_inside_network 172.17.144.0 255.255.255.0

So, if I interpret it correctly, then the traffic matching ACL acl-vpntalk will go on the VPN tunnel.

As far as the lists others access dedicated, my inner interface I have:

Access-group acl-Interior interface inside

With ACL-Interior:

access list acl-Interior ip allow a whole

So nothing complicated there.

Now, just because of all this I conclude I encouraged all remote network traffic in my site. If all traffic 172.17.144.0/24 is allowed to join my network.

However, I don't know if this conclusion is correct.

This ACL is also applied:

Access-group acl-outside in external interface

And it looks like:

deny access list acl-outside ip a

I'm not sure if this ACL applies to vehicles coming from the IPSEC peer. It's for sure inbound on the external interface, but if it is valid for the IPSEC traffic I don't know.

If it is valid, then am I had reason to conclude that only connections initiated from my inside network to the remote control can come back?

Thanks in advance for your ideas.

With sincere friendships.

Kevin

Hey Kevin,

Here are my comments, hope you find them useful:

1. the ACL called "acl-vpntalk" sets traffic who will visit the IPSec tunnel, so you got that right. All traffic from the group called "my_inside_network" will 172.17.144.0/24 will pass through the tunnel, and there should be a similar to the other VPN end opposite ACL.

2. the 'acl-inside' applied to the inside interface allows any ip traffic coming out of the isnide to any destination.

3. the 'acl-outside' rejects all traffic from entering your home network, but the IPSec traffic is free and will cross because you will find a "sysopt connection permit-ipsec' configured on your PIX command that tells the operating system to allow all traffic destined for VPN tunnels without explicitly enabling it through the inbound ACL. If you have stopped the "sysopt" should stop your traffic and you will have more control on your tunnel traffic.

Personally, I usually disable the "sysopt" and control the VPN traffic in my incoming ACL.

Just a quick note, if you look more deeply into the ACL on the PIX functionality, you will find that no traffic moves inside, if she is not allowed on the external interface. For example, you can allow traffic between "inside" and "dmz" interfaces by adding an entry 'allow' on one of the ACLS applied to one of these interfaces. But when you want to allow traffic from the external interface (security level 0), you will need to allow in the inbound ACL applied on the external interface.

I could have written something vague, but I hope you get my point.

Thank you.

Salem.

IPSec Tunnel upward, but not accessible from local networks

Hello

I have an ASA5520 and a Snapgear. The IPSec tunnel is in place and works very well. But I am not able to access the local LAN on both sides. Here are a few setups:

SH crypt isakmp his

Active SA: 1 Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey) Total IKE SA: 1 1 IKE Peer: 10.10.10.2 Type : L2L Role : responder Rekey : no State : AM_ACTIVE

Crypto/isakmp:

crypto ipsec transform-set ESP-AES-256-MD5 esp-aes-256 esp-md5-hmac crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac crypto ipsec transform-set ESP-AES-192-MD5 esp-aes-192 esp-md5-hmac crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac crypto ipsec transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac crypto ipsec transform-set ESP-AES-192-SHA esp-aes-192 esp-sha-hmac crypto ipsec transform-set ESP-AES-128-MD5 esp-aes esp-md5-hmac crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac crypto ipsec security-association lifetime seconds 28800 crypto ipsec security-association lifetime kilobytes 4608000 crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set pfs group1 crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set transform-set ESP-AES-128-SHA ESP-AES-128-MD5 ESP-AES-192-SHA ESP-AES-192-MD5 ESP-AES-256-SHA ESP-AES-256-MD5 ESP-3DES-SHA ESP-3DES-MD5 ESP-DES-SHA ESP-DES-MD5 crypto map outside_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP crypto map outside_map interface outside crypto map IPSECTEST_map0 1 match address IPSECTEST_cryptomap crypto map IPSECTEST_map0 1 set peer 10.10.10.2 crypto map IPSECTEST_map0 1 set transform-set ESP-3DES-SHA crypto map IPSECTEST_map0 1 set nat-t-disable crypto map IPSECTEST_map0 1 set phase1-mode aggressive crypto map IPSECTEST_map0 interface IPSECTEST crypto isakmp enable outside crypto isakmp enable IPSECTEST crypto isakmp policy 10 authentication pre-share encryption 3des hash sha group 2 lifetime 3600

Route SH:

C 172.16.3.0 255.255.255.0 is directly connected, VLAN10 C 10.10.10.0 255.255.255.0 is directly connected, IPSECTEST C 192.168.112.0 255.255.254.0 is directly connected, inside

access-list:

IPSECTEST_cryptomap list extended access allowed object-group DM_INLINE_PROTOCOL_1 172.16.3.0 255.255.255.0 object 172.20.20.0

and here's the scenario:

If I make a ping of the asa to the Remote LAN, I got this:

ciscoasa (config) # ping 172.20.20.1
Type to abort escape sequence.
Send 5, echoes ICMP 100 bytes to 10.172.20.20.1, wait time is 2 seconds:
No route to the host 172.20.20.1

Success rate is 0% (0/1)

No idea what I lack?

Here's how to set up NAT ASA 8.3 exemption:

network object obj - 172.16.3.0
172.16.3.0 subnet 255.255.255.0

network object obj - 172.20.20.0
172.20.20.0 subnet 255.255.255.0

NAT (inside, outside) source static obj - 172.16.3.0 obj - 172.16.3.0 destination static obj - 172.20.20.0 obj - 172.20.20.0

Here's how it looks to the ASA 8.2 and below:

Inside_nat0_outbound to access extended list ip 172.16.3.0 allow 255.255.255.0 172.20.20.0 255.255.255.0
NAT (inside) 0-list of access Inside_nat0_outbound

IPSec tunnel and NetFlow packets

I have a router 1841 IPSec running with an ASA. F0/0 is the source interface. I also set up NetFlow, which must be sent through the IPSec tunnel to the parser. The acl setting the IPSec interesting traffic covers addresses, source and destination of NetFlow. But NetFlow Traffic is not captured by the tunnel. When I ping the destination router, icmp traffic is picked up and goes through the tunnel. Are there ways to force NetFlow traffic to go to the tunnel?

Thank you.

Y at - it a route to the destination address of netflow? I have noted problems with traffic heading towards a destination that was not in the routing table is not made down a VPN.

The GRE Tunnel descends?

So here's my setup:

Internal router (2821) > Cluster internal DMZ ASA > router DMZ (2821) > external DMZ Checkpoint Cluster > Branch Office router (877)

Internal Cluster ASA a configured PAT production internal then all the VLANS.

The router in the DMZ has an interior interface configured on the internal DMZ and an external interface configured on the external DMZ. The DMZ router has two interfaces configured loopback.

The external control point is configured with NAT for the incoming and outgoing traffic.

The branch is a DSL router with a static IP address.

The first requirement is to configure a GRE IPSec tunnel between the DMZ router and the branch office router.

The second condition is to configure a GRE IPSec tunnel between the internal router and the router in the DMZ.

The third requirement is to allow routing between the internal router and the branch through the router in the DMZ, because it is ultimately the connection between the head office and branch of live backup.

I configured a Contract by the IPSec Tunnel between the router in the DMZ and routers of Management Office successfully.

I can also set up a GRE Tunnel (without IPSec) between the internal router and the router in the DMZ.

However, whenever the GRE Tunnel establishes between internal and DMZ routers and a neighbouring forms EIGRP, EIGRP neighborhood between the router in the DMZ and the branch drops! See following the DMZ router log file:

1 = to branch tunnel

Tunnel of 100 = internal

002885:. 3 Mar 22:32:57.013: % LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed State to
002886:. 3 Mar 22:33:06.029: % DUAL-5-NBRCHANGE: IPv4 EIGRP 1: neighbor 172.17.205.61 (Tunnel1) is on the rise: new adjacency
002889:. 3 Mar 22:33:58.434: % LINK-3-UPDOWN: Interface Tunnel100, changed State to
002890.: 3 Mar 22:33:58.438: % LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel100, changed State to
002891:. 3 Mar 22:34:15.370: % DUAL-5-NBRCHANGE: IPv4 EIGRP 1: neighbor 192.168.5.66 (Tunnel100) is on the rise: new adjacency
002892:. 22:34:30.551 3 Mar: % DUAL-5-NBRCHANGE: 1 IPv4 EIGRP: neighbour 172.17.205.61 (Tunnel1) is falling: expiry of hold time
002893:. 3 Mar 22:34:47.015: % LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, state change downstairs

The IPSec tunnel, for the branch remains in place throughout.

Can anyone help!?

The problem was that whenever the GRE Tunnel established between internal and DMZ routers and a forms of EIGRP neighbor branch was learning the next hop to the destination of tunnel from a different device.

This is how the branch was to learn the route to the tunnel destination:

Tunnel1 interface

Tandragee Sub Station router VPN Tunnel description

bandwidth 64

IP 172.17.205.62 255.255.255.252

no ip-cache cef route

delay of 20000

KeepAlive 10 3

source of tunnel Loopback1

tunnel destination 172.17.255.23

be-idz-vpn-01 #sh ip route 172.17.255.23

Routing for 172.17.255.23/32 entry

Through the 'static', the metric distance 1 0 known

Routing descriptor blocks:

* 172.17.252.129

Path metric is 0, number of shares of traffic 1

be-idz-vpn-01 #sh ip route 172.17.252.129

Routing for 172.17.252.128/25 entry

Known via 'connected', distance 0, metric 0 (connected, via the interface)

Routing descriptor blocks:

* directly connected by GigabitEthernet0/1

Path metric is 0, number of shares of traffic 1

be-idz-vpn-01 #.

This is how the next hop as learned GRE Tunnel between internal and DMZ routers

be-idz-vpn-01 #sh ip route 172.17.252.129

Routing for 172.17.252.128/27 entry

By the intermediary of "eigrp 1", the known distance 170, metric 40258816, type external

Redistribution via eigrp 1

Last updated on Tunnel100 192.168.5.66, ago 00:07:25

Routing descriptor blocks:

* 192.168.5.66, 192.168.5.66, there is, through Tunnel100 00:07:25

Path metric is 40258816, 1/number of shares of traffic is

Time total is 10110 microseconds, minimum bandwidth 64 Kbps

Reliability 255/255, MTU minimum 1476 bytes

Loading 1/255, 2 hops

We can see how the next hop to the destination of tunnel 172.17.255.23 changed from known via 'connected' via GigabitEthernet0/1 known via "eigrp 1" through Tunnel100.

This case causes the Tunnel 1 drops.

The reason for this behavior was because the road to reach the next hop was acquired with a longest match through tunnel interface so that he won the race to the routing table.

The solution we applied:

Created a list of distribution on the branch office router in order to remove this specific route Tunnel 100 updates.

Router eigrp 1

distribute-list 1

Network 10.10.10.0 0.0.0.3

network 172.17.203.56 0.0.0.3

network 172.17.203.60 0.0.0.3

network 172.17.205.60 0.0.0.3

network 172.19.98.18 0.0.0.0

network 192.168.5.64 0.0.0.3

passive-interface Loopback1

be-idz-vpn-01 #sh access-list 1

IP access list standard 1

10 deny 172.17.252.128, wildcard bits 0.0.0.127 (1 match)

20 permit (1230 matches)

be-idz-vpn-01 #.

Once this has been applied, we could have the GRE Tunnel established between internal and DMZ routers with the tunneld ACCORD between the branch and the router in the DMZ.

In Facebook, when I click to view any other window (list of notifications, chat list, list of parameters, etc.), the lists do not stay upward

Whenever I click on something to Facebook to display another window/list, the list is not stay in place. It closes automatically

Start Firefox in Firefox to solve the issues in Safe Mode to check if one of the extensions or if hardware acceleration is the cause of the problem (switch to the DEFAULT theme: Firefox/tools > Modules > appearance/themes).
- Makes no changes on the start safe mode window.
- https://support.Mozilla.org/KB/safe+mode
- https://support.Mozilla.org/KB/troubleshooting+extensions+and+themes
Try turning off hardware acceleration.
- Tools > Options > advanced > General > Browsing: "use hardware acceleration when available.
If disable hardware acceleration works then check if there is an update available for your graphics display driver.
- https://support.Mozilla.org/KB/how-do-i-upgrade-my-graphics-drivers

force the IPSec tunnel to stay in place even if no traffic

Similar Questions

Maybe you are looking for