ACL interface or subinterface

Similar Questions

• Treatment of ACL interface...

  For this question, let me first series, the scenario...

  Applied to the external interface - ACL_out SMTP allows all IP addresses.

  ACL_dmz applied to the dmz interface - SMTP allows only some certain machines in the DMZ (implicit deny statement at the end of list).

  The STATIC controls have been set up for all machines in the DMZ.

  A package of SMTP from the outside would be able to go to any machine in the DMZ (do not take into account if the host is listening on port 25), or only those specified by the STATIC commands?

  Basically, my question is whether once a package passes an ACL on an interface (for example, apart from the interface), is the package again treated to the next interface (for example, the perimeter network or inside interface), or what is once the package passes one of the interfaces, it is sent to its destination regardless of ACL applied on interfaces on which the package runs?

  Thank you.

  If the package passes through the external interface in the demilitarized zone, the ACL applied to the DMZ interface has no effect.

  When a package arrives first in the int outdoors, the ACL applied to the external interface is checked (using the static method) and if the packet is permitted, the PIX creates a connection for her entry. Return on this connection (inheriting from the DMZ interface) packets are allowed to proceed without any thorough ACL check.

  It's exactly the same thing to say, a package inside out to the Internet, you do not have to apply an ACL to the external interface allowing these back, cause a connection was created.

  If you want to restrict what hosts/ports DMZ people on the outside can reach, can do you this with you (dmz, outside) static and your ACL applied to the external interface. The ACL applied on the DMZ interface is really only for connections on the DMZ interface, which probably isn't going to be something else.

• ASA "route inside 0 0 192.168.1.1 by tunnel" interface ACL question

  Hello

  Small question around the road inside 0.0.0.0 0.0.0.0 192.168.1.2 in tunnel command.

  Do you need to add a u-turn traffic within the ACL interfaces (for example internet related http traffic) or 'same-security-traffic permit intra-interface' negates the need of this?

  So if my site remote vpn outside is 10.1.1.0/24 should I add entering permitted statements for the 10.1.1.0/24 inside my interface.

  Thank you

  same-security-traffic permit intra-interface allows then-input-output traffic on a single interface

  allowed incoming 10.1.1.0/24 statement in the list ACL allows traffic (output - then-) penetration on a single interface, but you must disable the RPF check

• Amount of the ACLs on an interface of the PIX

  Hi all

  I just wanted to know how much group-access entry (s) that you can attached to a 515ER PIX interface? I wonder if it's the same rule as the router, IE 1 ACL/interface/direction. En thank you your help.

  Hi Vincent,.

  You can apply to a single group-access on any pix interface... is not like in a router in a router, you can apply groups of incoming/outgoing access... On a pix you can apply only inbound access-groups...

  I hope this helps... all the best...

  REDA

• ACL IPSEC - CRYPTO vs Interface

  Hello

  Where an IOS device is connected to a PIX 6.3, with a VPN IPSec site to site with ipsec connection allowed sysopt

  Thinking that it would be simpler to apply the required ACL, I created the ACL crypto to the entire subnet with the thought I would create ACL interface for nailing to specific hosts inside the subnet.  I see now that I need to disable the connection of sysopt permit-ipsec for the ACL interface to apply.

  1. is it more common for crypto ACL to be more host specific vs specific subnet and the necessary ACL ONLY (with the active sysopt)? I have a true Swiss cheese of the armies on either side of the vpn that need access and I didn't want to maintain such a complicated in meaning OPPOSITE ACL.

  2 or it is more common for both - crypto ACL (allow a simpler ACL) then apply ACL interface?

  3. I see the issue with the realization of the interface & crypto ACL, there is more that can get sent THEN denied to the remote interface, or even blocked traffic on the local side.  If the ACL interface should be used, what is the best practice here?

  4. I see the interface that acl work when sysopt allowed ipsec connection is enabled, but only on outbound traffic. Is it because traffic has not struck the crypto ACL again?

  Any pointers in the right direction would be appreciated.

  Thank you

  Dan Foxley

  Dan

  Much depends on whether the VPN device also acts as a firewall. If this isn't ie. Once the traffic has been decrypted, it is then passed on the firewall then allowed sysopt of active ipsec connection is a logical choice.

  In response to your questions, speak from my personal experience-

  (1) crypto ACL tend to be more subnet than host-based, but it depends on your specific needs.

  (2) Yes, in general the crypto acl is more general, the acl interface is where you attach.

  (3) don't know, I followed. If you want to limit this subnet traffic is sent through the tunnel then you would with an acl interface but on a different interface IE. the interface more near the source of the traffic.

  (4) it is to do with the order of treatment IE. which is done first. Not really used an acl outgoing on the same interface as endpoint vpn but I suspect you're right.

  Note that you do not need to apply the acl on the actual interface the VPN ends, at least with the code v7.x and beyond. You can terminate the VPN on the external interface, and then use an outbound acl on the interface that is sent unencrypted traffic. Yes, that means he has to go through the firewall, but it can make the management of your ACLs easier.

  Jon

