allow icmpv6 in ipv4-access list in the tunnel

Similar Questions

• ASA 5505 VPN works great but can't access internet via the tunnel to customers

  We have an ASA 5505 ASA 8.2.1 running and using IPSec for Remote access clients in the main office.  Remote access is a lot of work, with full access to network resources in the main office and the only thing I can't get to work is access to internet through the tunnel.  I don't want to use split tunneling.  I use ASDM 6.2.1 for configuration.  Any help is appreciated.  I'm probably missing something simple and it looked so much, I'm probably looking at right beyond the error.  Thanks in advance for your time and help!    Jim

  Add a statement of nat for your segment of customer on the external interface

  NAT (outside) - access list

  then allow traffic routing back on the same interface, it is entered in the

  permit same-security-traffic intra-interface

  *

  *

  * more than information can be found here:

  http://www.Cisco.com/en/us/products/ps6120/products_tech_note09186a00807...

  On Wednesday, 27 January 2010, at 23:12, jimcanova

• access list of split tunneling

  Hello

  I have some problems on ASA 5520 split tunneling configuration.

  Here's the scenario:

  Number of remote users connects ipsec with ASA 5520 (in central) using ubuntu vpnc-client.

  Split tunneling is used, in order to allow remote users to surf the Internet using their ISP.

  The goal is to remove the possibility for ssh/telnet servers within the local enterprise network for remote users.

  Here is a part of the config:

  internal REMOTE_gp group strategy
  attributes of Group Policy REMOTE_gp
  VPN-idle-timeout no
  Protocol-tunnel-VPN IPSec
  Group-lock no
  Split-tunnel-policy tunnelspecified
  value of Split-tunnel-network-list REMOTE_split

  tunnel-group type REMOTE access remotely

  tunnel-group REMOTE General attributes

  authentication-server-group RADIUSGR

  Group Policy - by default-REMOTE_gp

  REMOTE tunnel-group ipsec-attributes

  pre-shared-key *.

  ISAKMP keepalive retry threshold 15 10

  RADIUS protocol AAA-server RADIUSGR

  AAA-server RADIUSGR (INSIDE_LAN) 192.168.0.244

  REMOTE_split list extended access deny tcp 192.168.0.0 255.255.255.0 ssh telnet rank everything

  permit access ip 192.168.0.0 scope list REMOTE_split 255.255.255.0 192.168.100.0 255.255.255.0

  ip subnet ##192.168.100.0/24 - where from Radius Server to allocate ip addresses to remote users.

  INSIDE_LAN_in list extended access deny tcp 192.168.0.0 255.255.255.0 eq ssh 192.168.100.0 255.255.255.0

  INSIDE_LAN_in list extended access deny tcp 192.168.0.0 255.255.255.0 eq telnet 192.168.100.0 255.255.255.0

  permit access ip 192.168.0.0 scope list INSIDE_LAN_in 255.255.255.0 any

  It has nat enabled on the interface, but there is a special instruction in nat0 ACL for 192.168.100.0 subnet

  permit access ip 192.168.0.0 scope list INSIDE_LAN_nat0_outbound 255.255.255.0 192.168.100.0 255.255.255.0

  The problem is that the remote users can easily ssh and telnet servers in network INSIDE_LAN. Everything I put in INSIDE_LAN_in ACL, remote users still have full access to this network. Restrictions in the REMOTE_split ACL do not work either.

  You must configure vpn-filter rather to block telnet and ssh access as follows:

  Remote filter access list deny tcp 192.168.100.0 255.255.255.0 192.168.0.0 255.255.255.0 eq 22

  Remote filter access list deny tcp 192.168.100.0 255.255.255.0 192.168.0.0 255.255.255.0 eq 23

  distance-filter 192.168.100.0 ip access list allow 255.255.255.0 192.168.0.0 255.255.255.0

  attributes of Group Policy REMOTE_gp

  VPN-value filter-remote control

  Split tunnel acl has the following statement and it should be extended to standard ACLs instead of:

  REMOTE_split list of permitted access 192.168.0.0 255.255.255.0

  Hope that helps.

