I have two networks currently. Network A & B. Network A is a remote location where users connect to B through VPN. Once they establish a tunnel they rdp a terminal server. On this terminal server there are several printers installed. These printers actually live on Network A and are connected to B by a 3002 hardware vpn client. So, a recap, the users vpn in to B and print to printers located on site A. B has a 10.1.1.x network and the printers network is a 10.2.2.x. I added persistent routes on the terminal server so that traffic routes. I know this is a cludgy setup and you are probably asking me why don't we just use split tunneling. GOVT. system so I can't. In any event, this setup works, however, anytime the terminal server reboots are the hardware client loses power the tunnel doesn't fully re-establish. I can see the HW client connected from the concentrator but there is no traffic passsing and I can no longer ping the printers network from the terminal server. Here is where it gets interesting! If I initiate a ping from a printer from site A to the terminal server the pings are answered and I can connect again! It is the weirdest thing! I have all the lastest software. Anyone else experience this??? I know it's unlikely because of the silly arrangement I have on my network but any help would be great. Thanks.
It is the default behaviour not only for PAT mode but for EzVPN altogether. So, the traffic has to be initiated from the client's end so that the IPSEC SA can be built and once it is built, it can be bidirectional.
I was running a PIX 501 tunnel using NEM to my asa 5520 and found that if the network connection was cut in-between then the ASA would not tear down the existing connection (even with keep alives on). I removed the NEM and it was perfect. Just my experience with it.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...