• ACL LocalFW Vs pushed Firesight ACL

  Hi guys

  If we have a strategy pushed Firesight to ASA network and it has a local policy on the interface, which would override?

  Also is there a way we could check on the SAA what policy he received from Firesight?

  How do you push a policy to the Firesight ASA?

  Do you mean that you have a policy thrust to the firepower of the ASA service module?

  In this case, these are quite different things. The ASA evaluates the passage of the ACL interface occupants when the package is presented to the interface. The service module evaluates the flow against its policies when it receives the package from the ASA parent under the policy-map.

  Is not one or the other, is both and the net result is their cumulative policy when it is applied in the series (as a Boolean 'AND' logical).

  See this link for a picture:

  https://CCIE-or-null.NET/2014/12/10/packet-flow-with-firepower/

• Multi-tenant IOS Firewall and security even subinterfaces 9.0

  Hi all

  I'm so used to< 8.3="" and="" am="" having="" great="" difficulty="" getting="" an="" environment="" working="" properly="" so="" i'm="" now="" going="" to="" leverage="" the="" cisco="">

  We set up a network with clients behind a pair of 5510 s.  All of these clients will have their own dedicated sous-interface in their own VLAN.  Out the door, I got inter - allowed security-same interface and all networks communicate with each other.  I certainly don't want that, so I have disabled this command and now each network client is unable to communicate with each other, as expected.

  The problem now lies in networks where a customer have 2 VLANS separated (say a staging and a prod environment) where they need to communicate.  Is it feasible if they are of the same security level and even security allowed inter-interface is disabled?  I just need to create an ACL for the networks to talk?  Is there a better way to do this with the same security allowed active inter-interface?

  8.3 pre, I have same security allowed active inter-interface, but traffic could not speak to the other interface unless I created an exemption NAT and ACLs.  Always create a NAT exemption?

  Hello

  The basic problem that you run with different software levels is the parameter 'nat-control' that exists in 8.2 (or earlier version), but does not exist in version 8.3 (or subsequent version of the Software ASA).

  In the 8.2 and pre software you got with the nat configuration change 'control' of requiring a connection to have a NAT configuration to be able to pass traffic through the ASA. Of course this coupled with the 'security level' gave you more changes to control traffic without resorting to the ACL.

  However, in the new software of 8.3 and later the "nat-control" level no longer exists and that a connection has a NAT configuration that be applied or not ASA still allows the connection (subject other ASA controls allow) so basically you won't need NAT configurations between your local interface. The most common NAT configurations should be between your local interface and the "external" ASA interface.

  If you try to control traffic between interfaces with the global configuration commands you mention, you will eventually be 'juggling' with the 'security level' configurations autour constantly so that the correct rules for traffic is applied.

  This question came up on these forums every now and then, and I almost always offer the same approach which is to set up an ACL on EACH interface of the ASA.

  • Remember to leave the 'same-security-traffic"on the SAA configurations. It is because even if you have interface ACL allowing traffic, if they are for some reason any left with identical "security level"custom ACL be sufficient to allow the traffic. "
  • Configure each interface an ACL
  • Initially to configure the ACL to create a "object-group" that will contain EACH network behind your local interface of firewall (except the "outside" ofcourse)
  • Use this category 'object' at THE start of ACL interface to BLOCK ALL traffic behind this interface to these networks
  • After that allow or block different/Out Internet - linked as usual traffic
  • In the same networks 2 (or more) behind the need of different interfaces to communicate with each other, set up a statement that allows early each ACL. The already existing 'decline' exposed with the 'object' group already will ensure that other traffic between networks are blocked

  A very simple example, you might want to consider the following

  Networks:

  • LAN1: 10.10.10.0/24
  • LAN2: 10.10.20.0/24
  • DMZ1: 192.168.100.0/24
  • DMZ2: 192.168.200.0/24

  permit same-security-traffic inter-interface

  Interface GigabitEthernet0/0

  Description box

  interface GigabitEthernet0/0.10

  VLAN 10

  nameif LAN1

  security-level 100

  IP 10.10.10.1 255.255.255.0

  interface GigabitEthernet0/0.20

  VLAN 20

  nameif LAN2

  security-level 100

  IP 10.10.20.1 255.255.255.0

  interface GigabitEthernet0/0.100

  VLAN 100

  nameif DMZ1

  security-level 100

  IP 192.168.100.1 address 255.255.255.0

  interface GigabitEthernet0/0,200

  VLAN 200

  nameif DMZ2

  security-level 100

  192.168.200.1 IP address 255.255.255.0

  object-group network BLOCK-LOCAL-NETWORKS

  object-network 10.10.10.0 255.255.255.0

  object-network 10.10.20.0 255.255.255.0

  object-network 192.168.10.0 255.255.255.0

  object-network 192.168.20.0 255.255.255.0

  access-list LAN1 - IN note allow HTTP / HTTPS in the DMZ1 Server

  access-list LAN1 - permit tcp 10.10.10.0 255.255.0 host 192.168.100.100 eq www

  access-list LAN1 - permit tcp 10.10.10.0 255.255.0 host 192.168.100.100 eq https

  LAN1-IN access-list note block traffic to another local network

  access-list LAN1 - deny ip any object-group NETWORK-LOCAL-BLOCK

  Note LAN1-IN access list allows any outbound

  access-list IN LAN1 ip 10.10.10.0 allow 255.255.255.0 any

  LAN1-IN group access to the LAN1 interface

  And of course all other ACL would follow the same model in one form or another. You would really have to worry about traffic is allowed between interfaces, but rather the most work would probably add "allowed" in the upper part of each ACL when required for communication inter-interface. But I guess that the amount of these additions would remain also to a manageable level for FW admins.

  Naturally in environments the biggest you would probably get a high-end ASA and virtualize it and separate each customer environment in their own security context where you would avoid this situation together. Naturally the biggest points against this solution usually can be fresh and the fact that virtualize the ASA multiple context mode disables some essential operational capability of the SAA, which the most important is probably the Client VPN connections (VPN L2L is supported in the software in multiple context Mode 9.x)

  Hope this helps

  Don't forget to mark the reply as the answer if it answered your question. And/or useful response rates

  Request more if needed

  -Jouni

