site-to-site vpn ignores remote-to-local accesses

lana.deere · ‎02-01-2018

I previously had an ASA5505 with VPN working to a different ASA5505 at another site. My ASA5505 broke I replaced it with an ASA5506, Firepower Thread Defense version (ASA5506-FTP-K9). The web-based Firepower Device Manager is very different from the ASDM I have used previously and I am having trouble setting my VPNs back up. I have configured Internet access successfully and have set up the VPN with NAT disabled and it seems to work fine for traffic originating on my ASA5506. However, traffic which originates on the remote ASA5505 does not get through.

The documentation says:

Ensure that access control rules allow traffic between the protected networks through the VPN interface. This traffic is not allowed automatically. The system decrypts the VPN traffic before evaluating it with the access control policy, so you can apply intrusion prevention, URL filtering, and so forth.

I thought this meant that I needed to go to the Policies > Access Control page and add a rule allowing VPN traffic from the remote site into the local site, so I added a rule with source and destination zones/ports ANY, source network=the remote LAN, destination network=the local LAN. This did not make any apparent difference. The variations on that which I tried also didn't solve the problem.

For what it is worth, I turned on the console logging on the ASA5506 and and found I was getting pairs of messages like these whenever the remote side attempted to access my local LAN:

Jan 31 2018 20:59:14: %ASA-6-302013: Built inbound TCP connection 115517 for outside:10.16.0.85/48897 (10.16.0.85/48897) to inside1_2:10.24.1.24/22 (10.24.1.24/22)

[...unrelated messages...]

Jan 31 2018 20:59:44: %ASA-6-302014: Teardown TCP connection 115517 for outside:10.16.0.85/48897 to inside1_2:10.24.1.24/22 duration 0:00:30 bytes 0 SYN Timeout

That did not suggest anything to me, though.

Any help, suggestions, and/or document pointers would be appreciated.

Rahul Govindan · ‎02-01-2018

The messages seem to say "SYN Timeout", so it looks like the ASA did not receive the SYN ACK for the packet that your sourced from the remote LAN. If you apply a packet capture on the inside1_2 interface, do you see the packets going out and the response coming back in?

lana.deere · ‎02-02-2018

How do I apply a packet capture on an interface? I will try it, but I don't see anything on the web interface's menus which looks like packet capture. I know very little about the CLI.

Rahul Govindan · ‎02-02-2018

You can use the example guide here:
https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/118097-configure-asa-00.html

You would need to go to the FTD CLI and then run the packet capture as you would do for the ASA.

lana.deere · ‎02-05-2018

For the benefit of anyone coming across this thread, to get into the appropriate mode for packet capture connect to the command line interface via the USB cable and terminal emulator software, then:

From cli, run 'system support diagnostic-cli'

> system support diagnostic-cli
Attaching to Diagnostic CLI ... Press 'Ctrl+a then d' to detach.
Type help or '?' for a list of available commands.

firepower>

From diagnostic cli, run 'enable'

firepower> enable
Password:
firepower#

Now the capture command is available.

lana.deere · ‎02-05-2018

I tried setting up capture and now I'm wondering why the interface mention in the original message is inside1_2, and why the packets are captured there when I capture.

firepower# show cap
capture into7 type raw-data interface inside1_7 [Capturing - 0 bytes]
match ip host 10.16.0.85 host 10.24.1.24
capture into8 type raw-data interface inside1_8 [Capturing - 0 bytes]
match ip host 10.16.0.85 host 10.24.1.24
capture into2 type raw-data interface inside1_2 [Capturing - 450 bytes]
match ip host 10.16.0.85 host 10.24.1.24
firepower# show capture into2

60 packets captured

1: 17:31:34.402582 10.16.0.85.45473 > 10.24.1.24.22: S 2339846069:2339846069(0) win 14600 <mss 1380,sackOK,timestamp 2177810237 0,nop,wscale 7>

