Packet-trace for vpn l2l

Similar Questions

• Policy NAT for VPN L2L

  Summary:

  We strive to establish a two-way VPN L2L tunnel with a partner. VPN traffic is one-to-many towards our partner, and our partner they need of a many-to-one to us (they need to access a host on our network). In addition, our partner has many VPN, so they force us to use a separate NAT with two private hosts addresses, one for each direction of the tunnel.

  My initial configuration of the tunnel on my grown up side of Phase 1, but not IPSec. Partner ran debug that revealed that my host did not address NAT'd in the NAT policy. We use an ASA5520, ver 7.0.

  Here is the config:

  # #List of OUR guests

  the OURHosts object-group network

  network-host 192.168.x.y object

  # Hosts PARTNER #List

  the PARTNERHosts object-group network

  network-host 10.2.a.b object

  ###ACL for NAT

  # Many - to - many outgoing

  access-list extended NAT2 allowed ip object-group OURHosts-group of objects PARTNERHosts

  # One - to - many incoming

  VIH3 list extended access permit ip host 192.168.c.d PARTNERHosts object-group

  # #NAT

  NAT (INSIDE) 2-list of access NAT2

  NAT (OUTSIDE) 2 172.20.n.0

  NAT (INSIDE) 3 access-list VIH3

  NAT (OUTSIDE) 3 172.20.n.1

  # #ACL for VPN

  access list permits extended VPN ip object-group objects PARTNERHosts OURHosts-group

  access allowed extended VPN ip host 192.168.c.d PARTNERHosts object-group list

  # #Tunnel

  tunnel-group type ipsec-l2l

  card <#>crypto is the VPN address

  card crypto <#>the value transform-set VPN

  card <#>crypto defined peer

  I realize that the ACL for the VPN should read:

  access allowed extended VPN ip host 172.20.n.0 PARTNERHosts object-group list

  access allowed extended VPN ip host 172.20.n.1 PARTNERHosts object-group list

  .. . If the NAT was working properly, but when this ACL is used, Phase 1 is not even negotiating, so I know the NAT is never translated.

  What am I missing to NAT guests for 172.20 addresses host trying to access their internal addresses via the VPN?

  Thanks in advance.

  Patrick

  Here is the order of operations for NAT on the firewall:

  1 nat 0-list of access (free from nat)

  2. match the existing xlates

  3. match the static controls

  a. static NAT with no access list

  b. static PAT with no access list

  4. match orders nat

  a. nat [id] access-list (first match)

  b. nat [id] [address] [mask] (best match)

  i. If the ID is 0, create an xlate identity

  II. use global pool for dynamic NAT

  III. use global dynamic pool for PAT

  If you can try

  (1) a static NAT with an access list that will have priority on instruction of dynamic NAT

  (2) as you can see on 4A it uses first match with NAT and access list so theoretically Exchange autour should do the trick.

  I don't see any negative consequences? -Well Yes, you could lose all connectivity. I don't think that will happen, but I can't promise if you do absolutely not this after-hours.

  Jon

• MS CA for VPN L2L ASA

  What type of certifcates I should issueing bee in my ASA.

  Now I'm issueing IPSEC (offline) and I don't know if it's the right kind.

  I have ICP work for mobile users. simply not L2L

  Yes,

  Which can cause failure.

  Put command

  "ignore-ipsec-keyusage" under the CompanyTrustPoint

  That should solve.

• ASA 8.4. (1) VPN L2L can only be established through default gateway

  Hi all!

  We have an ASA 5510, with two internet connections. A destined for VPN l2l and the other to access inet users in general.

  On asa 8.04, I configured the encryption on inteface "VPNAccess" card and a static route on the remote peer L2L with access internet VPN, the default rotue pointed the router General inet.

  We bought a new firewall with 8.4.1 and now asa only tries to open the remote if peer traffic is on the default gateway.

  It does not take into account routes more specific (I mean longer masks) and always tries to use the gateway by default, but only for VPN, if I do a trace to that peer route, it uses the routing table correctly.

  Any advice?

  Thank you!

  Well well, (any, any) certainly does not help.

  You need to be more specific, otherwise, even once, as suggested earlier, he does not know which interface to use because you don't have specify it.

  In addition, you must also be precise with the source network and destination. Otherwise, the firewall will not know which interface the subnet should be connected to.

  More precise best for NAT statement.

  NAT (, PublicTESAVPNBackup) source static static destination

• Cisco ASA (8.3) - Packet trace / Multi context Classification

  Hello

  I use packet - trace for a while on and outside, with mixed results.

  I am running a firewall context multi with more than 10 of the same shared contexts outside the interface / network.

  All interfaces have obviously valid and unique IPs and also the unique MAC addresses as automatic address mac is enabled in the system context.

  It is an ASA 5550 running 8.3 (2.10) Provisional includes therefore the fix for the bug failed packet classification - draw well known.

  So in theory, with firewall settings on a shared interface ASA must use the firewall MAC address to classify incoming traffic on the correct firewall and as far as I know, only retreating to use TAR to classify if the Mac of the interface are the same. Actually on my platform, appears not to be the case and the classifier uses NAT to determine the context of destination. I see this with live traffic (that is not generated by packet - trace) in newspapers and can prove it by disabling some NAT rules (there is some overlap with the IP address behind each firewall).

  My question about packet trace is - in the scenario above with an external interface shared, tracer package uses not ALWAYS NAT to determine the context of destination? Or tracer packet search address MAC interface penetration depending on what context you run packet tracer of? It seems that packet - trace uses NAT in my case which could be just symptomatic of the potential bug I described above, rather than by design.

  I searched the forums for an answer to this and have not found one - don't know if it will be a question for developers TAC?

  See you soon

  Paul

  Hi Paul,.

  The packet - trace has no way to specify the MAC address of the simulated package, so it will always return a check of the NAT. It is currently a limiation of the feature of packet - trace in multiple context mode.

  In addition, if your NAT rules contains the 'none' keyword of the pair of the interface, you should be aware of this bug:

  CSCts07069 - ASA: packet classifier fails with "any" in the rule being NAT (fixed in 8.3.2.28)

  Hope that helps.

  -Mike