• ASA - same-security-traffic allowed inter VS permit/deny access-list interface

  Hi people,

  I wonder if I use the same-security-traffic permits inter-interface order to ASA and I have 2 separate interfaces with the same level of security and ACL with a few rules explicit allow , if not covered by these statements to allow traffic will be blocked by implicit deny at the end of the ACL or am I completely wrong in my thinking?

  That is right.

  But then if you have an interface with an ACL and another interface without an ACL and you want to pass traffic between the two interfaces, then the interface without an ACL will rely on the level of security while configured with the ACL interface will rely on configured ACL entries.

  --

  Please do not forget to select a correct answer and rate useful posts

• Command control interface

  I just installed an ASA with an AIP-SSM-20 version 5.1. I have several subinterfaces on Physics G0/0, which is be the control on the SPI interface. However, when I try to add this interface as interface monitors, I get "error: Interface GigabitEthernet0/0 is already assigned as an interface of promicuous, as part of a pair of inline or is the control interface.» What does that mean? I have configured my ASA to send traffic out a subinterface G0/0, but I don't see any indication that it works.

  The confusion here is that there are 2 interfaces GigabitEthernet0/0.

  The ASA has a GigabitEthernet0/0 and the SSM has completely separated GigabitEthernet0/0.

  GigabitEthernet0/0 of the SSM is the external interface of the SSM itself map. That's where command and control IP of the SSM is assigned. DFS cannot monitor this interface.

  GigabitEthernet0/0 of the SAA is you have subinterfaces on.

  Here are 2 separate interfaces.

  You cannot add Gig of the SSM 0/0 to a sensor virtual because the sensor is not able to control it is command and control external interface.

  You cannot add Gig of the ASA 0/0 with a virtual sensor because you can't add ASA ALL interface to a virtual sensor. This is how you configure not followed to the SSM.

  The only ONE that can be monitored by the SSM is Gig 0/1 interface of the SSM.

  BUT as you cannot confuse the SSM Gig Gig of the ASA and 0/0 0/0. You must also not confuse Gig of the SSM Gig of the ASA and 0/1 0/1.

  Concert of the 0/1 SSM's backplane of the SAA.

  Concert of the SAA 0/1 is the second external port of the SAA itself.

  By placing the SSM 0/1 Gig in virtual sensor that you say the SSM to monitor all Gig of the SSM 0/1 packages that are coming from the ASA backplane.

  To monitor traffic, you need to configure ASA to send packets to the SSM to montioring (aka send them at the bottom of the basket of the ASA so then Gig0/1 of DFS will see them.

  Then, how send you traffic to the ASA to the SSM?

  Through policies.

  You create a class, and in the policy of this class, you use one of the following configuration lines.

  IPS inline

  or

  IPS promiscuity

  You then apply the policy at the global level for the whole of the ASA context, or more specifically to one or more interfaces (or subinterfaces) ASA context.

  Here is an example of how implementing a policy to send traffic to the SSM for monitoring:

  http://www.Cisco.com/en/us/products/ps6120/products_configuration_example09186a00807335ca.shtml

• IPS/ACL/ZBF precedence on router IOS

  I have a number of 891 routers deployed for VPN connectivity to a central site. Routers have an ACL so focused on the area of firewall and IPS/IPS configured on their public interfaces. They run IOS universal 15.1.1. They have been for more than six months.

  Last week I started having newspapers like that of the instance of IPS:

  Jan 12 09:51:21 ss260 378: Jan 12 15:51:20.551: % 4-IPS-SIGNATURE: Sig:3041 Subsig:0 SEV:100 package of TCP SYN/DEF [Source that I can't identify me - MY-ROUTER:25-> IP - IP:25] VRF: NONE RiskRating:100

  I know that the ACL interface is processed before the ZBF. I was assuming that IPS happens after the ACL as well, but this package should never have gotten past my ACL. The ACL only allows ESP, IKE, SSH and pings and then only if they are from about a half dozen source IPs. The source of the trigger package is NOT among those permitted.

  Because my ACL does not all traffic not encrypted (with the exception of the pings I generate), I really didn't expect the instance of IPS to see whatever it is likely to trigger an alert, and until last week, it was true.

  So far, all the newspapers are for the same signature SYN/DEF. It is a type of special cases for some reason signature any or can I wait to see alerts whenever a packet that will block anyway, the ACL matches a signature?

  Hello

  First of all, I noticed that packages fell by IPS have the port source and destination 25 - weird ;-)

  If you are interested in the operation with new code CEF order you can check 'show cef interface INTERFACE_NAME IFC_NUMBER', it is reliable and in order, they are done, but perhaps more detail you need ;-)

  Router#sh cef interface fa0/0
  
  FastEthernet0/0 is down (if_number 4)
  
    Corresponding hwidb fast_if_number 4
  
    Corresponding hwidb firstsw->if_number 4
  
    Internet address is 10.1.1.1/24
  
    ICMP redirects are always sent
  
    Per packet load-sharing is disabled
  
    IP unicast RPF check is disabled
  
    Input features: Access List
  
    Output features: Firewall (NAT), Firewall (inspect)
  
    Inbound access list is 101
  
    Outbound access list is not set
  
    IP policy routing is disabled
  
    BGP based policy accounting on input is disabled
  
    BGP based policy accounting on output is disabled
  
    Hardware idb is FastEthernet0/0
  
    Fast switching type 1, interface type 18
  
    IP CEF switching enabled
  
    IP CEF switching turbo vector
  
    IP CEF turbo switching turbo vector
  
    IP prefix lookup IPv4 mtrie 8-8-8-8 optimized
  
    Input fast flags 0x1, Output fast flags 0x0
  
    ifindex 3(3)
  
    Slot  Slot unit 0 VC -1
  
    Transmit limit accumulator 0x0 (0x0)
  
    IP MTU 1500
  
  

  HTH,

  Marcin

