Hello Everyone, I'm looking to configure a stable site-to-site VPN with L2TP Over IPSec feature, to have the possibility to connect two LAN networks as Layer 2 bridge passing through the Layer 3. In this way I can mantain the same addressing on the remote site, and I can share the same VLANs for both sides. I found some kind of configuration, but none which works. Maybe is not possibile to configure this feature on Cisco ASA? Best Regards, Luigi Celeste ... View more

Hi Everyone! I have a problem with our Cisco ASA in our company. The question is quite simple. We have our ASA configured in Active / Standby Failover with redundant links connected at two switches 3750 in HSRP for a better fault tolerance (This information are only for completeness, I don't think this kind of topology can be involved in our problem). They also connects eight brances via VPN L2L.You can see the image attached. Always for a better fault tolerance, we have configured IPSLA between two service providers to ensure continuity when the primary fail. The problem is that, when network traffic is congested toward WAN side (we have a 8Mbit/s HDSL connection) , the primary route it's removed unnecessarily. It remain down just the time for reset the connections, and became up again. During that time, all VPN L2L connections fails and the remote branches have to re-negotiate the tunnels again. For troubleshooting purpose, I've configured syslog messages to an email address for IPSLA and Failover events, and every time the tracked route fail, I receive an email. Also I've configured Netflow to monitor the traffic behavior, and I use NAGIOS to monitor the reachability of our branches Firewalls. In this case, I ping my branches every seconds, end if NAGIOS don't receive a response for 15 seconds consecutively, I receive an email alert. When the ASA's tracked route fail, NAGIOS don't have neither the time to notice that remote branches are go down too that all tunnels have already became up. Below there's my SLA configuration. I check Google DNS every 30 seconds with 20 ICMP packets. No ASA crash are reported. No failover occur. My ASA version is: 9.2(2)   sla monitor 1  type echo protocol ipIcmpEcho 8.8.8.8 interface outside1  num-packets 20  frequency 30 sla monitor schedule 1 life forever start-time now track 1 rtr 1 reachability   Thank's for reply.   Luigi Celeste ... View more

Hi everyone! I've a problem with ASA Remote Access VPN reporting. I would to simply reporting VPN RA connections, when a user login and logoff from the ASA of my company, with a printout of the time that remained connected throughout the day . Simply to say. I've configured then our ASA with syslog directed toward a server who have installed Firewall Analyzer ManageEngine software with the following commands: logging enable logging timestamp logging emblem logging trap informational logging device-id ipaddress inside system logging host inside 192.168.10.10 format emblem All works fine. All the logs are redirected correctly to the server who report correctly the VPN connections. What it does not works is the delay that the ASA take before report a VPN connection. For example (in attachment), if I try to connect my PC at RA VPN through the ASA with Cisco VPN Client with the username "cgigi", and immediately disconnect, the report awaits at least 5 minute before to appear on the screen. different, instead, is if I can try to connect in VPN on my ASA with AnyConnect. In that case, the report immediately appear on the screen when I logout, even if I remained connected only few seconds. All the connections make by old Cisco VPN Client (or IKEv1 protocol) are reported with a delay of at least 5 minutes. This behavior is not good for security purpose, because I need to know exactly when a user has been connected in our network. Also, I would like to separate, changing syslog messages if poissible, the session type "LAN-to-LAN", from the session type "IPSecOverNat" (see raw log), in such a way to have only the "IPSecOverNat" connections reported. Thank's in advance for the support. Luigi Celeste ... View more