Mike, Yes!  I conducted the reload command remotely via the outside interface connection on F ASA. We were able to make the first vpn from N to F, we could see this in the real time log and monitoring VPN sessions ( session showed TX was "0", because it wasn't sending data back to ASA N;  additionally, ASA N was TXing like mad, but not RXing anything). We did run the packet tracker, but we can not remember what it told us now (will do again when we try again). What is most puzzling about this, is that there was not a config change!  This was solely an IOS change and now we don't work.  Roll back and we work as configured.  This makes me think that there is something in the new IOS that is messing our connection up. ... View more

Vinit, You bring up steps that we did accomplish the last time we tried bringing it up.  The logs didn't show us anything!!  (just checked them again, only interfaces going up/down.  May need to adjust logging next time we try).  We were surprised!  Same with controllers. Working on taking the old F 3845 and connecting to the new V3900 in the lab just to see what I get now (it has worked with out a problem in the past).  Will let you know how it turns out. ... View more

Thanks for the quick response. I've attached inventory and config for both boxes.  Keep in mind, F router is on-line right now and V router is not. ... View more

Were you able to have access to the device? yes Were you able to ping the default gateway? If you are talking about F's default gateway, then yes, because I wouldn't be able to get to it otherwise because there is only one connection, the outside interface. Any logs showed up in the console? Good question!  Just looked over our syslog.  Nothing reported other than the reloads dropping the tunnel between F and N. Were you able to ping the ASA from the internal hosts? Wouldn't be able to access F if this was the case. Thank you for such a quick response! ... View more

I have found to problem.  Seems that the VPN filter for a different VPN was interferring with the VPN that I was focused on and the one that I was using to connect to the device. In the end, object group R-NOC-Inside had a object network 192.168.50.0 with in it.  I removed it and sure enough I could connect.  Still working on full testing, but I am pretty sure this is the fix. ... View more

From the outside ASA, I ran packet tracer on the outside interface, icmp, source 10.255.255.1, dest 192.168.50.10.  I receive a packet drop, and the erros is (rpf-violated) Reverse-path verify failed.  I remove the line from the config, and now get dropped packet because of ACL, but it still doen't tell me which acl. I also verified with production system and get same error. ... View more

Additionally, from the CLI I turned on capture for all acl-drop.  I have a ping going from one side of the site-2-site VPN to the other side and it is dropping.  The capture tells me it is dropping because of an ACL.  But doesn't tell me which ACL.  I am using the tunnel-group 65.246.21.12, which uses the group-policy W-NOC for this interface.  the policy does not have a vpn-filter assinged to it.  So now I am digging to try and figure out which ACL is dropping this connectivity. ... View more

I have added the line ssl encryption aes256...... Should I be able to see this line in the config now? Attempted to open asdm from my desktop application, I put in the correct ip address and username and password and get this error message: unable to launch device manager from ip. I have had this error the entire time. ... View more

Do you mean SSL or SSH???? I do a search in my config and don't see SSL.  I have compared to my production unit and also do not see SSL in the config. I do have ssh IP lines in my config. ssh 192.168.50.0 255.255.255.0 inside. Any other suggestions? ... View more

Http lines are in the config. I have confirmed that the asdm.bin is on disk0. Will confirm that there is the ssl line.  More to come later. ... View more

I can tell you that we learned a lot about Multicast in these past 3 weeks and we finally have it running the way we need it to run. First lesson learned is that we did not understand RP correctly in the beginning.   We now understand, RP is just a meeting place and my router in this project, is not the RP, it is the source of the multicast.  Therefore a RP on my router was not needed in our configuration. Second lesson is that in Multicast a tunnel will be dynamically created.  The IP address of that tunnel is important in the passing of the multicast.  In the anomalies that we were seeing last week, the tunnel was taking the outside interface IP which was incorrect.  We have added "ip pim register-source [source interface]"  to always be the inside interface (Vlan 10), and it is working consistently, even after reboots of different equipment and in different order. Below is our config.  It is not the final config as we need to apply some security measures, but for now, we know this works! Again thank you for all  your help and time! ip multicast-routing ip cef no ipv6 cef ! multilink bundle-name authenticated interface FastEthernet0/0 ip address 172.30.255.1 255.240.0.0 ip pim sparse-mode ip nat outside ip virtual-reassembly in duplex auto speed auto interface FastEthernet0/2 switchport access vlan 10 no ip address ! interface FastEthernet0/3 switchport access vlan 10 no ip address interface Vlan10 ip address 10.64.3.3 255.255.0.0 ip pim sparse-mode ip nat inside ip virtual-reassembly in ! router ospf 10 network 10.64.0.0 0.0.255.255 area 0 network 172.16.0.0 0.15.255.255 area 0 ! ip forward-protocol nd ! ! no ip http server no ip http secure-server ip pim register-source Vlan10 ip nat inside source static 10.64.70.1 172.30.0.1 ip nat inside source static 10.64.70.2 172.30.0.2 ip nat inside source static 10.64.70.11 172.30.0.11 ip nat inside source static 10.64.70.12 172.30.0.12 ip nat inside source static 10.64.70.21 172.30.0.21 ip nat inside source static 10.64.70.22 172.30.0.22 ip nat inside source static 10.64.3.1 172.30.3.1 ip nat inside source static 10.64.3.2 172.30.3.2 ip nat inside source static 10.64.3.11 172.30.3.11 ip nat inside source static 10.64.3.12 172.30.3.12 ... View more