• In/Out ACL by VPN on SAA

  Is it possible to do it on an ASA? I don't understand how a router can do a better job with control of asymmetric flow as an ASA.

  168 VPN ipsec-isakmp crypto map
  LongRidge-CareOne-CUST Site-to-Site Description
  defined by peer 108.170.125.242
  ip access-group VPNCryptoMap168_in-ACL set in
  ip access-group VPNCryptoMap168_out-ACL set on
  game of transformation-AES256_SHA
  match address VPNCryptoMap168-ACL

  IP VPNCryptoMap168-ACL extended access list
  Note CUST-CareOne-LongRidge VPN Site-to-Site
  IP 10.61.0.0 allow 0.0.255.255 172.18.61.0 0.0.0.255
  IP VPNCryptoMap168_in-ACL extended access list
  Note CUST-CareOne-LongRidge VPN Site-to-Site
  allow any object-group CareOne_Somerset_restrict-og-response to icmp echo
  allow any host eq snmp 10.61.23.101 udp
  allow any host 10.61.23.101 eq tftp udp
  allow tcp any a Workbench
  allow any host 10.61.202.88 eq www lpd 5357 5800 and 5900 tcp telnet
  IP VPNCryptoMap168_out-ACL extended access list
  Note CUST-CareOne-LongRidge VPN Site-to-Site
  object-group CareOne_Somerset_restrict-og ip permit any

  Unfortunately, the "vpn-filter option" under the group policy on the Cisco ASA applies only the VPN filter in the incoming direction and automatically configures the outbound direction. Refer to this link. There is an improvement that has been opened to support VPN filters in each direction, but it is not yet applied.

  The only way I see is to modify the default behavior and configure ASA to submit VPN traffic to ACL interface using the command of not sysopt connection VPN-enabled and then configure ACL interface accordingly. I don't know if it's worth to you.

