I've recently started peering with a remote office that is running a Fortigate 100A (4.0 code) to my ASA 5540 running 8.2 code. The tunnel between us is setup as a ipsec-l2l with psk. The ASA config looks something like this: tunnel-group 22.214.171.124 type ipsec-l2l
tunnel-group 126.96.36.199 ipsec-attributes
pre-shared-key ***** crypto map remote-vpn 120 match address remote_office_2
crypto map remote-vpn 120 set peer 188.8.131.52
crypto map remote-vpn 120 set transform-set ESP-3DES-SHA
crypto map remote-vpn 120 set reverse-route access-list remote_office_2 extended permit ip 10.0.0.0 255.255.255.0 172.16.1.0 255.255.255.0 So as you can see, this is pretty much a basic IPSEC L2L. Now for the issue/strangeness that I am seeing. I have seen a few cases where on the Fortigate side, if I add a new Phase 2 in the configuration, for say 172.16.2.0/24 to 10.0.0.0/24 , the ASA would actually go out and build the Phase 2 SA on it's side without the configuration every being added. One would think that the ASA would reject the Phase 2 because it's not defined in the remote_office_2 access-list, but it doesn't. I confirmed that the Phase 2 on the ASA is built by using the "show vpn-session db detail l2l filter name 184.108.40.206" command. I would see something like: IPsec: Tunnel ID : 1332.2 Local Addr : 10.0.0.0/255.255.255.0/0/0 Remote Addr : 172.16.1.0/255.255.255.0/0/0 Encryption : 3DES Hashing : SHA1 Encapsulation: Tunnel Rekey Int (T): 28800 Seconds Rekey Left(T): 28788 Seconds Idle Time Out: 0 Minutes Idle TO Left : 0 Minutes Bytes Tx : 26885 Bytes Rx : 24246 Pkts Tx : 114 Pkts Rx : 110 IPsec: Tunnel ID : 1332.3 Local Addr : 10.0.0.0/255.255.255.0/0/0 Remote Addr : 172.16.2.0/255.255.255.0/0/0 Encryption : 3DES Hashing : SHA1 Encapsulation: Tunnel Rekey Int (T): 28800 Seconds Rekey Left(T): 28794 Seconds Idle Time Out: 0 Minutes Idle TO Left : 0 Minutes Bytes Tx : 64609 Bytes Rx : 53554 Pkts Tx : 102 Pkts Rx : 102 Is this normal behavior for the ASA to create these undefined Phase 2 SA? Is there a way to prevent this from happening? I'm just trying to avoid any issues where an incorrect SA is built and could cause an outage. Thanks!
... View more
We use the RSA server to backend our user authentication for our Anyconnect home VPN users. There have been requests to have some of our home users have static IP addresses while on the Anyconnect. I have not been able to find a working example on how to get this to work while using SDI (RSA) authentication. I have a generic /23 for my user VPN network, let's say 10.1.0.0/23 and I would like to perhaps maintain a block of 32 addresses for the purpose of static assignment. Currently my address assignment is done on the ASA itself through a local pool. The basic flow of what I'm looking to do is: StaticUser1 connects and is assigned 10.1.0.1 DynamicUser1 connects and is assigned 10.1.0.33 If a user does not have a static ip address assignment, they will be issued an IP from the local pool. I guess I'm stumped in figuring out how to get the static IP address assigned to the users that need it, while maintaining the SDI/RSA authentication for all the users. Any help would be appreciated.
... View more
Thanks, DAP does seem to be the way to go with this. I found a similar article to what you posted last night which confirmed the same type of screenshots. I will just have to set time aside to update my policies on my ASA to take advantage of this. I guess as a best practice in the future, I need to make sure I update the DfltAccessPolicy to Terminate from the start, because I have a number of production services on my ASA which could be effected if I do change it now. Thanks! Jeff
... View more
I can't seem to find any documentation to how to get this working. I'm trying to make it so that only users of a certain AD group are authenticated for my Anyconnect VPN on my ASA 8.2.2 I've found the documentation on how to prevent logins using the msNPAllowDialin attribute, but not how to base it on group membership (memberOf) This is what I have configured: ldap attribute-map AllowVPN
map-name memberOf IETF-Radius-Class
map-value memberOf "CN=VPN Users,OU=Groups,OU=City,OU=Country,DC=us,DC=mydom,DC=net" TESTGROUP aaa-server ADAUTH (inside) host 10.1.1.1
ldap-attribute-map AllowVPN Do I need to do any kind of restrictions inside the actual group-policy TESTGROUP ?
... View more
I've seen a few discussions about this, but I've not been able to find an answer as to why this keeps failing. I have a Centos 5.5 server that I use for configuration file management and I have been unable to get my 6509E to send the configuration using the CISCO-CONFIG-COPY-MIB. Here is the shell script I'm using for testing: #!/bin/bash RAND=$1; shift snmpset -On -v2c -c private 10.2.154.30 .220.127.116.11.18.104.22.168.22.214.171.124.4.2.$RAND i 1 .126.96.36.199.188.8.131.52.184.108.40.206.4.3.$RAND i 4 .220.127.116.11.18.104.22.168.22.214.171.124.4.4.$RAND i 1 .126.96.36.199.188.8.131.52.184.108.40.206.4.5.$RAND a "10.2.153.4" .220.127.116.11.18.104.22.168.22.214.171.124.4.6.$RAND s "Router.cfg" .126.96.36.199.188.8.131.52.184.108.40.206.4.14.$RAND i 4 snmpwalk -On -v2c -c private 10.2.154.30 .220.127.116.11.18.104.22.168.22.214.171.124.4.10.$RAND I've also tried adding " .126.96.36.199.188.8.131.52.184.108.40.206.4.14.$RAND i 6 " to the beginning of the snmpset command, even though I know the random # that I'm using is unique. This is the output I get from running the shell command: # ./x.sh `od -vAn -N2 -tu4 < /dev/urandom` 8176 Error in packet. Reason: noCreation (That table does not support row creation or that object can not ever be created) Failed object: .220.127.116.11.18.104.22.168.22.214.171.124.4.14.8176 .126.96.36.199.188.8.131.52.184.108.40.206.4.10.8176 = No Such Object available on this agent at this OID And this is the output of debug snmp on the 6509: Nov 7 13:33:13 EDT: SNMP: Packet sent via UDP to 10.2.153.4 Nov 7 13:33:14 EDT: SNMP: Packet received via UDP from 10.2.153.4 on Vlan50 Nov 7 13:33:14 EDT: SNMP: Set request, reqid 763539692, errstat 0, erridx 0 ciscoConfigCopyMIB.10.2.153.4.14.8176 = 6 ciscoConfigCopyMIB.10.2.153.4.2.8176 = 1 ciscoConfigCopyMIB.10.2.153.4.3.8176 = 4 ciscoConfigCopyMIB.10.2.153.4.4.8176 = 1 ciscoConfigCopyMIB.10.2.153.4.5.8176 = 10.2.153.4 ciscoConfigCopyMIB.10.2.153.4.6.8176 = Router.cfg ciscoConfigCopyMIB.10.2.153.4.14.8176 = 4 Nov 7 13:33:14 EDT: SNMP: Response, reqid 763539692, errstat 11, erridx 1 ciscoConfigCopyMIB.10.2.153.4.14.8176 = 6 ciscoConfigCopyMIB.10.2.153.4.2.8176 = 1 ciscoConfigCopyMIB.10.2.153.4.3.8176 = 4 ciscoConfigCopyMIB.10.2.153.4.4.8176 = 1 ciscoConfigCopyMIB.10.2.153.4.5.8176 = 10.2.153.4 ciscoConfigCopyMIB.10.2.153.4.6.8176 = Router.cfg ciscoConfigCopyMIB.10.2.153.4.14.8176 = 4 Nov 7 13:33:14 EDT: SNMP: Packet sent via UDP to 10.2.153.4 Nov 7 13:33:14 EDT: SNMP: Packet received via UDP from 10.2.153.4 on Vlan50 Nov 7 13:33:14 EDT: SNMP: Get-next request, reqid 1919913490, errstat 0, erridx 0 ciscoConfigCopyMIB.10.2.153.4.10.8176 = NULL TYPE/VALUE Nov 7 13:33:14 EDT: SNMP: Response, reqid 1919913490, errstat 0, erridx 0 cseL2StatsEntry.1.3021 = 2037843887 Nov 7 13:33:14 EDT: SNMP: Packet sent via UDP to 10.2.153.4 Nov 7 13:33:14 EDT: SNMP: Packet received via UDP from 10.2.153.4 on Vlan50 Nov 7 13:33:14 EDT: SNMP: Get request, reqid 1919913491, errstat 0, erridx 0 ciscoConfigCopyMIB.10.2.153.4.10.8176 = NULL TYPE/VALUE Nov 7 13:33:14 EDT: SNMP: Response, reqid 1919913491, errstat 0, erridx 0 ciscoConfigCopyMIB.10.2.153.4.10.8176 = NO_SUCH_OBJECT_EXCEPTION Nov 7 13:33:14 EDT: SNMP: Packet sent via UDP to 10.2.153.4 6509 software version is: Version 12.2(33)SXI4 Any ideas where to go from here?
... View more
Just a follow up. While the correct eventID does work, one issue that i've found is that when a user resumes a connection, they tend to get a new IP address from the pool and this is not logged. The actual log line looks something like this: %ASA-6-725003: SSL client outside:x.x.x.x/59510 request to resume previous session. I do see a log line with the eventID as: ASA-4-113019 which is almost what I am looking for. Just it doesn't include the assigned IP address: %ASA-4-113019: Group = GROUPNAME, Username = myusername, IP = 220.127.116.11, Session disconnected. Session Type: SSL, Duration: 0h:30m:34s, Bytes xmt: 1908538, Bytes rcv: 14370, Reason: Idle Timeout Thanks for all your help on this, I'll just have to look towards other methods to try and correlate the logs.
... View more
Thanks. The 722# ones apply to the SVC stuff as well. Unfortunately, it's still limited in it's usefulness. While it does show the userID connected, it shows the external IP address associated with it. I still can't seem to find a way to correlate the active SVC connection for the user to the assigned IP address from the pool. I guess it would be nice to have a line something like: user SVC connection terminated. P-IP 18.104.22.168 A-IP 10.1.1.1 duration 3:30:15 xmit 45456464 recv 35343242 Sort of like a summary line. Another big issue with the logging is that when a user resumes the connection, it doesn't specifiy the userID , just the Public IP, so you would have to dig back into logs to try and figure out who that public IP belongs to. At the end of the day, just knowing who had what assigned IP at a given time is what really matters. I'll poke around to see if I can find any DHCP/IP pool related logging. Update: I found this entry, but it doesn't seem to apply to SVC/WebVPN: Error Message %ASA-6-713228: Group = group, Username = uname, IP = remote_IP_address
Assigned private IP address assigned_private_IP to remote user Explanation This message is generated when IKE obtains an address for the client private IP address from DHCP or from the address pool. The message specifies the IP address assigned to the client. • group—The name of the group • uname—The name of the user • remote_IP_address—The IP address of the remote client • assigned_private_IP—The client IP address assigned by DHCP or from the local address pool
... View more
I would like to know if it is possible to setup my ASA running 8.2 to log events from when my users log on and off the anyconnect client. There was a security issue with one of our remote systems and it has been impossible to try and determine who had that IP address during that time. The IP Pool is defined on the ASA as well, so it would be nice to have the following information: userID connected userID disconnected IP address associated with connection Currently I have my logging set up as follows: logging enable
logging console debugging
logging monitor debugging
logging buffered debugging
logging trap informational
logging history informational
logging asdm informational
logging queue 3170
logging host inside 10.1.1.1
no logging message 106006
no logging message 710005 Thanks!
... View more
Consistently I see similar errors like this in my logs. The src address is actually my SCCM server (policy server) and the dst address is a remote VPN user who connects with the AnyConnect client. %ASA-4-419002: Duplicate TCP SYN from inside:10.2.152.69/2974 to inside:10.2.252.230/139 with different initial sequence number %ASA-4-419002: Duplicate TCP SYN from inside:10.2.152.69/2973 to inside:10.2.252.230/445 with different initial sequence number I'd like to try and clean up these errors if possible. Any ideas on what can be done to try and see what the cause of these are? Thanks
... View more
I've been running this on some client 1811 routers with success. Here is a basic config that should work: !! I use a delay on the up/down to prevent some flapping issues that could arise. track 11 ip sla 11 reachability default-state up delay down 90 up 120 !! Primary ISP interface FastEthernet0 ip address 192.168.1.2 255.255.255.0 !! Secondary ISP / Backup interface FastEthernet1 ip address 172.16.1.2 255.255.255.0 !! Main default route is tracked and primary ISP is preferred ip route 0.0.0.0 0.0.0.0 192.168.1.1 track 11 !! Backup ISP has a floating static metric of 250, will only be used if SLA fails ip route 0.0.0.0 0.0.0.0 172.16.1.1 250 !! Note 10.1.1.1 is the endpoint my clients try to connect to (my side) ip sla 11 icmp-echo 10.1.1.1 source-interface FastEthernet0 frequency 30 ip sla schedule 11 life forever start-time now !! Access list to permit only icmp for SLA check access-list 199 permit icmp any host 10.1.1.1 echo !! Local routing policy to make sure SLA check always goes out primary ISP interface route-map FAILOVER permit 10 match ip address 199 set ip next-hop 192.168.1.1 !! Ties route map to local routing policy ip local policy route-map FAILOVER I prefer to ping something I'm trying to reach remotely, but you could ping the next hop as well (just as long as you can be sure that would be the reason for an outage). I found that in most cases, a problem would exist after the next hop (ISP gateway) so the SLA would never work.
... View more
Thanks for the response. I originally thought about doing that but the issue there is, that IP address will pretty much always be up. The next hop is an ISP ethernet handoff, so connectivity to that IP address will be up 99% of the time (unless that ISP link dies completely). Sorry I didn't illustrate that in my earlier post. Generally, it's the 1811 (10.1.1.2) -> (10.1.1.1) ISP gateway router -> INTERNET -> My ISP Gateway devices -> My ASA cluster (192.168.1.1) I was curious more then not why it seemed the SLA pretty much just stopped working all together, which I think even if I was tracking the next hop, would have happened regardless. Thanks
... View more
I have a Cisco 1811 router that has 2 ISP connections coming into it for VPN redundancy. I've noticed that over the last few weeks, the SLA which tracks the default gateway to the primary ISP has been failing, even though the SLA should be returning an OK status. The SLA seems to stay active for a few runs before stating there is No Connection, thus making it so the backup ISP is the preferred default route and the VPN endpoint comes up, leaving 2 QM_IDLE sessions on the router. Here is a bit of the config: crypto logging session ! crypto isakmp policy 10 encr 3des hash md5 authentication pre-share group 5 crypto isakmp key MYKEY address 192.168.1.1 ! crypto ipsec security-association lifetime seconds 86400 ! crypto ipsec transform-set tunnelset esp-3des esp-md5-hmac no crypto ipsec nat-transparency udp-encaps ! crypto map VPNMAP 10 ipsec-isakmp set peer 192.168.1.1 set transform-set tunnelset match address 101 ! ! track 10 ip sla 10 reachability delay down 10 up 30 interface FastEthernet1 description !!! Primary ISP !!! ip address 10.1.1.2 255.255.255.0 ip nat outside crypto map VPNMAP ! interface FastEthernet2 switchport access vlan 899 ! interface Vlan899 description !!! Secondary ISP !!! ip address 172.16.1.2 255.255.255.248 ip nat outside crypto map VPNMAP ! ip local policy route-map FAILOVER ! ip sla 10 icmp-echo 192.168.1.1 ! ip sla schedule 10 life forever start-time now ! access-list 199 permit icmp any host 192.168.1.1 echo ! route-map FAILOVER permit 10 match ip address 199 set ip next-hop 10.1.1.1 ! ip route 0.0.0.0 0.0.0.0 10.1.1.1 track 10 ip route 0.0.0.0 0.0.0.0 172.16.1.1 250 ! And now the issue: #show track 10 Track 10 IP SLA 10 reachability Reachability is Down 54 changes, last change 00:58:48 Delay up 30 secs, down 10 secs Latest operation return code: No connection Tracked by: STATIC-IP-ROUTING 0 #show ip sla statistics IPSLAs Latest Operation Statistics IPSLA operation id: 10 Type of operation: icmp-echo Latest RTT: NoConnection/Busy/Timeout Latest operation start time: *14:43:48.581 EDT Wed Sep 15 2010 Latest operation return code: No connection Number of successes: 0 Number of failures: 52 Operation time to live: Forever #show ip route Gateway of last resort is 172.16.1.1 to network 0.0.0.0 #ping 192.168.1.1 source fa1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds: Packet sent with a source address of 10.1.1.2 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 60/69/80 ms #show crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id status 192.168.1.1 172.16.1.2 QM_IDLE 2099 ACTIVE 10.1.1.2 192.168.1.1 QM_IDLE 2098 ACTIVE #show route-map FAILOVER route-map FAILOVER, permit, sequence 10 Match clauses: ip address (access-lists): 199 Set clauses: ip next-hop 10.1.1.1 Policy routing matches: 110156 packets, 7051604 bytes #show access-lists 199 Extended IP access list 199 10 permit icmp any host 192.168.1.1 echo (110157 matches) When I add a static route for the primary ISP with a distance of 10 (ip route 0.0.0.0 0.0.0.0 10.1.1.1 10) the IP SLA recovers and the secondary VPN conn-id (172.16.1.2) gets removed from the crypto. Is there anything missing from the configuration that would cause this? Or are there any useful debugging commands to see why the SLA seems to fail, even though I can ping the remote host just fine while it says it's unreachable?
... View more
I have the following configuration setup: Cisco 1811 (Client Router) Fa0 - Internal Network 192.168.0.0/24 Fa1 - Primary ISP connection, we'll call it 22.214.171.124 Fa2 - Vlan 800 Vlan 800 - Secondary ISP connection, we'll call it 126.96.36.199 ASA 5580 running 8.2 Outside interface we'll call 188.8.131.52 crypto map 5 set peer 184.108.40.206 220.127.116.11 crypto map 5 match address test_network I have a tunnel-group defined for both 18.104.22.168 and 22.214.171.124 Now for the issue. I have the 1811 setup with SLA tracking. I use a default route-map to make sure that the ICMP goes out of Fa1 at all times and I track the default route with this. I have a floating weighted 250 default route pointing to the backup ISP. While both networks are reachable, I can create the tunnel using the primary ISP to 126.96.36.199 (from 188.8.131.52). I can ping across the tunnel without issue. I can then simulate an outage of the primary ISP and the secondary route will kick in. I ping across the tunnel again, and on the ASA I can see a new ISAKMP connection has been established. Looking on the 1811, I see (2) QM_IDLE isakmp connections. While the primary link is down, I can still ping across the tunnel without issue. The primary isakmp session on the 1811 never drops off but on the ASA it does in fact get removed. The ASA only has an established connection to 184.108.40.206. Once the primary link recovers and the default route is back out the primary ISP connection, the tunnel never recovers. The ASA appears to think that the secondary ISP is the active connection still and the routing doesn't work across the tunnel because the 1811 is trying to send data out the primary ISP. Is there a way to do the following: - When the primary ISP goes down on the 1811, the established tunnel is dropped - When the primary ISP comes back up on the 1811, the ASA can re-establish the connection using the primary link (or the backup tunnel on the 1811 is disconnected)? Is this even possible to do on a single router (2 ISP links) or can it only be done using 2 routers? Let me know if I need to explain a bit better or if any configuration details are needed. Thanks! Jeff
... View more
I have a vpn-filter set on my L2L policy. The remote site uses a Cisco 1811 router and the main hub is a Cisco 5580. I already have a vpn-filter acl in place on an existing L2L connection that works fine. The only issue is, when I make changes to the acl to add/remove access, I have to reload the entire tunnel before the changes take place. My question is, is there a command to reload the access control without dropping the tunnel?
... View more