• S2S vpn pings go but watch drop packet tracer

  Hi guys,.

  Thanks for a great forum!

  I have a vpn tunnel of work implemented between 2 ASAs, that I use the tunnel daily for management purposes. When I simulate the traffic entering the tunnel at tracers package one end shows a drop of water...

  The flow rate is gcoutside inside the shared_vpn_inside interface.

  Packet-trace entry tcp gcoutside 192.168.77.109 10000 192.168.70.10 80 retail

  It gives the following:

  Phase: 8

  Type: VPN

  Subtype: ipsec-tunnel-flow

  Result: DECLINE

  Config:

  Additional information:

  Direct flow from returns search rule:

  ID = 0x744b44f0, priority = 69 = ipsec-tunnel-flow area, deny = false

  hits = 32062, user_data = 0xb2f965c, cs_id = 0 x 0, reverse, flags = 0 x 0 = 0 protocol

  Hide ip src/id =192.168.77.0, = 255.255.255.0, port = 0, = 0 tag

  IP/ID=192.168.70.0 DST, mask is 255.255.255.0, port = 0, tag = dscp 0 = 0 x 0

  input_ifc = gcoutside, output_ifc = any

  And just to point out, all through the tunnel works... I can't find any errors anywhere... Not in the newspapers, nowhere.

  Why is it when everything seems to work?

  See you soon

  Hello

  I guess I could have remembered as bad. I tend not to use the "packet-tracer" to test the management VPN remote connections to the Local level. I tend to use to begin the negotiation of VPN when I don't have access to equipment that can use the VPN L2L connection.

  So it would be nice if you can not just simply test connectivity to the subject of connection that are supposed to be coming through a VPN connection. Even if this VPN connection is currently on the rise.

  I actually tested with earlier with a couple of different units of the SAA, and it has not worked for the connection which were rising and negotiated SAs.

  -Jouni

• Dynamic routing for VPN Failover L2L

  Hello

  Can someone offer me some advice on this please?

  I have attached a simple diagram of our EXTENSIVE referral network.

  Overview

  • The firewall is ASA 5510 running 8.4 (9)
  • Basic to the Headquarters network uses OSPF
  • On ASA static routes are redistributed into OSPF
  • On ASA for VPN static routes are redistributed into OSPF with 130 metric so redistributed BGP routes are preferred
  • Basic network has a static route to 10.0.0.0/8 to Corporate WAN, which is redistributed into OSPF
  • Branch Office WAN uses BGP - routes are redistributed into OSPF
  • The branch routers using VRRP for redundancy of the IP for the default gateway of local customers.
  • Branch router main past off VRRP IP to router backup when the WAN interface is down
  • BO backup router (. 253) contains only a default route to the internet
  • In normal operation, the traffic to and from BO uses Local Branch Office WAN
  • If local BO WAN link fails, traffic to and from the BO uses IPSec VPN via public Internet

  I try to configure dynamic routing on our network for when a branch switches to the IPsec VPN. What I want to happen (not sure if it is possible) is for the ASA announce the subnet to the remote end of the VPN in OSPF to Headquarters.

  I managed to get this working using IPP, but for some reason any VPN stay up all the time when we are not in a failover scenario. This causes the ASA added the table as a static route is the remote subnet in it and do not use the announced route of OSPF from the core network. This prevents the BO customers access to the Internet. If I remove the IPP on the VPN setting, ASA learns the route to the subnet via the WAN BO - resumes normal operation.

  I have configured the metric of the static routes that get redistributed into OSPF by ASA superior to 110. This is so that the routes redistributed by the WAN BO OSPF BGP, are preferred. The idea being that when the WAN link is again available, the routing changes automatically and the site fails to WAN BO.

  I guess what I need to know is; This design is feasible, and if so where I'm going wrong?

  Thank you

  Paul

  Hi Paul,.

  your ASA maintains the tunnel alive only because this path exists on ASA.  This is why you must use IP - SLA on ASA to push network taffic "10.10.10.0/24" based on the echo response, using the ALS-intellectual property

  Please look at the example below, in the example below shows that the traffic flows through the tunnel, only if the ASA cannot reach the 10.10.10.0/24 network via the internal network of HQ.

  This configuration illuminate ASA.

  Route inside 10.10.10.0 255.255.2550 10.0.0.2 track 10

  (assuming 10.0.0.2 ip peering from inside the ip address of the router to HO)

  Route outside 10.10.10.0 255.255.255.0 xxx.xxx.xxx.xxx 254

  (value of 254 is a more expensive route to go via IPSec tunnel and x = the bridge by default-ISP)

  ALS 99 monitor

  type echo protocol ipIcmpEcho 10.10.10.254 inside interface

  NUM-package of 3

  frequency 10

  Annex monitor SLA 99 life never start-time now

  track 10 rtr 99 accessibility

  Let me know, if this can help.

  Thank you

  Rizwan James

