My experience is only an ASA, but you could try exporting the trustpoint in pkcs12 format, which should contain both the cert and private keys: crypto ca export trustpoint pkcs12 passphrase -trustpoint being the trustpoint name -passphrase being a password you want to use to protect the output with The ASA should output the base64-encoded pkcs12 file to the terminal screen, and you can copy/paste into notepad. When you want to import back into the same or different firewall just use the 'import' command: crypto ca import trustpoint pkcs12 passphrase The trustpoint name doesn't have to be the same as the one you exported. You'll paste in the pkcs12 output you just copied. I believe if you've deleted the trustpoint you'll also lose the associated keys. Not 100% on that though. You can't recover the keys from the chain cert. Hope this is what you're looking for. - James ... View more

Is the traffic being caught by an ACL higher up in the order? If your traffic flow not matching the ACL? You might try moving this particular ACL higher up to see if hit counts start to increase. Good luck! James ... View more

I'm sorta surprised that the firewall let you put in an ACL with a non-pairing IP/mask ( 192.168.100.2 255.255.255.252). When you specify the subnet mask the IP must be the network IP not a 'host' IP, unless the mask is /32. You might try the following: acl servers_in line 1 extended permit tcp host 192.168.100.2 host 10.83.0.2 eq 443 acl servers_in line 2 extended permit tcp host 192.168.100.2 host 10.83.0.2 eq 445 acl servers_in line 3 extended deny ip host 192.168.100.2 any acl servers_in line 4 extended permit tcp host 192.168.100.10 host 10.83.0.10 eq 25 acl servers_in line 5 extended permit tcp host 192.168.100.10 host 10.83.0.11 eq 80 acl servers_in line 6 extended deny ip host 192.168.100.10 any acl servers_in line 7 extended permit ip 192.168.100.0 255.255.255.0 any Good luck! James ... View more

I agree about making sure your source IP falls within the encryption domain and nonat acl. Looking over your config, if your source IP comes from 192.168.148.0/30 there's no reason it shouldn't work. You may want to make sure there isn't some sort of policy NAT or PAT configured to use 192.168.150.231 on the other end when sending traffic to 10.210.12.25. Check out the no-nat ACL's on the other end as well. Good luck! James ... View more

You should be able to implement Policy NAT on the 2nd Pix 501 to accomplish what it is you're trying to do. Policy NAT Access List: access-list policy-nat-acl extended permit ip 192.168.1.0 255.255.255.0 192.168.3.0 255.255.255.0 Static NAT: static (inside,outside) 172.16.1.0 access-list policy-nat-acl *Make sure the above static statement is above any other 1 to 1 statics statements, you may have to remove and add them back to make this happen* Modify your encryption domain on the Pix: access-list 200 extended permit ip 172.16.1.0 255.255.255.0 192.168.3.0 255.255.255.0 Modify the encryption domain on the ASA: access-list 200 extended permit ip 192.168.3.0 255.255.255.0 172.16.1.0 255.255.255.0 There will be a one-to-one mapping for clients behind this Pix 501. If Server A behind the Pix @ 192.168.1.2 generates traffic to 192.168.3.2 behind the ASA, it will appear to that client as 172.16.1.2. Clients behind the ASA will need to use the 172.16.1.x addresses to contact clients behind that Pix 501. If you're hairpinning the VPNs on the ASA you'll use 172.16.1.0/24 in all of the no-nat ACL's and encryption domains to represent that new Pix. Hope this helps! James ... View more

Are your intranet sites hosted on the DMZ servers that have static NAT entires in your config? If so, you might try implementing DNS doctoring on the static NATs by adding 'dns' to the end of the NAT entry. You'll have to remove the static NATs and re-add them with 'dns' tacked on, then clear the xlate. If you're using domain names to resolve the IPs for your intranet sites the ASA will rewrite the DNS response with the internal 192.168 IP instead of the public IP. Ought to work if you're able to access the DMZ servers (and sites) with their private IPs. You may also try adding an access list rule permitting the 192.168.200.0/24 network to hit the public IPs of your DMZ servers as a test as well. Good luck! James ... View more

Hello, After thinking this over, I think you can implement both vpn-session-timeout and vpn-access-hours within your group policy to mostly do what you want. For example: Find out what timezone your ASA is using, and compare it to your own: ciscoasa# sh clock 04:51:35.439 UTC Fri Dec 4 2009 (aka. 10:51 PM CST) Implement the time-range in global config mode using 'time-range rangename' ciscoasa(config)# time-range my-vpn-restriction ciscoasa(config-time-range)# periodic daily 04:00 to 05:00 ciscoasa(config)# group-policy rack-test attributes ciscoasa(config-group-policy)# vpn-access-hours value my-vpn-restriction The time range of 04:00 to 05:00 permits VPN access between the hours of 10:00 PM to 11:00 PM CST. You apply this time-range within the group policy you want to affect. Any client VPN connection made during this time will live past the end time so long as the idle timeout is not exceeded. So, if a client connects at 10:59 PM they will be permitted to use the VPN for as long as they need to despite exceeding the VPN access time. The way to work around this is to implement a VPN session timeout value within the group policy as well. ciscoasa(config)# group-policy rack-test attributes ciscoasa(config-group-policy)# vpn-access-hours value vpn-restriction ciscoasa(config-group-policy)# vpn-session-timeout 30 The 30 signifies the number of minutes the VPN connection will stay alive before the ASA resets the connection. <1-35791394> is the number of minutes that can be set. After the session timeout period has been exceeded, the client VPN software will alert the user that the VPN connection has been terminated, at which point they can reconnect. If it falls within access hours, great. Otherwise, the client must wait until the appropriate time to reconnect. So in the above example, if the user connects to the VPN at 10:59 PM their session will last 30 minutes and end at 11:29 PM. Any reconnection attempt will result in the password box continuously being presented as if they had invalid credentials. The caveat with this method is that normal VPN connections during business hours will also be disconnected every 30 minutes, creating a possible inconvenience for your users. Hope that helps! James ... View more

Thanks for the new info. In my previous comment I was looking at it from an outbound client perspective, thus my question about dynamic nat. In the case of the xlate timeout, it is used for both static and dynamic NAT. I doubt that's the issue here though. There is a connection timeout setting on the ASA -- timeout conn 1:00:00 -- that defaults to one hour. A connection reset after only 3 minutes seems strange. If you wouldn't mind posting a sanitized config here maybe someone can shed some light on it. ... View more

Yeah, I understand what it is you're trying to do, but unfortunately I don't think there's any way to do it fully on the CSS. The idea is that the sorryserver would store some sort of static content, like a 'server down' or 'ongoing maintenance' page, that clients would be directed to incase the primary service failed. Once the primary service comes alive all *new* connections would be directed to the primary service, while existing connections to the sorry server could A) continue to be mapped to the sorry server until the entry in the persistence table expired or B) be remapped to the now-up primary service. The only way I can think to implement what you want would require something like this: - Turn on logging - Configure an email address on the CSS that logs can be sent to - Ensure the keepalive method is 'get' for the primary service When the state transition states place for the primary service (ALIVE to DEAD/DOWN), it is recorded in the traplog. Once this is emailed to the customer, there can be logic on their end that will change the contents of the healthcheck file on the primary server if it sees the primary service on the CSS failed. The primary service will then continue to fail its keepalives due to a hash mismatch and would require the customer to manually change the healthcheck file to bring the server back into rotation. I know it sounds a little far fetched, but perhaps it can be done. I've seen variants of this method implemented so it might be worth looking at. Good luck! James ... View more