About mpgioia

Yes..  I was going to say that .. because client is sending SYN's again with seq=0 and never updating. Checking... ... View more

There.. Following a stream end to end.   ... View more

The NAT's are getting to the server... I can see it in wireshark on the endpoint..   There's a mess of ip checksum mismatch's and ACK number mismatches.. Probably assymetry going on..   ... View more

Yes.. can hit the services on the servers fine inside... Hyper-V.. quite sure.. don't have access to the underlying Hyper-V solution.. just the guest.. but can see Hyper-V NDIS bindings everywhere in the network settings so assume they are virtual and Hyper-V is the virt solution. ... View more

Static. default vr. to tunnel interface.       From the 192.168.75.15 host (near end) below.     ... View more

omg.. I think the 'decapsulated inner packet' is coming through on Cisco ASA as IPv6 ?!   Look at the log line at the end.. truncated off..  But the first parameter appears to be in IPv6 format ?   ... View more

Infact I just posted template Syslog output (or should I say.. all I received was the template syslog output from the rep on the other side..) i'll get the actual output/log line to see what the translated inner packet is. ... View more

This is ridiculous.. and appreciate the pipe in @TranceforLife. Yes, incrementing enc/dec packets. And check this out.. when I run a PCAP,  and filter right down to a source of a /32 and a destination of a /32 (near and far end), all 4 stages of what it can pcap.. I literally get no files created when I try to, like, http/https browse.  Nothing. I start my ping off to the dest.. bang files created.. 😕   If it helps, at least on the far end/Cisco side I get a repeating,   ---------------------------------------------------------------------------------------------------------------------------------------------------------- IPSEC: The decapsulated inner packet doesn't match the negotiated policy in the SA.   The packet specifies its destination as pkt_daddr its source as pkt_saddr, and its protocol as pkt_prot. The SA specifies its local proxy as id_daddr/id_dmask/id_dprot/id_dport and its remote proxy as id_saddr/id_smask/id_sprot/id_sport. ---------------------------------------------------------------------------------------------------------------------------------------------------------- ... View more

@Brandon_Wertz wrote: Sorry about that I copied a URL from "page 2" apparently that doesn't work:   http://www.pcworld.com/article/2047513/fragging-wonderful-the-truth-about-defragging-your-ssd.html    The URL had a '%C2%A0' suffixed at the end.  Drop that off and it will work. ... View more

@chris.russell wrote: Yeah, thats why i recommended sourcing pings from something other than whatever interface its pinging from now.   Educate me here. ... what do you mean by this ? 🙂 Right now, I'm on a near end proxy-id/policy source address.. (like an actual machine in this subnet.. remotely) pinging to proxy-id/policy destination address (this I'm not on remotely.. but have been told in confidence by far end representative it's there and live.. obviously..)   See.. now i'm stressing again that it's my side again if 'Session Start' is ticked in logging on my policy and I don't see my traffic-half/side on the way to the far end.. when I technicaly should right ? ... View more

@AXI_IIEN_Remo wrote: You could also enable "Session Start" log so you will also see logs for not established sessions.   But as you describe this setup, and when you don't see any encryption/decryption errors I would also definately check the other side (make someone check the other side). Maybe the other side has access-lists in place which only allow icmp?   What you could still check is the system log, if the ASA tries to setup a new phase 2 tunnel for tcp traffic while sending only icmp to the existing one. Not really likely but a while ago I had a cisco-router admin who somhow managed to configure his router to setup different phase 2 tunnels for every source/destination/port constellation.   With the routing I think you're absolutely right. If there is a routing problem also icmp would fail.   Yeh am logging at Session Start and End. Don't see nothing.. I'll check the other side.. Thanks guys. ... View more

I agree....Traffic logging only appears when session established. So any furfy of not seeing at least my TCP SYN's/my side of the traffic getting over I shouldn't get hung up on.. because the session is not established.. that's why I'm not seeing any traffic. ( I originally.. .erroneously .. was getting hung up on why I couldn't see at my TCP leg making it's way over in the traffic logs.. but no session.. that's why )   I've gone through my config on near side to death.. I think it is the other side.   But then... ICMP gets there and back.. so if it was fundamental routing.. even ICMP wouldn't get there ? ... View more