• VPN l2l failed inside on ASA 5520 (8.02)

  VPN l2l is dropping packets to Phase 5 because of a rule configured. I have an isakmp his but the client cannot connect to the destination here in my network. I'll post my config to access list at the bottom of the Packet-trace output.

  vpnASA01 # entry packet - trace within the icmp [10.0.0.243] 0 8 10.97.29.73 det

  Phase: 1

  Type: CAPTURE

  Subtype:

  Result: ALLOW

  Config:

  Additional information:

  Direct flow from returns search rule:

  ID = 0xc92087c8, priority = 12, area = capture, deny = false

  hits = 85188209121, user_data = 0xc916a478, cs_id = 0 x 0, l3_type = 0 x 0

  Mac SRC = 0000.0000.0000, mask is 0000.0000.0000

  DST = 0000.0000.0000 Mac, mask is 0000.0000.0000

  Phase: 2

  Type: ACCESS-LIST

  Subtype:

  Result: ALLOW

  Config:

  Implicit rule

  Additional information:

  Direct flow from returns search rule:

  ID = 0xc87f1f98, priority = 1, domain = allowed, deny = false

  hits = 85193048387, 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 0000.0000.0000

  Phase: 3

  Type: FLOW-SEARCH

  Subtype:

  Result: ALLOW

  Config:

  Additional information:

  Not found no corresponding stream, creating a new stream

  Phase: 4

  Type:-ROUTE SEARCH

  Subtype: entry

  Result: ALLOW

  Config:

  Additional information:

  in 10.0.0.0 255.0.0.0 inside

  Phase: 5

  Type: ACCESS-LIST

  Subtype:

  Result: DECLINE

  Config:

  Implicit rule

  Additional information:

  Direct flow from returns search rule:

  ID = 0xc87f3670, priority = 111, domain = allowed, deny = true

  hits = 67416, user_data = 0 x 0, cs_id = 0 x 0, flags = 0 x 4000, protocol = 0

  SRC ip = 0.0.0.0 mask 0.0.0.0, port = 0 =

  DST ip = 0.0.0.0 mask 0.0.0.0, port = 0 =

  Result:

  input interface: inside

  entry status: to the top

  entry-line-status: to the top

  the output interface: inside

  the status of the output: to the top

  output-line-status: to the top

  Action: drop

  Drop-reason: flow (acl-drop) is denied by the configured rule

  = ACCESS-LIST + Config =.

  the object-group L2LVPN-blah_local network
  network-object 10.97.29.73 255.255.255.255
  the object-group L2LVPN-blah_remote network
  network-object [10.0.0.240] 255.255.255.240

  INBOUND_OUTSIDE list of allowed ip extended access object-L2LVPN-blah_remote L2LVPN-blah_local group object

  L2LVPN-blah_obj allowed extended ip access-list object-L2LVPN-blah_local group L2LVPN-blah_remote

  access-list SHEEP extended permits all ip [10.0.0.243] 255.255.255.240

  Route outside [10.0.0.240] [10.97.29.1] 255.255.255.240 1

  address for correspondence card crypto outside-VPN 46 L2LVPN - blah_obj
  peer set card crypto VPN-exterior 46 [10.0.0.243]
  outside-VPN 46 transform-set esp-sha-aes-256 crypto card
  outside-VPN interface card crypto outside

  IPSec-l2l type tunnel-group [10.0.0.243]
  IPSec-attributes of tunnel-group [10.0.0.243]
  pre-shared-key *.

  [10.0.0.1] is to protect the global addresses of clients. Assume that these are still used in place of the current range of intellectual property. 10.0.0.240/28

  ===========================================

  Thanks in advance.

  Michael Garcia

  Profit Systems, Inc..

  Hi Michael,

  -Is the IP peer really part of the network that make up the field of encryption?

  -Is the ACL INBOUND_OUTSIDE applied (incoming) inside or outside interface (inbound)? It is the current form, it would need to be on the external interface.

  -You specify the peer IP only in the ACL SHEEP, so all other traffic is NAT would and eventually denied because it does not match the field of encryption

  Someone else may have a few ideas, but these are questions I have for the moment.

  James

