Unable to send data over a site-to-site VPN.

[sinfantino]

Good morning!

I am at my wits end and am hoping someone here can help me out.

I have two ASAs at different sites that I am trying to set up a site-to-site VPN between.  I only want a specific subnet to be able to connect from site A to site B, and I (think I've) set everything up for that.  The site A ASA has several different site-to-site VPN connections already which are working fine; however, with the VPN to site B, the VPN establishes but does not allow data to pass over the connection.  Both ASAs show TX traffic (that number increases as I mash the 'refresh' button in frustrated hope that it will start working watch it), but there is no RX traffic on either end (and pings from computers at either site just time out).  I have tried everything I can think to try short of restarting the ASAs (these are in use and there's not really a good time to do that, so am trying to avoid that if I can); I'm sure it's something simple that I'm missing but I haven't been able to find it.

The ASA at site A is running older software - ASA version 8.2(5) than the ASA at site B - ASA version 9.1(6)6, but I could not find any warnings about the two being incompatible.  I have noticed the ASA at site B is set up with multiple VLANs, which appears to be an option only for the 9.1 versions (or at least later than 8.2); I did not set it up and thought it was weird all the ports were in access mode, but I'm not sure that's a problem (and am pretty sure fiddling with those would bring everything down, so I'd like a second opinion that the VLANs are the problem before doing that).

I'm attaching sanitized copies of the configs - as mentioned the Site A ASA has other VPN connections; the link is coming up between the two firewalls so I don't think it's relevant, but if necessary I've tagged the public IPs of Site A and Site B in the configs (if it doesn't have that then it's for one of the other connections).

Thank you in advance for your help!

[evilcreamsicle]

From what I can tell, your sdf asa group-policy has your tunnel protocol set to ikev1, but on the colo side you aren't, so that could be something.

also your sdf asa is attempting to use your colo public IP as an endpoint, but that endpoint device appears to be a router on the outside of the ASA rather than the ASA itself, is that correct?

I'm using ASAs as the true endpoint at both sites, one running 9.2 and one running 8.2.
...sanitizing then i'll post the relevant parts of my working config.

[evilcreamsicle]

OK here is a sample of my working config.

At a second look, it looks like your colo ASA does have a public IP assigned to it, but it seems to be routing all of your 10.4.0.0 traffic through your colo router instead of directly out its public interface.

name 10.1.5.253 Colo-R description Colo Router

route Inside-Route 10.4.0.0 255.255.0.0 10.1.5.253 1

when you are creating your tunnel on your sdf asa, are you pointing it at the colo router public IP, or the colo ASA public IP?

EDIT: Didn't upload site a config... oops

[sinfantino]

Thanks very much for taking a look at this!

The SDF ASA is pointing at the Colo ASA public IP.  I'm double checking but I didn't think that router even had a public IP (might be something leftover from a different setup).

I spent a while banging my head on the ikev1 vs isakmp without getting anywhere - I was going forward on the assumption that the 9.2 version just translates the isakmp command into ikev1 (our startup config on the SDF ASA just has the isakmp line, and when I clear all the VPN information out and readded it using isakmp (NOT ikev1) then did 'show run' the line came back as ikev1.

Thank you very much for those examples - I'm going through them now; it helps a lot just knowing for sure that it *can* work between the two versions.

[evilcreamsicle]

Yeah it works flawlessly for me.

If your tunnel endpoint is the colo ASA public IP, i'd look at this route statement in your config:

route Inside-Route 10.4.0.0 255.255.0.0 10.1.5.253 1

From what I can tell from your tunnel configuration, the local IP you're trying to route to your SDF site is 10.4.4.128, and would be affected by that route.

It is possible that return traffic is being sent to [and probably dropped by] the colo router at 10.1.5.253. Is that router on the inside of the ASA then? Is that where that traffic is supposed to go?

[sinfantino]

Oops that's probably the problem... the local IP at the SDF site is 10.122.x.x; the 10.4.4.128 is behind the CoLo ASA.

From what I can tell though the tunnel should be set up that way (but I've been staring at it so long that everything's running together)/it doesn't look backwards anywhere.  Do you remember what was set up the wrong way (with it pointing 10.4.4.128 traffic to SDF/Site B)?

[evilcreamsicle]

on the colo ASA, it looks like it is sending traffic bound for 10.4.0.0 through 10.1.5.253, which is why I was asking. That would happen to any traffic arriving at the colo ASA destined for a 10.4.0.0 device.

That configuration might be correct, but only if the device at 10.1.5.253 is between 10.4.0.0 and your colo ASA. That was why I was asking.

if you run 'show crypto ipsec sa' what does it show for traffic over the tunnel?

[sinfantino]

Oh; I misunderstood then.  ^^;  The router/10.1.5.253 is between the two.

I had to generate some traffic from the SDF side but here's the results:

Colo/Site A (just for this VPN):

interface: Outside-Route
Crypto map tag: outside_map, seq num: 6, local addr: <redacted-PublicIP-SiteA>

access-list Outside-Route_6_cryptomap extended permit ip 10.4.4.128 255.255.255.128 10.122.80.0 255.255.255.0
local ident (addr/mask/prot/port): (10.4.4.128/255.255.255.128/0/0)
remote ident (addr/mask/prot/port): (10.122.80.0/255.255.255.0/0/0)
current_peer: <redacted-PublicIP-SiteB>

#pkts encaps: 11, #pkts encrypt: 11, #pkts digest: 11
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 11, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0

local crypto endpt.: <redacted-PublicIP-SiteA>, remote crypto endpt.: <redacted-PublicIP-SiteB>

path mtu 1500, ipsec overhead 74, media mtu 1500
current outbound spi: D0D5D381
current inbound spi : B40B6913

inbound esp sas:
spi: 0xB40B6913 (3020646675)
transform: esp-aes-256 esp-md5-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, }
slot: 0, conn_id: 4182016, crypto-map: outside_map
sa timing: remaining key lifetime (kB/sec): (4374000/27601)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
outbound esp sas:
spi: 0xD0D5D381 (3503674241)
transform: esp-aes-256 esp-md5-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, }
slot: 0, conn_id: 4182016, crypto-map: outside_map
sa timing: remaining key lifetime (kB/sec): (4373998/27601)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001