• ACL ASA5540 does not not for VPN access.

  I'm under code 8,03 and have a simple VPN L2L configured between two sites. It is in fact a test config in my lab, but I'm unable to restrict traffic using an ACL inside.

  I used the VPN Wizard to do the config initial and then added an Interior (out) ACL to restrict traffic once the tunnel rises.

  The encryption card is as follows:

  access extensive list ip 164.72.1.128 outside_1_cryptomap allow 255.255.255.240 host SunMed_pc

  Then I have an ACL to limit traffic to ping GHC_laptop, telnet to GHC_switch and denying the rest:

  inside_access_out list extended access allowed icmp host host SunMed_pc GHC_Laptop

  inside_access_out list extended access permit tcp host SunMed_pc host GHC_switch eq telnet

  inside_access_out deny ip extended access list a whole

  However SunMed_pc can also ping at GHC_switch and can FTP to GHC_laptop even if the 3rd entrance to deny any meter increases when I do this.

  I have attached a Word document that has the entire config with a screenshot showing the ACL and the shots.

  Should I configured incorrectly, or is ACL ACL actually does not work as expected?

  You can still keep all the IP for your acl interesting traffic. If you delete the sysopt, then you would write access in your acl 'inside_access' like you did above.

  If you are going to have dozens of tunnels l2l and will limit all, then I just remove the sysopt and use the acl interface.

  There is another option. You can leave the sysopt and use a vpn-filter. It is explained here and can be applied to l2l.

  http://www.Cisco.com/en/us/products/HW/vpndevc/ps2030/products_configuration_example09186a0080641a52.shtml

  http://www.Cisco.com/en/us/docs/security/ASA/asa80/command/reference/uz.html#wp1524559

• ACL and anyconnect ssl vpn

  Hello world

  I was testing the few things at my lab at home.

  PC - running ssl vpn - sw - router - ISP - ASA (anyconnect ssl)

  AnyConnect ssl works very well and I am also able to access the internet.

  I use full tunnel

  I have ACLs on the external interface of the ASA

  1

  True

  any

  any

  intellectual property

  Deny

  0

  By default

  []

  I know that the ACL is used to traffic passing by ASA.

  I need to understand the flow of traffic for internet via ssl vpn access. ?

  Concerning

  MAhesh

  As you correctly say, the ACL interface is not important for that because the VPN traffic is not inspected by the ACL. Of the at least not by default.

  You can control the traffic with a different ACL that is applied to the group policy with the command "vpn-filter". And of course you need a NAT rule that translates your traffic when running to the internet. This rule should work on the pair of interface (outside, outside).