• NATting for VPN traffic only

  I have a client with an ASA 5505 who has several networks, he tries to communicate via a VPN tunnel with a desktop remotely. One of the networks does not work because it is also used on the other side of the tunnel management interface, and none of both sides seem ready to re - IP their interior space.

  Their proposed solution is to NAT the contradictory network on this side to a different subnet firewall before passing through the tunnel. How to implement a NAT which only uses the VPN tunnel while the rest of the traffic that comes through this device of the United-NATted Nations?

  The network in question is 192.168.0.0/24. Their target you want the NAT is 172.16.0.0/24. Config of the SAA is attached.

  Hello

  Basically, the political dynamic configuration PAT should work to connect VPN L2L because the PAT political dynamics is processed before PAT/NAT dynamic configurations.

  Only NAT configurations that can replace this dynamic NAT of the policy are

  • NAT0 / exempt NAT configuration
  • Strategy static NAT/PAT
  • Public static NAT/PAT

  And because we have determined that the only problem is with the network 192.168.0.0/24 and since there is no static configuration NAT/PAT or static policy NAT/PAT, then PAT political dynamics should be applied. Unless some configurations NAT0 continues to cause problems.

  The best way to determine what rules are hit for specific traffic is to use the command "packet - trace" on the SAA

  Packet-trace entry inside tcp 192.168.0.100 12345 10.1.7.100 80

  For example to simulate an HTTP connection at random on the remote site

  This should tell us for example

  • Where the package would be sent
  • He would pass the ACL interface
  • What NAT would be applied
  • It would correspond to any configuration VPN L2L
  • and many others

  Then can you take a sample output from the command mentioned twice and copy/paste the second result here. I ask get exit twice because that where the actual VPN L2L negotiations would go through the first time that this command would only raise the L2L VPN while the second command could show already all the info of what actually passed to the package simulated.

  In addition, judging by the NAT format you chose (political dynamics PAT), I assume that only your site connects to the remote site? Given that the political dynamics PAT (or dynamic PAT) normal does not allow creating a two-way connection. Connections can be opened that from your site to the remote site (naturally return traffic through automatically because existing connections and translations)

  -Jouni