SDF/Site B:

interface: outside
Crypto map tag: outside_map, seq num: 1, local addr: <redacted-PublicIP-SiteB>

access-list outside_25_cryptomap extended permit ip 10.122.80.0 255.255.255.0 10.4.4.128 255.255.255.128
local ident (addr/mask/prot/port): (10.122.80.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (RCS-IS/255.255.255.128/0/0)
current_peer: <redacted-PublicIP-SiteA>

#pkts encaps: 1, #pkts encrypt: 1, #pkts digest: 1
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 1, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#send errors: 0, #recv errors: 0

local crypto endpt.: <redacted-PublicIP-SiteB>/0, remote crypto endpt.: <redacted-PublicIP-SiteA>/0
path mtu 1500, ipsec overhead 74(44), media mtu 1500
PMTU time remaining (sec): 0, DF policy: copy-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: B40B6913
current inbound spi : D0D5D381

inbound esp sas:
spi: 0xD0D5D381 (3503674241)
transform: esp-aes-256 esp-md5-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
slot: 0, conn_id: 15671296, crypto-map: outside_map
sa timing: remaining key lifetime (kB/sec): (3915000/27704)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
outbound esp sas:
spi: 0xB40B6913 (3020646675)
transform: esp-aes-256 esp-md5-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
slot: 0, conn_id: 15671296, crypto-map: outside_map
sa timing: remaining key lifetime (kB/sec): (3914999/27704)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001

[evilcreamsicle]

have you tried adding ikev1 to the tunnel protocol in your group-policy on colo ASA?

[sinfantino]

As far as I can tell there isn't a way to do that/it already is added - I'm not 100% sure on this, but it seems like the 'Enable IPSec' option in the asdm/the ipsec line in the config on the 8.2 version is the same as the ikev1 option/config line in the 9.iforgot version.

I'll double check tomorrow though - my shift just ended and I don't have access to the ASAs anymore.

Thank you again for your help on this - I've been working on it for a week now and it's been driving me bonkers.

[sinfantino]

I went through and looked for a way to add ikev1 to the group policy; I can't find a way either in ASDM or the CLI.  I found an 'ipsec-udp' command but that didn't do anything one way or the other.

I've done some ikev1? exploring in the colo ASA's cli and it doesn't seem to have options for it, at least not where the later version has them (there's no crypto ipsec ikev1, for instance).