• Effect of the access lists on free access of high to low by default

  I'll implement access rules list on PIX525 (V6.3) with several DMZ, but want to minimize the rules.

  Scenario - 3 interfaces (inside (secuity100, average security50 outside Security0)

  To allow hosts on the way to reach the inside I create an access list applied to a central interface. However, will be an implicit (or explicit) deny at the end of the access list prevents the intermediate hosts with default value to open access to the lower security outside the interface?

  Thank you

  Mick

  Level of security and access lists:

  To grant access of lower to higher level, you need to an access list and a static.

  Equal to equal level cannot talk to each other.

  Higher level of security can talk to lower levels, if there is no access on this interface list and the NAT is configured correctly.

  ACL will add at the end a "deny ip any any" after a statement of license. So getting back to your question: If you allow a DMZ host to connect internal host on a specific port that all other connections are blocked. You must specify all the tarffic in this access list otherwise they will be blocked.

  The only exception is the traffic may be from other interface access lists to the demilitarized zone, answers etc. For example, you are allowing port 80 to a dmz host outside this traffic will not be verified again by the dmz access list.

  sincerely

  Patrick

• Question of access list for Cisco 1710 performing the 3DES VPN tunnel

  I have a question about the use of access lists in the configuration of a router Cisco 1710 that uses access lists to control traffic through the VPN tunnel.

  For example the following lines in a configuration on the remote router. My question is whether or not the traffic that matches the definition of list access-130 (something other than 192.168.100.0/24), cross the VPN tunnel or go directly to the Ethernet0 interface.

  My understanding is that traffic that matches the access list 120 would be encrypted and sent through the IPSec tunnel. If there was "ban" set out in the statements of 120 access-list, the traffic for those would be sent through the IPSec tunnel but not encrypted (if possible). And finally, given that the definition of crypto card reference only "adapt to 120", any traffic that matches 130 access list would be sent Ethernet0 but not associated with the card encryption and thus not sent through the IPSec tunnel. "

  Any input or assistance would be greatly appreciated.

  Map Test 11 ipsec-isakmp crypto

  ..

  match address 120

  Interface Ethernet0

  ..

  card crypto Test

  IP nat inside source overload map route sheep interface Ethernet0

  access-list 120 allow ip 192.168.100.0 0.0.0.255 10.10.0.0 0.0.255.255

  access-list 130 refuse ip 192.168.100.0 0.0.0.255 10.10.0.0 0.0.255.255

  access-list 130 allow ip 192.168.100.0 0.0.0.255 any

  sheep allowed 10 route map

  corresponds to the IP 130

  He would go through the interface e0 to the Internet in clear text without going above the tunnel

  Jean Marc

• No not removed from the external interface access-list access list?

  PIX515

  customer wanted to modify the access list (add a new line)

  so he has first publish no access-list command can

  apply the change to the access list, but the access list has been

  removed from the interface outside

  is this a normal behavior? on routers access list stay connected

  for the event of the interface if you issue no access-list command

  Thanks in advance for any comments

  JYP

  Hi Thibault-

  No, it is not a normal behavior, sounds more like an error by the customer. It's always a good idea to copy the required ACL on a text editor (Notepad) do not forget to include "access-group command" i.e. "access-group interface inside inside' or 'access-group out in interface outside' - when copying the required ACL and then issues a 'no access-list inside' or 'no access-list outside' the first line in the ACL copied on your notebook before copy you it to the PIX , also make sure that you are using the config and make an "m wr" (write memory) after the ACL modified have been applied on the PIX.

  Hope this helps-

• Cisco 837 and access list

  Hi all

  Sorry if my question sounds stupid, but I had a lot of problems with the syntax of the access list, especially to remove a line in an access list, for example:

  Here is my list of access

  access-list 120 allow ip 192.168.6.0 0.0.0.255 172.16.0.0 0.0.255.255

  access-list 120 allow ip 192.168.6.0 0.0.0.255 172.20.0.0 0.0.255.255

  access-list 120 allow ip 192.168.6.0 0.0.0.255 172.17.0.0 0.0.255.255

  If I want to delete only this line

  access-list 120 allow ip 192.168.6.0 0.0.0.255 172.16.0.0 0.0.255.255

  I do not know how, I if do:

  no access-list 120 allow ip 192.168.6.0 0.0.0.255 172.16.0.0 0.0.255.255

  all the access-list 120 is removed!

  Help, please!

  Olivier

  Hi, this is the usual behavior, if you delete the access list of the entire statement with sequence number is deleted.

  You can create a named extended access-list and have the sequence number for each statements.

  !

  Standard IP access list note

  permit 172.10.0.0 0.0.255.255

  10.1.1.0 permit 0.0.0.255

  permit 192.168.1.0 0.0.0.255

  deny all

  !

  and if you want to delete something in between, or any particular line, you can run the command like this that will remove this line instead of the entire ACL itself...

  Standard note of access-list (config) #ip

  (config-std-nacl) #no 3

  This configuration lines will remove the third line only (which is to allow the 192.168.1.0 0.0.0.255, leaving the other statements)

  regds

• bug in iOS? startup-config + command access-list + an invalid entry detected

  I posted this yesterday in the newsgroup usenet comp.dcom.sys.cisco and received no nibbles. If I did something incredibly stupid, please do not hesitate to advise.

  Cisco 827

  IOS (TM) C820 software (C820-K9OSY6-M), Version 12.2 (8) T5, RELEASE

  SOFTWARE (fc1)

  I'm looking to use a host named in a more extended access list. The

  script I copy startup-config contains the following entries:

  ! the 2 following lines appear at the top of the script

  123.123.123.123 IP name-server 123.123.123.124

  IP domain-lookup

  ! the following line appears at the bottom of the script

  120 allow host passports - 01.mx.aol.com one ip access-list

  When I reboot the router, I saw the following message:

  Translation of "passports - 01.mx.aol.com"... the domain server (255.255.255.255)

  120 allow host passports - 01.mx.aol.com one ip access-list

  ^

  Invalid entry % detected at ' ^' marker.

  It seems as if the entrance to the server name of the router is not processed

  prior to the access list. I can not even check with

  router02 access lists 120 #sh

  makes the access list entry * not * exist.

  But when I manually type the entry in the router I see the

  Next:

  router02 (config) #access - list 120 permits Passport - 01.mx.aol.com ip host

  any

  Translation of "passports - 01.mx.aol.com"... the domain server (123.123.123.123)

  [OK]

  and I can confirm its creation:

  router02 access lists 120 #sh

  Extend the 120 IP access list

  allow the host ip 64.12.137.89 one

  I have to do something incredibly stupid. If necessary I can post the whole startup-config, although it is quite long. (I don't know if the same label/common sense if apply here as apply to newsgroups usenet. i.e. post us actual ip addresses in our configs or must they be edited?)

  Any help is very appreciated.

  Hello

  Currently IOS does not use DNS - names in the ACL for the saved configuration / running.

  When you type in a list of access with a domain name we he looks up and replaces it with the IP address. I remember seeing a bug No. recently request this feature but I don't remember one bug id # now.

  Router (config) #access - list 187 ip allow any host www.cisco.com

  Router (config) #^ Z

  router #show run | 187 Inc

  IP access-list 187 allow any host 198.133.219.25

  router #show worm | split 12

  IOS (TM) C800 Software (C800-K9NOSY6-MW), Version 12.2 (13) T, RELEASE

• DMVPN WILL ACCESS LIST

  Hi, guys

  Could you please help me with this matter?

  When you configure the DMVPN talk-to-spoke with several hubs (GRE IPSEC EIGRP) talked about what traffic should be allowed on the external physical interface on a router?

  !

  IP access-list еxtended CRYPTO-ONLY

  license to esp [IPSEC peers Reomote] [IPSEC peer Local]

  permit of eq isakmp udp [IPSEC peers Reomote] [IPSEC peer Local]

  allow accord [IPSEC peers Reomote] [IPSEC peer Local]

  !

  interface FastEthernet

  IP access-group CRYPTO ONLY in

  !

  If I delete the last line of the access list, where the "free WILL" is permitted, the router never built EIGRP neighbor relationships. If this line should be present? If so, does any not encrypted GRE traffic will come out?

  Thanks in advance,

  Mladen

  Hey Mladen,

  The access list bound to the external interface is checked twice IE before and after decryption. This is why you must allow packets will clear also.

  HTH

  Sangaré

  pls rate helpful messages

• access lists

  I have a question... or two... :) on access lists.

  My current access list looks like the following:

  access-list acl_outbound allow icmp a whole

  acl_outbound list of access allowed tcp 192.168.50.0 255.255.255.0 any eq 80

  acl_outbound list of access allowed tcp 192.168.50.0 255.255.255.0 any eq 21

  acl_outbound list of access allowed tcp 192.168.50.0 255.255.255.0 any eq 22

  acl_outbound list of access allowed tcp 192.168.50.0 255.255.255.0 any eq 8080

  acl_outbound list of access allowed tcp 192.168.50.0 255.255.255.0 any eq 443

  acl_outbound ip access list allow a whole

  access-list acl_inbound allow icmp a whole

  inside_nat0_outbound 192.168.50.0 ip access list allow 255.255.255.0 host Bluff_Outside

  outside_cryptomap_9 192.168.50.0 ip access list allow 255.255.255.0 host Bluff_Outside

  1. I get no response to external IP addresses with my permit icmp echo. I have to specify what type of ICMP traffic as echo response on the end of the statement of license? I assumed not to put a specific function of what ICMP permit would allow all ICMP traffic, but I guess I was wrong.

  2. also suggestions on how to improve my access lists would be appreciated. Just because it might "work" does not mean that it is the best way.

  As I noticed that I had to have the ip permit any one to make it work, but am not sure exactly what is happening when I apply that statement to allow permit tcp statement work correctly.

  My goals are:

  allow hosts listed web traffic (including https and ftp)

  allow ICMP pings pass from the inside to the outside and the response

  allow VPN tunnels to establish

  Thank you all for your help. This forum was very informative and useful with previous posts, I'm sure it will be with this one as well.

  Dave

  The question is now that you have an incomplete encryption card on your PIX, which effectively blocks ALL outgoing traffic. Add the following line:

  > card crypto outside_map 9 match address outside_cryptomap_9

  to your PIX. This should get the traffic flowing again. Although passed by the hit counters your ACL, try to ping the host Bluff_Outside to test your ping? If so, then your config crypto says to encrypt all traffic as well, which probably won't work unless the Bluff is configured correctly. Better to make things as simple as possible while you are testing, then I recommend to take the crypto stuff for now with:

  > no outside_map interface card crypto outside

  Reading through your original post, when you access list only allowing certain protocols TCP, and you found that it did not work, was it web browsing that didn't work? If so, whether you have been reviewed by name rather than IP address, and depending on where your DNS servers, you probably also needed to enable DNS lookups via (udp port 53). MANY people forget this.

  In addition, in my humble OPINION, most of the clients that I have seen that initially only allow certain outgoing protocols, eventually find it's more pain than anything like their users say "I need to use this Protocol" and "I need to use this Protocol. Just be tired if you want to go down this road without a valid reason, you can cause a lot of extra work for yourself. What could be easier is just to make sure that your inside the subnet and only your home subnet, can get out by doing:

  > acl_outbound 192.168.50.0 ip access list allow 255.255.255.0 any

  This limited kind of all other connections rear door inside your network by your PIX and Internet connection, but still allows all your users go out and do what they want. Oh you obviously.

• Levels of security and access lists

  I have DMZ1 (security50) that needs to access DMZ2 (security20). However, for access to the work I need to modify the access list that controls access of DMZ1 inside (Security 100). My understanding is that you only need statements of access list for the access of low to high not top-to-bottom.

  I simply get it wrong?

  Andrew,

  In general what you say is true. That is how the PIX is designed. But, once you apply the acl on the security interface higher than its interior or the demilitarized zone, default behavior is no longer there. In this case, you must allow exclusively the superior traffic lower. So, it's flexibility as security engineer to check our our strictly secure LAN traffic. Although we know that the inside is always fixed, but an acl can be applied to control which traffic is allowed outside or dmz. Your case is a classic example of why you need a lower LCD of higher security interface.

  I hope this helps! Thank you

  Renault

• access-list [line-num]

  Too often, I see in the access list statement, there is a line number set to 1, like this:

  permit access-list id_test 1...

  Desc the doc said: "The line number to insert a note or an access control element (ACE)."

  I can understand his 'writing' but never 'really' understand. :)

  Someone could it explain by giving an example?

  Thank you for helping.

  Scott

  PIX (config) # access-list id_test sh

  id_test list of access; 5 elements

  id_test of access list row 1 will allow any host 1.1.1.1 (hitcnt = 0)

  id_test of access list row 2 allow accord any host 2.2.2.2 (hitcnt = 0)

  id_test of access list row 3 will allow any host 3.3.3.3 (hitcnt = 0)

  line 4 of the id_test of access list allow accord any host 4.4.4.4 (hitcnt = 0)

  access list id_test line 5 will allow any host 5.5.5.5 (hitcnt = 0)

  PIX (config) # access - list id_test line 2 Note Hello

  PIX (config) # access-list id_test sh

  id_test list of access; 5 elements

  id_test of access list row 1 will allow any host 1.1.1.1 (hitcnt = 0)

  Hello from note access-list id_test line 2

  id_test of access list row 3 will allow any host 2.2.2.2 (hitcnt = 0)

  line 4 of the id_test of access list allow accord any host 3.3.3.3 (hitcnt = 0)

  access list id_test line 5 will allow any host 4.4.4.4 (hitcnt = 0)

  id_test of access list line 6 will allow any host 5.5.5.5 (hitcnt = 0)

  allowed for pix (config) # access - list id_test line 1 icmp any host 1.1.1.1

  PIX (config) # access-list id_test sh

  id_test list of access; 6 items

  allowed to Access-list id_test line 1 icmp any host 1.1.1.1 (hitcnt = 0)

  id_test of access list row 2 allow accord any host 1.1.1.1 (hitcnt = 0)

  Note access-list id_test line 3 Hello

  line 4 of the id_test of access list allow accord any host 2.2.2.2 (hitcnt = 0)

  access list id_test line 5 will allow any host 3.3.3.3 (hitcnt = 0)

  id_test of access list line 6 will allow any host 4.4.4.4 (hitcnt = 0)

  access list id_test line 7 will allow any host 5.5.5.5 (hitcnt = 0)

  TRIS-NOC-FW1 (config) #.

  the golden rule of the acl, is that it works in order, from top to bottom. with the line number, you can precisely insert the new entry of acl or note everywhere where you want.

  for example, imagine you have a 200-entry acl, and now you want to allow one host before the other refuse registration. of course you don't want to interrupt the network by UN-apply and reapply the entire acl. in this case, the line number to save life.