• Direct specific ports down a VPN L2L

  I have a client who is trying to use an ISP hosted web filtering and content management a gateway, the ISP wants to use and L2L ISPEC VPN on site at their front door to control the traffic. Today we have the tunnel with an ACL test for peripheral test side customer down the tunnel, but that it blocks all traffic that is not being analyzed. The problem is that they are on an ASA 5510 with 8.2.2. You cannot add ports tcp in the ACL sheep, it error when you try to apply the nat 0 access-list statement sheep (inside). We can define the ports to go down the VPN traffic interesting ACL with number, but there is no way to send just the web ports down the VPN and allow the other ports on regular overflow interface NAT I was look in 8.4 and see if it allows a policy NAT (twice the NAT for virtual private networks) to set a port to a range of IPS (IE (: nat static destination WEBINSPECT-WEBINSPECT (indoor, outdoor) static source a whole) but who only define as web ports.

  I do not have an ASA test to use, but I guess that vpn l2l will be only by IP and I can not define a port tunnel.

  In any case, it is a strange, but the ideas are welcome. I don't think it's possible, but I thought I'd see if anyone encountered at the front.

  Hello

  Well to give you a simple example where we use the double NAT / manual transmission NAT to handle traffic

  For example a configuration example I just did on my 8.4 (5) ASA

  The following configuration will

  • Set the 'object' that contains the source network for NAT
  • Set the 'object' that contains the service for NAT
  • Define the real NAT

  The real NAT is going to make any connection from the network under 'Wireless' network object to the destination port TCP/80 will be sent 'WAN' interface without NAT

  Of course it is the next step with VPN L2L network under 'network wireless of the object' would correspond to the ACL of VPN L2L. But that seemed straight forward for you already

  the subject wireless network

  10.0.255.0 subnet 255.255.255.0

  service object WWW

  Service tcp destination eq www

  NAT (WLAN, WAN) static source without WIRE WIRELESS WWW WWW service

  The following configuration will

  • Define the "object-group", that defines networks of the source of the rule by default PAT for Internet traffic
  • Set the 'object' for the PAT address (could just use 'interface' instead of the 'object')
  • Define the real NAT

  The NAT configuration will just make a rule by default PAT for the wireless network. The key thing to note here is that we use the setting "auto after." This basically inserts the NAT rule to the priority of the very bottom of the ASA.

  object-group, network WIRELESS-network

  object-network 10.0.255.0 255.255.255.0

  network of the PAT object - 1.1.1.1

  host 1.1.1.1

  NAT (WLAN, WAN) after the automatic termination of wireless - NETWORK PAT dynamic source - 1.1.1.1

  Now we can use the command "packet - trace" to confirm that the NAT works as expected.

  WWW TEST-TRAFFIC

  ASA (config) # packet - trace 12355 1.2.3.4 entry WLAN tcp 10.0.255.100 80

  Phase: 1

  Type: UN - NAT

  Subtype: static

  Result: ALLOW

  Config:

  NAT (WLAN, WAN) static source without WIRE WIRELESS WWW WWW service

  Additional information:

  NAT divert on the output WAN interface

  Untranslate 1.2.3.4/80 to 1.2.3.4/80

  Phase: 2

  Type: IP-OPTIONS

  Subtype:

  Result: ALLOW

  Config:

  Additional information:

  Phase: 3

  Type: NAT

  Subtype:

  Result: ALLOW

  Config:

  NAT (WLAN, WAN) static source without WIRE WIRELESS WWW WWW service

  Additional information:

  Definition of static 10.0.255.100/12355 to 10.0.255.100/12355

  Phase: 4

  Type: HOST-LIMIT

  Subtype:

  Result: ALLOW

  Config:

  Additional information:

  Phase: 5

  Type: NAT

  Subtype: rpf check

  Result: ALLOW

  Config:

  NAT (WLAN, WAN) static source without WIRE WIRELESS WWW WWW service

  Additional information:

  Phase: 6

  Type: USER-STATISTICS

  Subtype: user-statistics

  Result: ALLOW

  Config:

  Additional information:

  Phase: 7

  Type: IP-OPTIONS

  Subtype:

  Result: ALLOW

  Config:

  Additional information:

  Phase: 8

  Type: USER-STATISTICS

  Subtype: user-statistics

  Result: ALLOW

  Config:

  Additional information:

  Phase: 9

  Type: CREATING STREAMS

  Subtype:

  Result: ALLOW

  Config:

  Additional information:

  New workflow created with the 1727146 id, package sent to the next module

  Result:

  input interface: WLAN

  entry status: to the top

  entry-line-status: to the top

  the output interface: WAN

  the status of the output: to the top

  output-line-status: to the top

  Action: allow

  TEST FTP - TRAFFIC

  ASA (config) # packet - trace entry tcp 10.0.255.100 WLAN 12355 1.2.3.4 21

  Phase: 1

  Type:-ROUTE SEARCH

  Subtype: entry

  Result: ALLOW

  Config:

  Additional information:

  in 0.0.0.0 0.0.0.0 WAN

  Phase: 2

  Type: IP-OPTIONS

  Subtype:

  Result: ALLOW

  Config:

  Additional information:

  Phase: 3

  Type: INSPECT

  Subtype: inspect-ftp

  Result: ALLOW

  Config:

  class-map inspection_default

  match default-inspection-traffic

  Policy-map global_policy

  class inspection_default

  inspect the ftp

  global service-policy global_policy

  Additional information:

  Phase: 4

  Type: NAT

  Subtype:

  Result: ALLOW

  Config:

  NAT (WLAN, WAN) after the automatic termination of wireless - NETWORK PAT dynamic source - 1.1.1.1

  Additional information:

  Definition of dynamic 10.0.255.100/12355 to 1.1.1.1/12355

  Phase: 5

  Type: HOST-LIMIT

  Subtype:

  Result: ALLOW

  Config:

  Additional information:

  Phase: 6

  Type: NAT

  Subtype: rpf check

  Result: ALLOW

  Config:

  NAT (WLAN, WAN) after the automatic termination of wireless - NETWORK PAT dynamic source - 1.1.1.1

  Additional information:

  Phase: 7

  Type: USER-STATISTICS

  Subtype: user-statistics

  Result: ALLOW

  Config:

  Additional information:

  Phase: 8

  Type: IP-OPTIONS

  Subtype:

  Result: ALLOW

  Config:

  Additional information:

  Phase: 9

  Type: USER-STATISTICS

  Subtype: user-statistics

  Result: ALLOW

  Config:

  Additional information:

  Phase: 10

  Type: CREATING STREAMS

  Subtype:

  Result: ALLOW

  Config:

  Additional information:

  New workflow created with the 1727154 id, package sent to the next module

  Result:

  input interface: WLAN

  entry status: to the top

  entry-line-status: to the top

  the output interface: WAN

  the status of the output: to the top

  output-line-status: to the top

  Action: allow

  As you can see traffic TCP/80 corresponds to rule on the other. And the FTP used for example corresponds to rule by default PAT as expected.

  If you want to know a little more about the new NAT 8.3 format + you can check a document I created

  https://supportforums.Cisco.com/docs/doc-31116

  Hope this helps you, please mark it as answered in the affirmative or rate of answer.

  Naturally ask more if necessary

  -Jouni

• Problem VPN l2l * No. Tx and Rx *.

  Hi friends,

  I have a problem with the version 2 of ASA´s 5540 and 5510 8.4.3 and 8.2.5 respectively, TOPOLOGY: LAN - ASA-* WAN *-ASA - LAN

  I have no side 5540 TX

  # sh vpn-sessiondb detail l2l

  Session type: LAN-to-LAN detailed

  Link: 189.213.94.5

  Index: 107 IP Addr: 189.213.94.5

  Protocol: IPsec IKEv1

  Encryption: hashing 3DES 3DES 3DES: SHA1 SHA1 SHA1

  TX Bytes: 0 bytes Rx: 19104

  Opening time: 09:30:57 CST Friday, February 8, 2013

  Duration: 0: 00: 14:00

  IKEv1 Tunnels: 1

  IPsec Tunnels: 2

  IKEv1:

  Tunnel ID: 107.1

  The UDP Src Port: 500 UDP Dst Port: 500

  IKE Neg Mode: Hand Auth Mode: preSharedKeys

  Encryption: 3DES hash: SHA1

  Generate a new key Int (T): 86400 seconds given to the key Left (T): 85549 seconds

  Group D/H: 2

  Name of the filter: OUTSIDE_cryptomap_1

  IPv6 filter:

  IPsec:

  Tunnel ID: 107,2

  Local addr: 10.10.0.0/255.255.255.0/0/0

  Remote addr: 192.168.2.0/255.255.255.0/0/0

  Encryption: 3DES hash: SHA1

  Encapsulation: Tunnel PFS Group: 2

  Generate a new key Int (T): 28800 seconds given to the key Left (T): 27949 seconds

  Generate a new key Int (D): 4608000 K-bytes given to the key Left (D): 4607991 K-bytes

  Idle Time Out: 0 Minutes idling left: 0 Minutes

  TX Bytes: 0 bytes Rx: 10200

  TX pkts: 0 Rx Pkts: 170

  IPsec:

  Tunnel ID: 107.3

  Local addr: 10.5.0.0/255.255.0.0/0/0

  Remote addr: 192.168.2.0/255.255.255.0/0/0

  Encryption: 3DES hash: SHA1

  Encapsulation: Tunnel PFS Group: 2

  Generate a new key Int (T): 28800 seconds given to the key Left (T): 27952 seconds

  Generate a new key Int (D): 4608000 K-bytes given to the key Left (D): 4607992 K-bytes

  Idle Time Out: 0 Minutes idling left: 0 Minutes

  TX Bytes: 0 bytes Rx: 8904

  TX pkts: 0 Rx Pkts: 84

  NAC:

  Reval Int (T): 0 seconds Left (T) Reval: 0 seconds

  SQ (T) Int: 0 seconds EoU Age (T): 852 seconds

  Chock on the left (T): 0 second Posture token:

  Redirect URL:

  And I have no side 5510 Rx

  # sh vpn-sessiondb detail l2l

  Session type: LAN-to-LAN detailed

  Link: 201.140.121.82

  Index: 695 IP Addr: 201.140.121.82

  Protocol: IPsec IKE

  Encryption: 3DES hash: SHA1

  TX Bytes: 22480 Rx bytes: 0

  Connect time: 17:33:15 CST Friday, February 8, 2013

  Duration: 0: 00: 16:00

  IKE tunnels: 1

  IPsec Tunnels: 2

  IKE:

  Tunnel ID: 695.1

  The UDP Src Port: 500 UDP Dst Port: 500

  IKE Neg Mode: Hand Auth Mode: preSharedKeys

  Encryption: 3DES hash: SHA1

  Generate a new key Int (T): 86400 seconds given to the key Left (T): 85407 seconds

  Group D/H: 2

  Name of the filter:

  IPsec:

  Tunnel ID: 695.2

  Local addr: 192.168.2.0/255.255.255.0/0/0

  Remote addr: 10.10.0.0/255.255.255.0/0/0

  Encryption: 3DES hash: SHA1

  Encapsulation: Tunnel PFS Group: 2

  Generate a new key Int (T): 28800 seconds given to the key Left (T): 27808 seconds

  Generate a new key Int (D): 4608000 K-bytes given to the key Left (D): 0 K-bytes

  Idle Time Out: 0 Minutes idling left: 0 Minutes

  TX Bytes: 11880 Rx bytes: 0

  TX pkts: Rx 198 Pkts: 0

  IPsec:

  Tunnel ID: 695.3

  Local addr: 192.168.2.0/255.255.255.0/0/0

  Remote addr: 10.5.0.0/255.255.0.0/0/0

  Encryption: 3DES hash: SHA1

  Encapsulation: Tunnel PFS Group: 2

  Generate a new key Int (T): 28800 seconds given to the key Left (T): 27811 seconds

  Generate a new key Int (D): 4608000 K-bytes given to the key Left (D): 0 K-bytes

  Idle Time Out: 0 Minutes idling left: 0 Minutes

  TX Bytes: 10600 Rx bytes: 0

  TX pkts: Rx 100 Pkts: 0

  NAC:

  Reval Int (T): 0 seconds Left (T) Reval: 0 seconds

  SQ (T) Int: 0 seconds EoU Age (T): 994 seconds

  Chock on the left (T): 0 second Posture token:

  Redirect URL:

  Hope you guys could help me understand the issue correctly.

  Thank you!

  Looks like your problem is that you have the route to 192.168.2.X pointing inwards on your 5540, when it should be pointing to your interface OUTSIDE, or just leave the default route take care of it.

  Remove the static method for 192.168.2.0 on the 5540:

  no road inside 192.168.2.0 255.255.255.0 10.10.0.1 1

  Then see if two-way communication that happens. Try: entry packet - trace inside the 10.10.0.1 icmp 1 1 192.168.2.1

  Once again. If all checked out, see if you have two-way communication through the VPN.

• Tunnel VPN L2L with NATTing will not allow traffic which will be initiated by spoke to the hub.

  Traffic from internal hosts will NAT address works ok, but what speaks tests it traffic never connects.

  get the 10.1.12.232 NAT host would be 172.27.63.133 and past through the VPN tunnel to 10.24.4.65 without problem. However when 10.24.4.65 tries to ping or connect to 172.27.63.133 traffic does not make inside host 10.1.12.232

  ASA-1 #.
  !
  network object obj - 172.27.73.0
  172.27.73.0 subnet 255.255.255.0
  network object obj - 172.27.63.0
  172.27.63.0 subnet 255.255.255.0
  network object obj - 10.1.0.0
  10.1.0.0 subnet 255.255.0.0
  network object obj - 10.24.4.64
  subnet 10.24.4.64 255.255.255.224
  network object obj - 172.27.73.0 - 172.27.73.255
  range 172.27.73.0 172.27.73.255
  the object of the 10.0.0.0 network
  subnet 10.0.0.0 255.0.0.0
  network object obj - 24.173.237.212
  Home 24.173.237.212
  network object obj - 10.1.12.232
  Home 10.1.12.232
  network object obj - 172.27.63.133
  Home 172.27.63.133
  the DM_INLINE_NETWORK_9 object-group network
  object-network 10.0.0.0 255.255.255.0
  object-network 10.0.11.0 255.255.255.0
  object-network 10.0.100.0 255.255.255.0
  object-network 10.0.101.0 255.255.255.0
  object-network 10.0.102.0 255.255.255.0
  object-network 10.0.103.0 255.255.255.0
  the DM_INLINE_NETWORK_16 object-group network
  object-network 10.1.11.0 255.255.255.0
  object-network 10.1.12.0 255.255.255.0
  object-network 10.1.13.0 255.255.255.0
  object-network 10.1.3.0 255.255.255.0
  !
  outside_1_cryptomap list extended access permitted ip object-group DM_INLINE_NETWORK_16-group of objects DM_INLINE_NETWORK_9
  access extensive list ip 172.27.73.0 outside_8_cryptomap allow 255.255.255.0 10.24.4.64 255.255.255.224
  access extensive list ip 172.27.63.0 outside_8_cryptomap allow 255.255.255.0 10.24.4.64 255.255.255.224
  !
  list of allowed outside access extended ip 10.24.4.64 255.255.255.224 172.27.63.0 255.255.255.0
  list of allowed outside access extended ip 10.24.4.64 255.255.255.224 10.1.0.0 255.255.0.0
  list of allowed outside access extended ip 172.27.63.0 255.255.255.0 10.1.0.0 255.255.0.0
  !
  NAT (inside, all) source static obj - 172.27.73.0 obj - 172.27.73.0 destination static obj - 10.24.4.64 obj - 10.24.4.64 no-proxy-arp-search to itinerary
  NAT (inside, all) source static obj - 172.27.63.0 obj - 172.27.63.0 destination static obj - 10.24.4.64 obj - 10.24.4.64 no-proxy-arp-search to itinerary
  NAT (inside, outside) source dynamic obj - 10.66.0.0 obj - 172.27.73.0 - 172.27.73.255 destination static obj - 10.24.4.64 obj - 10.24.4.64
  NAT (inside, outside) source dynamic obj - 10.70.0.0 obj - 172.27.73.0 - 172.27.73.255 destination static obj - 10.24.4.64 obj - 10.24.4.64
  NAT (inside, outside) source dynamic obj - 10.96.228.0 obj - 172.27.73.0 - 172.27.73.255 destination static obj - 10.24.4.64 obj - 10.24.4.64
  NAT (inside, outside) source dynamic obj - 10.96.229.0 obj - 172.27.73.0 - 172.27.73.255 destination static obj - 10.24.4.64 obj - 10.24.4.64
  NAT (inside, outside) source dynamic obj - 192.168.5.0 obj - 172.27.73.0 - 172.27.73.255 destination static obj - 10.24.4.64 obj - 10.24.4.64
  NAT (inside, outside) source dynamic obj - 10.75.0.0 obj - 172.27.73.0 - 172.27.73.255 destination static obj - 10.24.4.64 obj - 10.24.4.64
  NAT (inside, outside) source dynamic obj - 10.11.0.0 obj - 172.27.73.0 - 172.27.73.255 destination static obj - 10.24.4.64 obj - 10.24.4.64
  NAT (inside, outside) source static obj - 10.1.3.37 obj - 10.71.0.37 destination static obj - 50.84.209.140 obj - 50.84.209.140
  NAT (inside, outside) source static obj - 10.1.3.38 obj - 10.71.0.38 destination static obj - 50.84.209.140 obj - 50.84.209.140
  NAT (inside, outside) source static obj - 10.1.12.232 obj - 172.27.63.133 destination static obj - 10.24.4.64 obj - 10.24.4.64
  NAT (inside, outside) source dynamic obj - 10.1.0.0 obj - 172.27.73.0 - 172.27.73.255 destination static obj - 10.24.4.64 obj - 10.24.4.64
  !
  NAT (exterior, Interior) source static obj - 10.24.4.64 obj - 10.24.4.64 destination static obj - 172.27.63.133 obj - 10.1.12.232
  NAT (outside, outside) source static obj - 10.24.4.64 obj - 10.24.4.64 destination static obj - 172.27.63.133 obj - 10.1.12.232

  the object of the 10.0.0.0 network
  NAT (inside, outside) dynamic obj - 24.173.237.212
  !
  NAT (VendorDMZ, outside) the after-service automatic source dynamic obj - 192.168.13.0 obj - 24.173.237.212
  outside access-group in external interface
  Route outside 0.0.0.0 0.0.0.0 24.173.237.209 1
  Route inside 10.1.0.0 255.255.0.0 10.1.10.1 1
  Route inside 10.2.1.0 255.255.255.248 10.1.10.1 1
  !
  Crypto ipsec transform-set ikev1 SHA-ESP-3DES esp-3des esp-sha-hmac
  Crypto ipsec transform-set ikev1 ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
  Crypto ipsec transform-set ikev1 ESP-AES-256-MD5 esp-aes-256 esp-md5-hmac
  Crypto ipsec transform-set ikev1 ESP-3DES-SHA-DH2-esp-3des esp-sha-hmac
  Crypto ipsec pmtu aging infinite - the security association
  !
  card crypto GEMed 8 corresponds to the address outside_8_cryptomap
  card crypto GEMed 8 set peer 64.245.57.4
  card crypto GEMed 8 set ikev1 transform-set ESP-AES-256-SHA ESP-AES-256-MD5
  GEMed outside crypto map interface
  !
  : end
  ASA-1 #.

  Hello

  First of all, I would like to remove these two lines because they do nothing productive

  nat (outside,inside) source static obj-10.24.4.64 obj-10.24.4.64 destination static obj-172.27.63.133 obj-10.1.12.232nat (outside,outside) source static obj-10.24.4.64 obj-10.24.4.64 destination static obj-172.27.63.133 obj-10.1.12.232

  Then, I was running packet - trace to see what NAT rule actually hit you.

  packet-tracer input inside 10.1.12.232 12345 10.24.4.65 12345

• Add the existing network of VPN l2l

  I have properly configured VPN l2l between our main site and 2 offices. Now, I would like to allow additional networks on the main site to access the branch sites. Here the doc of Cisco (http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807fad90.shtml) presents a method to do this by adding an additional interface. Is it possible to do without the addition of an interface?

  Here are the relevant config on the main site ASA (8,0) and one of the remote PIX (7.0):

  =========================

  ASA (main site)

  access extensive list ip 172.16.0.0 outside_1_cryptomap allow 255.255.255.0 172.16.29.0 255.255.255.0

  access extensive list ip 172.16.1.0 outside_1_cryptomap allow 255.255.255.0 172.16.29.0 255.255.255.0

  card crypto outside_map 1 match address outside_1_cryptomap

  card crypto outside_map 1 set 24.97.x.x counterpart

  map outside_map 1 set of transformation-ESP-3DES-MD5 crypto

  =========================

  PIX (remote site)

  access extensive list ip 172.16.29.0 outside_cryptomap_20_2 allow 255.255.255.0 172.16.0.0 255.255.255.0

  access extensive list ip 172.16.29.0 outside_cryptomap_20_2 allow 255.255.255.0 172.16.1.0 255.255.255.0

  card crypto outside_map 20 match address outside_cryptomap_20_2

  card crypto outside_map 20 peers set 204.14.x.x

  outside_map card crypto 20 the transform-set ESP-3DES-MD5 value

  Just add valuable traffic to your access lists. New = 172.16.2.0/24 network

  ASA (main site)

  outside_1_cryptomap to access extended list ip 172.16.2.0 allow 255.255.255.0 172.16.29.0 255.255.255.0

  PIX (remote site)

  access extensive list ip 172.16.29.0 outside_cryptomap_20_2 allow 255.255.255.0 172.16.2.0 255.255.255.0

  Don't forget your nat exemption acl as well. For example...

  ASA (main site)

  extended access-list allow ip 172.16.2.0 255.255.255.0 172.16.29.0 255.255.255.0

  PIX (remote site)

  permit extended access list ip 172.16.29.0 255.255.255.0 172.16.2.0 255.255.255.0

• Question of redundancy VPN l2l using 2811 as endpoint devices

  I have a new implementation of VPN L2L passes using two 2811 s than VPN terminal devices. I'll try to use the HSRP address between the public interfaces of both routers as VPN peer address. The problem that I found during the test is that the tunnel will become active and debugs watch the HSRP address as an invalid address to form the tunnel. Have a work-around, or a better plan for redundancy on peering address using similar devices? Thanks in advance.

  Take a look at this doc about IOS IPSec HA.

  http://www.Cisco.com/en/us/docs/iOS/security/configuration/guide/sec_vpn_ha_enhance_ps6922_TSD_Products_Configuration_Guide_Chapter.html#wp1039849

• Go simple configuration of vpn L2L comply with security requirements

  Hello

  I have successfully install a L2L connection (5510, 7.2) and a 3rd party (SonicWall).

  Security requirements are such that (contractors) to our office users to connect to various devices to the 3rd party, BUT nothing to the 3rd party must connect to what be it at our office.

  I tried an outbound ACL (access-group L2L-RESTRICT the interface inside) inside the interface. But the funny thing is that I'm getting hits on the declarations of refusal on the ACL, although tests show no problems for you connect to multiple hosts to our site of the 3rd party. My ACL config looks like the following:

  <..snip..>

  Note to L2L-RESTRICT access-list * ATTENTION * WITH CAUTION - RESTRICTIONS ON the 3rd PARTY VPN L2L

  L2L-RESTRICT access-list scope allow icmp 192.168.16.0 255.255.255.0 10.180.21.0 255.255.255.0 echo-reply

  deny access list L2L-RESTRICT the scope ip 192.168.16.0 255.255.255.0 no matter what newspaper

  Note to L2L-RESTRICT access-list > NOTE< last="" line="" *must*="" be="" permit="" any="">

  L2L-RESTRICT access-list scope ip allow a whole

  !

  L2L-RESTRICT the interface inside access-group

  <..snip..>

  Their network is obviously 192.168.16.x and they won't be able to use a vlan from different source as "interesting traffic" ACL won't allow it. So that sounds good in theory

  I have it configured correctly? Is there a better way?

  Thanks in advance,

  Mike

  Mike,

  It seems that you might be able to assign a VPN ACL filter via a group assigned to each tunnel L2L policy. I have never done this personally before, but looks like it would work...

  http://www.Cisco.com/en/us/products/HW/vpndevc/ps2030/products_configuration_example09186a00808c9a87.shtml#configs