I know this is somewhat old now, but I wanted to add how I ended up finally fixing this. Originally what I did was create a batch script that was executed when a user logged into the VPN. This batch script would connect to a Windows share on our internal network, copy down a PowerShell script along with the related support files to the users local machine. The batch would then execute the PowerShell script that was downloaded. This worked fine initially and got the desired result. We recently replaced the NAS device this share was hosted on which for whatever reason resulted in certain clients being unable to access the share and thus download the PowerShell script for execution. Some clients have differing AV clients which might block files from being downloaded. Just became too unreliable. I searched for a different way and finally came up with the fix which as it turns out so much less complicated than the way I was originally trying to do this. I ended up configuring the ASA device to use two different scripts for Windows clients when they log in. First I configured one script for use on the ASA, and then configured a second script for use on the ASA for VPN Onconnect execution. So what happens here is that when an AnyConnect client connects to the VPN, the ASA actually automatically downloads two different scripts to the clients local hard drive. One script is just a batch script that just has code in it to execute the second script, which is my PowerShell code. Since the ASA is configured to use two scripts, each one gets downloaded to the local client. No more having to connect to a share to copy the files, potentially exposing passwords or perhaps not being able to download the files needed at all from the share. Whats more, is that the scripts get downloaded anytime they are changed. If you make a change to the scripts, you just re-upload them to the ASA, re-configured the VPN configuration to use them, and your changes get re-downloaded to the client upon connecting to the VPN. Then its just a matter of having the batch script call the PowerShell script in the path it gets downloaded to by the ASA.
I had originally tried this method, and the ASA would download both scripts, but I could never get the PowerShell one to execute. It seemed as though the ASA was confused about which script to execute when there were two of them, or that it was executing the PowerShell script first which would never work because its PowerShell. I tried this again tonight and finally got it to work. The key was uploading the PowerShell code to the ASA first, and then adding the batch script second. Seemed to order the two scripts in such a way as to allow the batch to run first which then will run the PowerShell code. I may have also had the path incorrect when I originally tried this. I forgot that the PowerShell file that gets downloaded has a prefix added to the filename of "Onconnect_". So UserRDP.ps1 becomes "Onconnect_UserRDP.ps1" when its added to the VPN configuration. Its possible it would not work because I was not calling the correct filename with the pre-pended filename in the batch file. Not sure. Anyway its working now.
For anyone else wanting to do this, try the following:
1. Create your PowerShell script
2. Create your batch file. The batch file should just have the following in it:
powershell.exe -ExecutionPolicy Bypass -File "%ALLUSERSPROFILE%\Cisco\Cisco AnyConnect Secure Mobility Client\Script\Onconnect_<PowerShellScriptName>.ps1"
3. Upload both scripts to the ASA flash filesystem
4. Add a new onconnect script for Windows clients to your VPN configuration. Choose the PS script you created in step one. Ignore the warning about the script not being executable and continue importing the script.
5. Add a second Onconnect script to the ASA VPN configuration. This time choose the batch file that you created in step two.
That's it. The ASA should download both scripts locally, and execute the batch script first to then call the locally downloaded PowerShell script. Just wanted to finish this out in case any one else tries to do something similar. HTH.
... View more
i noticed your nat was using UDP on 3389, so you must have a whole bunch of high ports open for voip.
be careful with that,. you might want to look into sip inspection , so the fw can open media ports for RTP dynamically, based on sip signalling, if you run firepower than you can do deeper inspection and allow only if it is indeed RTP traffic and drop when its not
... View more
I gave up here and called TAC. It works the way I thought it did in the first scenario. Each host in the ACL can only accept the number of connections configured in the set connection part of the policy. Thanks.
... View more
I got this to work following this thread:
The last post from Fabian L did the trick. This issue for me was that Split-DNS was working, but using IPv6 for doing lookups for IPv6 hosts outside the tunnel. Anyconnect was simply dropping those packets instead of splitting them out because IPv6 was not enabled in the Anyconnect client. I added IPv6 split tunneling using a bogus IPv6 IP block. This allows the Anyconnect connection to know what IPv6 traffic to split out so that the client can make normal local IPv6 DNS queries and thus allow IPv6 connectivity for IPv6 split tunnel clients. Keeps the Anyconnect client from just dropping all IPv6 traffic which would be needed for clients using native IPv6 with their ISPs. Here are the relevant config additions for reference:
group-policy colo-anyconnect-ras attributes
ipv6-split-tunnel-policy tunnelspecified split-tunnel-network-list value colo-ras-split-tunnel
split-dns value domain.com split-tunnel-all-dns disable address-pools value colo-ras ipv6-address-pools value colo-ras-ipv6
ipv6 local pool colo-ras-ipv6 <ipv6 Address Block Goes Here>/80 100
access-list colo-ras-split-tunnel extended permit ip <IPv6 Address Block/80
So this has the effect of allowing IPv6 traffic to selectively traverse the Anyconnect tunnel based on the access list colo-ras-split-tunnel . Now I don't need IPv6 traffic over the tunnel at all, but since I am specifying what should go over it, this has the side affect of telling Anyconnect what traffic should NOT go over it. Anyconnect then splits the traffic out for IPv6 lookups to the Internet for the Anyconnect clients which use native IPv6. Anyway its all figured out. Hope this helps someone else with the same issue.
... View more
Greetings forum. So I am working on a project that could potentially make use of PVLANs to isolate some hosting servers we are possibly going to bring online in the coming weeks. We currently have Catalyst 4507R switches as the core at our DC running IOS version 15.0(2)SG7. We are using SVIs for Inter-vlan routing on the 4507Rs. We are running VTP version 2 currently. I am trying to lock down some answers with regards to running PVLANs in my environment. Any help here is much appreciated. I have read that to run PVLANs, you need to put your switches in transparent mode before enabling PVLANs. The thing I am not sure on is why. Do they say this because only VTP version 3 supports the synchronization of PVLANs in the VTP domain, and without version 3 your PVLANS will not be propagated, or is there an another reason to put your switches in transparent other than this. I understand that without v3 I would have to manually configure the PVLANS on my switches that would needs them. Just trying to understand if thats the reason they say to put VTP in transparent mode before implementing PVLANS or if there is something else to it I am missing. Can I run PVLANs using VTPv2 and manually configure the PVLANs on the switches that need them? Secondly, in order to switch to using VTPv3 from VTPv2, are there any gotchas I need to be aware of. I have two VTP servers in my VTP domain. I understand VTPv3 works differently with regards to VTP updates. When I change to version 3, will the current VLAN Database be overwritten causing me to loose my current VLANs, or will the current VLANs stay as is while I go about switching all my switches to VTPv3. Would like to avoid wiping out my network if possible. Third, I have a VMWare ESX setup. These new hosts will be VM servers. We do not have a license to support the Distributed VSwitch which allows PVLAN support for ESX VMs. These VMs are running on a Dell M1000e chassis with Cisco WS-CBS3130G-S switches in it. They have limited support for PVLANs. We have VLAN trunk uplinked to our core switches from these blade switches, and then trunk to the VMWare standard switch so we can control VLAN placement of the VLAN hosts. Looks like this: 4507R---------------->WS-CBS3130G-S----------->VMWareStandardSwitch--------->VMWare Guests Trunk Trunk Access I believe there is some way to set up using PVLANs using a setup like this. I think using an isolated PVLAN trunk port. The Blade switch does not seem to support that feature (running 12.2(40)EX1). This is said to be the desired practice when you have upstream switches which do not support PVLANs. Since my VMWare switch does not support them, but the switch linking the core to the vswitch does somewhat I am trying to understand the issues that would be seen there. Again lots if questions. Any help would be much appreciated.
... View more
Greetings to the forum. Let me start by admitting I am way behind here on deploying IPv6. I tried to get this moving last year but other projects were in front. Now its being requested so I am starting on a deployment plan for our network. I would like some general guidance on the use of some of the standard IPv4 tools and how to implement them with IPv6 versions. I have been doing significant amount of reading on the subject and am trying to nail down some best practices with regards to deploying IPv6. First a little background. We have two sites: A collocated DC with most of our servers and networking gear and an office site connected via redundant 200Mbps Ethernet L3 links. At each site we have twin Core switches (4507R at colo site and 3750E series at the office). Using the typical multi-vlan for traffic segmentation at each site, with VLAN interfaces using HSRPv1. We use OSPF as our IGP (single area). We do not have any EGP as we just default route out of Cisco ASA's to our providers at each site (each site has its own Internet connection). The ASAs at the colo serve VPN connections for remote users and I redistribute the VPN host routes into OSPF for the VPN clients connectivity to our office site over VPN. The firewalls at each site also inject their default routes into OSPF. We use typical DHCP relay on the vlan interfaces. So we want to continue supporting IPv4 and will run both IPv6 and v4 dual stack. I have a /48 IPv6 allocation from our Colo provider. So again would like some guidance on the best way to deploy IPv6. Specifics are as follows: 1. I have read that OSPFv3 is required to support IPv6. Should I run my existing OSPFv2 for existing v4 routing and run OSPFv3 for v6 or just run OSPFv3 for both using the address family feature 2. My switches all with the IP Services license or the Enterprise Services (4507R) do not seem to be able to do the OSPFv3 Address Families (router ospfv3 1 address-family ipv4)to use the same OSPF version for both protocols. I could not find any reference to the Address Families in the feature navigator for these switches. Anyone know if this is available for these. 3. We need to use HSRPv2 to support IPv6. I think v2 uses a different Multicast Address. Can I just add the command 'version 2' in the HSRP config without affecting my current v4 HSRP configurations and then add another HSRP group for the v6 addressing? Could it be that simple? 4. The issue of v6 NAT still seems to be hotly debated. I like NAT for what it can do for you when it comes to renumber time, not so much for any sort of security mechanism. Since we are at a colo a renumber is never out of the realm of possibility. I was going to roll with no NAT but just would like to get comments from others about what they think. I am just not sure either way. 5. My provider gave me a small allocation for the outside interface of my ASA. What I was going to do was not run NAT between the outside and inside interfaces, assign an IP out of my routed v6 allocation to the INSIDE interface, default route to the provider gear via the outside interface and small v6 allocation network, and then place an outside v6 ACL on the outside interface. Hosts on the inside interface would connect to the Internet using their assigned address from my v6 allocation and there would be no NAT. Does anyone see any reason this would not work? I am using v4 NAT so was wondering if it would be an issue to run NAT for v4 but not for v6? As always thanks in advance for your help.
... View more
Hmm, I'm not positive but I see what you're asking. If I understand correctly how the certificates work, it's actually the "cn" (common name) value on the certificate that's be compared to the FQDN the client browsed to. Usually the cn is the same as the device hostname. It doesn't have to be though. cn could be the user-friendly name and hostname could be the name useful to the IT team. Since your certificate cn is * (wildcard), it seems to me if your DNS record (or local hosts file) maps cn.yourcompany.com to your ASAs outside address and the ASA has the certificate *.yourcompany.com installed it might work OK. It's worth a try.
... View more
Hi, Was thinking about the same thing as you with regards to the order of NAT/ACL depending on where the connection is coming from. Notice my example though, Traffic from LAN to WAN first gets checked against ACL and local IP address is used as source then we see the Dynamic PAT translations that translates the source to a public IP address. Finally we see the ACL check of the ACL attached to the WAN interface in outbound direction. Again the traffic still matches the real IP address even though we have seen the Dynamic PAT getting applied. So there is clearly something else with the NAT/ACL ordering as one would expect to allow outbound traffic on the WAN interface to already be source from a public IP address. There are some things that are a bit unclear as Cisco doesn't really share specific enough information about the ASA operation. So some things just seem to work in a certain way yet you dont really know how to explain why they work the way they do. I agree with regards to "packet-tracer". Its a great tool. I think every Cisco device should have it to help determine problem with the traffic forwarding - Jouni
... View more
Anyone......I have a hard time believing this has never come up before. I know the Barracuda devices can do this somehow. Again, I am not at all familiar with Ironport gear so I am at a disadvantage here. Any help would be great. Thanks.
... View more
OK I was able to get this going last night. The key was just to add the vpn-addr-assign aaa command. Then it worked great. The only thing thats missing now is that its not setting the net mask correctly. The mask is part of the local pool config and I am not sure in IAS how I can set it. Perhaps a RADIUS attribute of some sort. One issue I did not mention is that I am using OSPF on this PIX and its redistributing the /32 routes for the VPN IP assignments throughout my network so that VPN hosts can get around. This still works correctly even when assigning the address via AAA. So the bottom line is that the tunnel group assigns the address for local if configured with a local pool but can be overridden by setting an IP in the user properties in Active Directory. For those who care in the future about doing this, here is the relevant config I have that makes it work: tunnel-group ras type remote-access tunnel-group ras general-attributes address-pool colo-ras authentication-server-group RADIUS LOCAL default-group-policy colo-ras password-management tunnel-group ras ipsec-attributes pre-shared-key * group-policy colo-ras internal group-policy colo-ras attributes vpn-idle-timeout 30 vpn-tunnel-protocol IPSec pfs enable split-tunnel-policy tunnelspecified split-tunnel-network-list value colo-ras-split-tunnel default-domain value altn.int ip local pool colo-ras 10.20.90.129-10.20.90.157 mask 255.255.255.224 vpn-addr-assign aaa vpn-addr-assign local Thanks for the help.
... View more
Thanks for the reply. Its not leading to a border router. All traffic is internal over this link. Each site has its own border. After posting this I realized that I have other SVIs with ACLs that work properly when sending traffic over this P2P link. This has to be something with this particular ACL. I'll just have to look deeper to see what it is. Again, thanks for the reply.
... View more