• PIX ACL user downloadable issues

  Recently, I opened a TAC case on an issue that I had with user downloadable ACLs on a radius server. I use the user acl on an intranet pix firewall that protects some servers. We have programmers who need special access for them and tried to have the ACL of assigned dynamically. It turns out that TAC said even if I had the correct ACL and they were applied to the user, I must have the same ACL allowing traffic on the interface which runs incoming traffic. There is no sense to me due to the fact that my goal was to get rid of permanent acl and not have to worry about the use of IP source addresses. I could have just the connection of the user through http and it gets the acl. Then finally the active uauth timer and removes the ACL so do not leave a hole on the PIX. I totally miss the downloadable ACLs goal, so if someone could shed some light on the subject I would appreciate it :) I have that someone has a solution or another solution to the problem that I have please do not hesitate to post! Thanks advance!

  Tony

  For authentication and ACL downloadable works, you need two ACLs on the PIX, the ACL interface and authentication ACL. You can consider the ACL interface as a trigger for the ACL authentication should it allow traffic through to trigger authentication. It must also allow the same traffic that the auth acl which means it is sometimes easier to make more restrictive the more permissive acl interface and the auth acl.

  for example if you have users on 192.168.1.0 24 inside interface and you want to authenticate you to access Terminal Server services, you can if you want to configure the inside access list to allow all traffic to 192.168.1.0/24

  ! inside the 192.168.1.0 auth trigger

  permit 192.168.1.0 ip access list inside_access_in 255.255.255.0 any

  but deny all in the acl of authentication, which means that all traffic required authentication/authorization first.

  ! authentication for 192.168.1.0

  ! don't authenticate DNS and ICMP

  inside_authentication list access deny udp 192.168.1.0 255.255.255.0 any eq 53

  inside_authentication list access deny icmp 192.168.1.0 255.255.255.0 any

  ! authenticate everything.

  permit 192.168.1.0 ip access list inside_authentication 255.255.255.0

  ! apply access lists

  inside_access_in access to the interface inside group

  AAA game inside_authentication inside RADIUS authentication

  Your ACL ACS/RADIUS would be configured to

  ! term serv

  permit tcp 192.168.1.0 255.255.255.0 any eq 3389

  ! http

  permit tcp 192.168.1.0 255.255.255.0 any eq 80

  That would provide the term serv and http access to an authenticated user. Your logs show permission denied for all other access to this user after authentication.

  I hope this helps.

• Site to site VPN ASA2ASA funny crypto ACL behavior

  Hello

  I use a VPN site-to site between two ASAs. It works but it should not work, in my opinion, there is a bug. The thing is that when I set the traffic is encrypted in an ACL, this traffic is denied and the tunnel doen't work. If I remove the ACL entries, I'm really interested in encryption, it works...

  Thus, for example.

  I affermirai a tunnel between the two ASAs and specify

  access allowed extended VPN ip host 172.16.0.60 list 172.20.24.60

  colt_map card crypto 20 matches the VPN address

  card crypto test_map 20 peers set 1.1.1.1
  test_map crypto 20 card value transform-set TEST
  3600 seconds, duration of life card crypto test_map 20 set - the security association
  card crypto test_map 20 set security-association life kilobytes 4608000

  When I have it, there is no traffic allowed between 172.16.0.60 and 172.20.24.60. And when I do:

  VPN access list extended deny ip host 172.16.0.60 172.20.24.60

  access allowed extended VPN ip host 172.16.0.59 list 172.20.24.59

  Can I get a communication between 172.16.0.60 172.20.24.60 of the host, but not between 172.16.0.59 the host 172.20.24.59.

  It seems very weird to me. I was wondering if anyone had this behaviour before or she could explain it?

  Thanks in advance.

  Yes.

  In Janan all traffic VPN is not checked against the external ACL because of a single command: sysopt connection permit VPN

  You can see if this command is enabled by practice: sh run all the sysopt

  If you remove this command: no sysopt permit vpn connection

  then, all VPN traffic is checked against the ACL interface (and you can only allow what you need).

  A better approach is to let the sysopt connection permit-vpn default and create a vpn-filter ACL that is applied to group policy for tunnel groups you need.

  Federico.