[rest of packets essentially identical]

There is not anything attached to physical port #2, which as I understand it is the one named inside1_2. The nodes attached to the FTD are connected on physical ports 5-8.

I put a capture on inside1_8, which is connected to the internal host, and it shows things like these:

245: 17:32:05.866120 10.16.0.85.5923 > 10.24.1.24.44436: . ack 3626842614 win 122 <nop,nop,timestamp 2177841700 1120348041>
246: 17:32:05.879959 10.16.0.85.5923 > 10.24.1.24.44436: P 4208455923:4208456341(418) ack 3626842620 win 122 <nop,nop,timestamp 2177841716 1120348057>
247: 17:32:05.880172 10.24.1.24.44436 > 10.16.0.85.5923: . ack 4208450451 win 1260 <nop,nop,timestamp 1120348171 2177841700,nop,nop,sack sack 1 {4208455923:4208456341} >
248: 17:32:05.881393 10.16.0.85.5923 > 10.24.1.24.44436: . 4208450451:4208451819(1368) ack 3626842620 win 122 <nop,nop,timestamp 2177841716 1120348057>
249: 17:32:05.881653 10.16.0.85.5923 > 10.24.1.24.44436: . 4208451819:4208453187(1368) ack 3626842620 win 122 <nop,nop,timestamp 2177841716 1120348057>
250: 17:32:05.881683 10.24.1.24.44436 > 10.16.0.85.5923: . ack 4208451819 win 1250 <nop,nop,timestamp 1120348173 2177841716,nop,nop,sack sack 1 {4208455923:4208456341} >
251: 17:32:05.881942 10.24.1.24.44436 > 10.16.0.85.5923: . ack 4208453187 win 1250 <nop,nop,timestamp 1120348173 2177841716,nop,nop,sack sack 1 {4208455923:4208456341} >
252: 17:32:05.887908 10.16.0.85.5923 > 10.24.1.24.44436: . 4208453187:4208454555(1368) ack 3626842620 win 122 <nop,nop,timestamp 2177841716 1120348057>
253: 17:32:05.888152 10.24.1.24.44436 > 10.16.0.85.5923: . ack 4208454555 win 1250 <nop,nop,timestamp 1120348179 2177841716,nop,nop,sack sack 1 {4208455923:4208456341} >
254: 17:32:05.889236 10.16.0.85.5923 > 10.24.1.24.44436: . 4208454555:4208455923(1368) ack 3626842620 win 122 <nop,nop,timestamp 2177841716 1120348057>
255: 17:32:05.889251 10.16.0.85.5923 > 10.24.1.24.44436: . ack 3626842632 win 122 <nop,nop,timestamp 2177841726 1120348065>
256: 17:32:05.889465 10.24.1.24.44436 > 10.16.0.85.5923: . ack 4208456341 win 1250 <nop,nop,timestamp 1120348180 2177841716>
257: 17:32:05.891265 10.24.1.24.44436 > 10.16.0.85.5923: P 3626842656:3626842666(10) ack 4208456341 win 1260 <nop,nop,timestamp 1120348182 2177841726>
258: 17:32:05.933331 10.16.0.85.5923 > 10.24.1.24.44436: . ack 3626842638 win 122 <nop,nop,timestamp 2177841767 1120348081>
259: 17:32:05.934018 10.24.1.24.44436 > 10.16.0.85.5923: P 3626842666:3626842672(6) ack 4208456341 win 1260 <nop,nop,timestamp 1120348225 2177841767>

I notice some "sack" in those, which sound like they ought to be related to the "sackOK" on inside1_2; but then I don't know why they would be on different interfaces.

lana.deere · ‎02-06-2018

In response to my own question about interface inside1_2, I tried putting an external switch on inside1_2 and transferring the connections from the other inside1_X ports to the external switch. This solved the problem. I haven't the slightest idea why the traffic for the other ports is getting sent to inside1_2, though.