• access-list with PAT

  Hi guys,.

  I would like to know if the accesslist with PAT, you can refuse statements. IE reject the order under the access list for the traffic that you do not want to be PATed.

  example:

  access list acl-pat deny ip 10.0.0.1 0.0.0.0 all

  permit access-list acl - pat ip 10.0.0.0 0.0.0.255 any

  If I won't 10.0.0.1 PATed.

  Hello

  It's perfectly legal and quite a common practice.

  Hope that help - rate pls post if it does.

  Paresh

• Cisco ISE and WLC Access-List Design/scalability

  Hello

  I have a scenario that wireless clients are authenticated by the ISE and different ACL is applied depending on the rules in the ISE. The problem I have seen is due to the limitation on the Cisco WLC that limit only 64 input access list. As the installer has only a few IVR/interfaces and several different access lists are applied to the same base on user groups interface; I was wondering if there may be an evolutionary design / approach according to which the access list entries can evolve next to create a vlan for each group of users and apply the access list on the interface of layer 3 instead? I illustrated the configuration below for reference:

  Group of users 1 - apply ACL 1 - on Vlan 1

  User 2 group - apply ACL 2 - on the Vlan 1

  3 user group - apply ACL 3 - on the Vlan 1

  The problem appears only for wireless users, he does not see on wired users as the ACLs can be applied successfully without restriction as to the switches.

  Any suggestion is appreciated.

  Thank you.

  In fact, you have limitations on the side of the switch as well. Long ACL can deplete resources AAGR of the switch. Take a look at this link:

  http://www.Cisco.com/c/en/us/support/docs/switches/Catalyst-3750-series-switches/68461-high-CPU-utilization-cat3750.html

  The new WLCs based on IOS XE and not the old OS Wireless/Aironet will provide the best experience in these matters.

  Overall, I see three ways to overcome your current number:

  1. reduce the ACL by making them less specific

  2 use L3 interfaces on a switch L3 or FW and the ACL is applied to them

  3. use the SGT/SGA

  I hope this helps!

  Thank you for evaluating useful messages!

• A simple (I think) - compensation access list hitcounts

  How can I clear counters hitcnt for access lists? Also a reload...

  These hitcounts (as in "show access-list"):

  access list to the INSIDE of the line 1 permit ip 10.100.10.0 255.255.255.0 host CrazyLarry (hitcnt = 107575)<>

  Thank you.

  This gives a shot:

  access-list aclname Clear counters

  Scott