Problems running ASA5510 as 172.x.y.z (final resolution: subnet masks)

[Loxmyth]

On my 5510, NAT rules appear to be needed for successful communication between interfaces at different security levels.
On Ricky's 5540, the security levels alone are sufficient to control flow between these; no NAT rules are required.

I'd say that was the result of nat-control being set differently on the two boxes, except that we're both running firmware versions after nat-control was deprecated.

So... Is there a command that has equivalent effect, that we might have set differently on the two boxes without noticing it in the .cfg dumps? Or might that control still be there but invisible and inaccessible, so our two machines are unavoidably going to behave differently?

(We've been beating our heads against this for the past week, trying to find the point of divergence between our setups. This looks suspiciously likely.)

[Loxmyth]

The goal is to use the interface security levels but otherwise permit all traffic (with required NAT to outside). It sounds like NAT RPF Check is what's getting in the way with the current setup -- true?

If so, what's the fix? Do I need to go to transparent mode, set all the interfaces as  172.17.0.1 255.255.0.0, and tell DHCP that each interface allocates addresses out of a separate subpool just so DHCP-provided addresses include the indication of what interface they're connected to? This seems rather different from the "plug it in, set security levels and address ranges, and due to statefulness everything should just work" that people keep telling me.

Or am I still confused?

I would expect this to be one of the most common starting configurations for the ASA, but there doesn't seem to be a worked example on the Web. Surprising.

(Yes, I know everything -- and maybe more things -- that can be done through ASDM can be done from the command line. I had to play with that until I get enough of the (used) machine reset and configured to connect ASDM to it at all. But if it CAN be done in the GUI tool, that's easier for this novice. Assuming I can figure out where the GUI hides that control and what the interactions are.)

[Marius Gunnerud]

When packet-tracer complains about RPF drop it is usually either due to a routing issue or a wrong packet-tracer syntax.  Try running the following and post the complete output here.  run it once with nat present and then once again without nat, save them into separate files and post the files here.

packet-tracer input inside tcp 172.17.1.10 12345 172.17.3.10 443 detail

Is there a reason you have ipv6 enabled on the interfaces?  I would suggest that until the issue is identified, remove any configuration that is not really necessary, including the ipv6 configuration.

Also, would be good if you could perform a capture on the interfaces in question while you run a tes connection. Also, post the results here.

cap capin interface inside match ip any host <IP of destination 172.17.3.x>

cap cappub interface public match ip any host <IP of destination 172.17.3.x>

show cap capin

show cap cappub

[Loxmyth]

OK, lemme turn off IPv6.

With NAT rules enabled:

Result of the command: "packet-tracer input inside tcp 172.17.1.10 12345 172.17.3.10 443 detail"

Phase: 1
Type: ACCESS-LIST
Subtype: 
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0xad5a1d68, priority=1, domain=permit, deny=false
hits=2205239, user_data=0x0, cs_id=0x0, l3_type=0x8
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0100.0000.0000
input_ifc=inside, output_ifc=any

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 172.17.3.0 255.255.255.0 public

Phase: 3
Type: NAT
Subtype: 
Result: ALLOW
Config:
nat (any,public) source dynamic any interface
Additional Information:
Dynamic translate 172.17.1.10/12345 to 172.17.3.1/12345
Forward Flow based lookup yields rule:
in id=0xadb5b178, priority=6, domain=nat, deny=false
hits=90697, user_data=0xae516000, cs_id=0x0, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0, dscp=0x0
input_ifc=any, output_ifc=public

Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xacdf5310, priority=0, domain=nat-per-session, deny=false
hits=291569, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0, dscp=0x0
input_ifc=any, output_ifc=any

Phase: 5
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xad5a8a00, priority=0, domain=inspect-ip-options, deny=true
hits=174474, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0, dscp=0x0
input_ifc=inside, output_ifc=any

Phase: 6
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (any,inside) source dynamic any interface
Additional Information:
Forward Flow based lookup yields rule:
out id=0xadc0c318, priority=6, domain=nat-reverse, deny=false
hits=54277, user_data=0xacce2620, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0, dscp=0x0
input_ifc=inside, output_ifc=any

Phase: 7
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
in id=0xacdf5310, priority=0, domain=nat-per-session, deny=false
hits=291571, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0, dscp=0x0
input_ifc=any, output_ifc=any

Phase: 8
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
in id=0xad5fd500, priority=0, domain=inspect-ip-options, deny=true
hits=153627, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0, dscp=0x0
input_ifc=public, output_ifc=any

Phase: 9
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Config:
Additional Information:
New flow created with id 348386, packet dispatched to next module
Module information for forward flow ...
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_tcp_normalizer
snp_fp_translate
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat

Module information for reverse flow ...
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_translate
snp_fp_tcp_normalizer
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: public
output-status: up
output-line-status: up
Action: allow

With NAT rules disabled (except for the one on outside):

Result of the command: "packet-tracer input inside tcp 172.17.1.10 12345 172.17.3.10 443 detail"

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 172.17.3.0 255.255.255.0 public

Phase: 2
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xacdf5310, priority=0, domain=nat-per-session, deny=false
hits=292499, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0, dscp=0x0
input_ifc=any, output_ifc=any

Phase: 3
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xad5a8a00, priority=0, domain=inspect-ip-options, deny=true
hits=174830, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0, dscp=0x0
input_ifc=inside, output_ifc=any

Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
in id=0xacdf5310, priority=0, domain=nat-per-session, deny=false
hits=292501, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0, dscp=0x0
input_ifc=any, output_ifc=any

Phase: 5
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
in id=0xad5fd500, priority=0, domain=inspect-ip-options, deny=true
hits=153821, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0, dscp=0x0
input_ifc=public, output_ifc=any

Phase: 6
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Config:
Additional Information:
New flow created with id 348997, packet dispatched to next module
Module information for forward flow ...
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_tcp_normalizer
snp_fp_translate
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat

Module information for reverse flow ...
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_translate
snp_fp_tcp_normalizer
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: public
output-status: up
output-line-status: up
Action: allow

Still with NAT rules disabled (except Outside), captures of ping -n 3 172.17.3.20 followed by ssh 172.17.3.20

Result of the command: "cap capin interface inside match ip any host 172.17.3.20"

The command has been sent to the device


Result of the command: "cap cappub interface public match ip any host 172.17.3.20"

The command has been sent to the device




Result of the command: "show cap capin"

12 packets captured

1: 21:29:03.627531 172.17.1.101 > 172.17.3.20: icmp: echo request 
2: 21:29:08.346692 172.17.1.101 > 172.17.3.20: icmp: echo request 
3: 21:29:13.347180 172.17.1.101 > 172.17.3.20: icmp: echo request 
4: 21:29:18.354199 172.17.1.101 > 172.17.3.20: icmp: echo request 
5: 21:33:16.400080 172.17.1.101 > 172.17.3.20: icmp: echo request 
6: 21:33:21.340833 172.17.1.101 > 172.17.3.20: icmp: echo request 
7: 21:33:26.340070 172.17.1.101 > 172.17.3.20: icmp: echo request 
8: 21:33:47.977259 172.17.1.101.48987 > 172.17.3.20.22: S 2531197003:2531197003(0) win 64240 <mss 1460,nop,wscale 8,nop,nop,sackOK> 
9: 21:33:48.985498 172.17.1.101.48987 > 172.17.3.20.22: S 2531197003:2531197003(0) win 64240 <mss 1460,nop,wscale 8,nop,nop,sackOK> 
10: 21:33:50.992151 172.17.1.101.48987 > 172.17.3.20.22: S 2531197003:2531197003(0) win 64240 <mss 1460,nop,wscale 8,nop,nop,sackOK> 
11: 21:33:55.002242 172.17.1.101.48987 > 172.17.3.20.22: S 2531197003:2531197003(0) win 64240 <mss 1460,nop,wscale 8,nop,nop,sackOK> 
12: 21:34:03.009612 172.17.1.101.48987 > 172.17.3.20.22: S 2531197003:2531197003(0) win 64240 <mss 1460,nop,wscale 8,nop,nop,sackOK> 
12 packets shown


Result of the command: "show cap cappub"

15 packets captured

1: 21:29:03.627698 172.17.1.101 > 172.17.3.20: icmp: echo request 
2: 21:29:08.346860 172.17.1.101 > 172.17.3.20: icmp: echo request 
3: 21:29:13.347363 172.17.1.101 > 172.17.3.20: icmp: echo request 
4: 21:29:18.354367 172.17.1.101 > 172.17.3.20: icmp: echo request 
5: 21:33:16.400232 172.17.1.101 > 172.17.3.20: icmp: echo request 
6: 21:33:21.341001 172.17.1.101 > 172.17.3.20: icmp: echo request 
7: 21:33:26.340238 172.17.1.101 > 172.17.3.20: icmp: echo request 
8: 21:33:47.977442 172.17.1.101.48987 > 172.17.3.20.22: S 4184713546:4184713546(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK> 
9: 21:33:48.985559 172.17.1.101.48987 > 172.17.3.20.22: S 4184713546:4184713546(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK> 
10: 21:33:50.992212 172.17.1.101.48987 > 172.17.3.20.22: S 4184713546:4184713546(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK> 
11: 21:33:55.002288 172.17.1.101.48987 > 172.17.3.20.22: S 4184713546:4184713546(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK> 
12: 21:34:03.009658 172.17.1.101.48987 > 172.17.3.20.22: S 4184713546:4184713546(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK> 
13: 21:34:33.803867 172.17.3.20 > 224.0.0.251: ip-proto-2, length 8 
14: 21:34:35.324842 172.17.3.20 > 224.0.0.251: ip-proto-2, length 8 
15: 21:34:40.048871 172.17.3.20 > 224.0.0.251: ip-proto-2, length 8 
15 packets shown

Of course with the NAT rules disabled, my console response on .1.101 was as follows. (Local .hosts file mapping meetpoint to .3.20)

C:\Users\keshlam\>ping -n 3 172.17.3.20

Pinging 172.17.3.20 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 172.17.3.20:
Packets: Sent = 3, Received = 0, Lost = 3 (100% loss),

C:\Users\keshlam>ssh meetpoint
ssh: connect to host meetpoint port 22: Connection timed out

C:\Users\keshlam>

MANY thanks, once again, to everyone who has been willing to look at this!

Any suggestions where I should post a usage tip based on my misunderstanding, once we find it, would be welcome; I'm not currently running a blog of my own. Or if you're planning to write it up, let me know where so I can point folks to it.

[Loxmyth]

Possibly dumb question: The default Access Rules permit ip. I have been presuming that this was a convenience setting which implied tcp, and tcp implied all the individual protocols built on tcp. (I'm not clear on whether or not it implies icmp.) Certainly the outgoing packets have seemed to behave that way. But... could not having explicitly specified (for example) ssh be causing us not to have stateful processing of that transaction? Or does ip really mean stateless ip, with my having to explicitly include tcp (or all the individual protocols?) if I want the firewall to handle sessions correctly?

(I've also been presuming this because user-entered rules don't offer the option of "any less secure", and don't let me select multiple interfaces so I can't do this manually. And since I'm not sure I know what network I'm going to be assigned when outside picks up the ONT's DHCP info, I can't use the address-ranges version to do this as a single access rule either.)

[Marius Gunnerud]

Higher to lower security levels implies IP, and we do see that icmp is entering the ASA inside interface and leaving the Public interface.  But we are not seeing anything in return.  Since ICMP is stateless, you need the command inspect icmp in your policy-map global-policy to allow the return ICMP traffic which you do have in place.  This leads me to believe that the issue is either on the destination host or the network between the destination host and the ASA.  

Are you able to ping the ASA 172.17.3.1 interface from 172.17.3.20 device?

can you verify the IP, subnet, and default gateway on the 172.17.3.20 device?

Do you by chance have a local firewall enabled on the 172.17.3.20 device?

[Loxmyth]

There's no local firewall on any of the public (..3.) machines. They can ping the ASA port. There's nothing between it and them but a dumb Ethernet switch.

Can I add the ICMP accept to the default firewall rule, or do I have to first make that an explicit rule (and explicitly list everything rather than using "all less secure")? If the latter... I can defer that and live without ping until we have ssh working as intended. There's a tcp option on ping, if it comes to that.

[Marius Gunnerud]

from higher to lower security level, as long as you have icmp inspect configured in the global-policy policy map the icmp reply should be allowed.  Do you have an option to create a SPAN monitoring session on the "Dumb Switch" port that connects to the ASA?

If the ASA is dropping the ICMP reply traffic, this happens before captures on the ASA are taken and will not show up in the capture.  So if you are able to do a wireshare via SPAN or similar on the switch we can determine if traffic is returning to the ASA or not.

could you issue the command show conn address 172.17.3.20 and show conn address 172.17.1.101 after you have done a test connection.

Another thing you might consider doing, if not done so already, is to reload the ASA.  There might be some stuck processes that are causing the issue.

[Loxmyth]

I'm actually surprised to see wlan0/wlx active here, since it's supposed to be connected only by cable, but for now I'm chalking that up to oddities of Raspbian and the RPi 3b...

keshlam@meetpoint:~ $ ip route
default via 172.17.3.1 dev enxb827ebeb5491 proto dhcp src 172.17.3.20 metric 202
default via 172.17.3.1 dev wlan0 proto dhcp src 172.17.3.20 metric 303
default via 172.17.3.1 dev wlx0013efc714b6 proto dhcp src 172.17.3.20 metric 304
172.17.0.0/16 dev enxb827ebeb5491 proto dhcp scope link src 172.17.3.20 metric 202
172.17.0.0/16 dev wlan0 proto dhcp scope link src 172.17.3.20 metric 303
172.17.0.0/16 dev wlx0013efc714b6 proto dhcp scope link src 172.17.3.20 metric 304
keshlam@meetpoint:~ $ ifconfig
enxb827ebeb5491: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.17.3.20 netmask 255.255.0.0 broadcast 172.17.255.255
inet6 fe80::2827:bbe5:1fdb:64f7 prefixlen 64 scopeid 0x20<link>
inet6 fd10:8f79:4105:a280:96e0:e6ba:7783:8e56 prefixlen 64 scopeid 0x0<global>
ether b8:27:eb:eb:54:91 txqueuelen 1000 (Ethernet)
RX packets 2142001 bytes 232540402 (221.7 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 209384 bytes 18779426 (17.9 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 728 bytes 73647 (71.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 728 bytes 73647 (71.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.17.3.20 netmask 255.255.0.0 broadcast 172.17.255.255
inet6 fd10:8f79:4105:a280:37e5:be06:564d:cac8 prefixlen 64 scopeid 0x0<global>
inet6 fe80::12c4:58f5:8d32:3917 prefixlen 64 scopeid 0x20<link>
ether b8:27:eb:be:01:c4 txqueuelen 1000 (Ethernet)
RX packets 1398638 bytes 182321607 (173.8 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8290 bytes 812748 (793.6 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlx0013efc714b6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.17.3.20 netmask 255.255.0.0 broadcast 172.17.255.255
inet6 fd10:8f79:4105:a280:535b:93cb:8901:c28b prefixlen 64 scopeid 0x0<global>
inet6 fe80::cffc:6c91:3371:edce prefixlen 64 scopeid 0x20<link>
ether 00:13:ef:c7:14:b6 txqueuelen 1000 (Ethernet)
RX packets 1940927 bytes 244696911 (233.3 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8448 bytes 998002 (974.6 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

keshlam@meetpoint:~ 

One thing worth noting is that this *did* set itself up for a /16 network, not /24. So that wouldn't (shouldn't?) explain the need for NAT. There goes my most recent guess...

[Loxmyth]

(For any Cisco folks reading this: It really would help to have more official "common example" configurations out there that we could simply swipe and use as our starting points. That would reduce how much of the box we have to learn immediately, and starting with something promised to work would eliminate at least some beginner mistakes. The existing docs are great references, but they do tend to assume that you already mostly understand the system and are just looking for details; they aren't tutorials.)

[Loxmyth]

I should probably rename this thread at some point, given that my initial guess about nat-control being involved was wrong.

Marius: Actually, I was wrong. There's a TPLink AC1750 first, running in access point mode with no NAT or DHCP of its own. Then there's a Netgear G5205 switch. I'm not sure what the monitoring capability is on either. But we can simplify matters: I can try moving the .3.20 machine to .2.20 (in the DMZ) and connect it directly to the ASA, eliminating any possible interference in the middle. If that cures the problem, I know it isn't the ASA per se; if it doesn't, we've eliminated those complications.

Lemme try that and report back.

Meanwhile, with NAT on and an SSH connection open from 1.101 to 3.20... (Lots of browser windows open from 1.101, I'm afraid, plus of course the ASDM connection...)

Result of the command: "show conn address 172.17.3.20"

178 in use, 1645 most used
TCP public 172.17.3.20:22 inside 172.17.1.101:55886, idle 0:01:30, bytes 5739, flags UxIO


Result of the command: "show conn address 172.17.1.101"

178 in use, 1645 most used
UDP public 239.255.255.250:1900 inside 172.17.1.101:49586, idle 0:00:05, bytes 704, flags - 
TCP public 172.17.3.20:22 inside 172.17.1.101:55886, idle 0:01:30, bytes 5739, flags UxIO 
TCP outside 34.149.100.209:443 inside 172.17.1.101:55873, idle 0:00:07, bytes 6423, flags UxIO 
TCP outside 54.243.231.45:443 inside 172.17.1.101:47602, idle 0:00:46, bytes 9182, flags UxIO 
TCP outside 52.94.224.209:80 inside 172.17.1.101:25198, idle 0:00:02, bytes 2477148, flags UxIO 
TCP outside 34.120.208.123:443 inside 172.17.1.101:55814, idle 0:00:48, bytes 8191, flags UxIO 
TCP outside 142.250.80.77:443 inside 172.17.1.101:47622, idle 0:00:02, bytes 6470, flags UxIO 
TCP outside 34.117.65.55:443 inside 172.17.1.101:55872, idle 0:02:04, bytes 2694, flags UxIO 
TCP outside 34.117.65.55:443 inside 172.17.1.101:55869, idle 0:00:07, bytes 6017, flags UxIO 
TCP outside 162.159.61.4:443 inside 172.17.1.101:51384, idle 0:00:02, bytes 6870839, flags UxIO 
TCP outside 20.25.241.18:443 inside 172.17.1.101:8484, idle 0:07:49, bytes 18800, flags UxIO 
TCP outside 18.161.21.10:443 inside 172.17.1.101:55359, idle 0:00:11, bytes 2217148, flags UxIO 
TCP outside 52.35.229.235:443 inside 172.17.1.101:55403, idle 0:00:06, bytes 117459, flags UxIO 
TCP outside 184.105.99.43:443 inside 172.17.1.101:47609, idle 0:00:27, bytes 9320, flags UxIO 
TCP outside 52.73.89.227:443 inside 172.17.1.101:55512, idle 0:00:53, bytes 798742, flags UxIO

[Loxmyth]

OK. Moved the Pi from 3.20 to 2.20, plugged directly into the ASA's interface 2 (DMZ)
With NAT on DMZ, can SSH to it.
With NAT on DMZ disabled...

Hm. Interesting. Disabling the NAT rule did not seem to break an SSH connection I had left open (?!). But after closing that session (and inadvertently rebooting the Pi; fumblefingered a BASH commandline), I can't establish a new one.

So it _looks_ like the blame doesn't (entirely) fall on the TP-Link router and Netgear switch on ..3. (public). There is another Netgear switch between ..1. (public) machines and the ASA, if that might matter at all.

[Loxmyth]

Restored NAT on interface 2/DMZ. Had to reboot the Pi; probably something about that unstable-state ssh connection. It's still .2.20, since I have an inform line in its dhcpcd.conf file saying so (that one needs a stable address).  The machine I'm running ASDM on (and typing this on) is now on 3.100 rather than 3.101; thank you, DHCP...

Result of the command: "show conn address 172.17.2.20"

329 in use, 363 most used
TCP DMZ 172.17.2.20:22 inside 172.17.1.100:43259, idle 0:01:56, bytes 10991, flags UxIO


Result of the command: "show conn address 172.17.1.100"

329 in use, 363 most used
UDP inside 172.17.1.100:50783 management 239.255.255.250:1900, idle 0:00:49, bytes 704, flags - 
UDP public 239.255.255.250:1900 inside 172.17.1.100:50783, idle 0:00:49, bytes 704, flags - 
TCP DMZ 172.17.2.20:22 inside 172.17.1.100:43259, idle 0:01:56, bytes 10991, flags UxIO 
TCP outside 54.211.170.244:443 inside 172.17.1.100:43241, idle 0:00:13, bytes 379684, flags UxIO 
TCP outside 13.35.93.81:443 inside 172.17.1.100:53673, idle 0:00:25, bytes 217007, flags UxIO 
TCP outside 34.117.65.55:443 inside 172.17.1.100:53639, idle 0:01:49, bytes 2918, flags UxIO 
TCP outside 34.117.65.55:443 inside 172.17.1.100:33716, idle 0:11:11, bytes 3030, flags UFxIO 
TCP outside 34.117.65.55:443 inside 172.17.1.100:33714, idle 0:06:02, bytes 2770, flags UFxIO 
TCP outside 162.159.61.4:443 inside 172.17.1.100:53593, idle 0:00:24, bytes 8421, flags UxIO 
TCP outside 162.159.61.4:443 inside 172.17.1.100:53592, idle 0:00:17, bytes 226738, flags UxIO 
TCP outside 52.159.127.243:443 inside 172.17.1.100:53594, idle 0:16:54, bytes 7557, flags UxIO 
TCP outside 184.105.99.43:443 inside 172.17.1.100:43284, idle 0:00:17, bytes 9320, flags UxIO 
TCP outside 52.1.135.115:443 inside 172.17.1.100:43268, idle 0:00:16, bytes 7674, flags UxIO 
TCP outside 34.149.100.209:443 inside 172.17.1.100:43270, idle 0:00:50, bytes 8965, flags UxIO 
TCP outside 34.149.100.209:443 inside 172.17.1.100:33717, idle 0:06:03, bytes 2161, flags UFxIO 
TCP outside 104.104.97.59:443 inside 172.17.1.100:43263, idle 0:00:52, bytes 34783, flags UxIO 
TCP outside 104.104.97.59:443 inside 172.17.1.100:33696, idle 0:14:57, bytes 8361, flags UFxIO 
TCP outside 34.120.115.102:443 inside 172.17.1.100:43274, idle 0:00:47, bytes 28479, flags UxIO 
TCP outside 34.160.144.191:443 inside 172.17.1.100:43272, idle 0:00:50, bytes 5964, flags UxIO 
TCP outside 52.202.78.51:443 inside 172.17.1.100:43244, idle 0:00:16, bytes 21721, flags UxIO 
TCP outside 34.117.237.239:443 inside 172.17.1.100:43273, idle 0:00:47, bytes 3740, flags UxIO 
TCP outside 34.107.221.82:80 inside 172.17.1.100:33687, idle 0:06:06, bytes 601, flags UFxIO 
TCP outside 34.107.221.82:80 inside 172.17.1.100:33686, idle 0:06:05, bytes 1042, flags UFxIO

[Marius Gunnerud · Accepted solution]

inet 172.17.3.20 netmask 255.255.0.0 broadcast 172.17.255.255

This most definately is the reason you need NAT to  communicate with the device.  The Public interface subnet for one is a /24 which is a mismatch, but you can argue that /16 includes the /24, whatever.  However, /16 also includes the inside interface IP subnet so the Raspbian believes it is connected to the source subnet and will never send the return packet to the ASA.  Fix this issue and you have fixed your problem, unless you have other problems with the TPlink and / or Netgear.

[Loxmyth]

Ahhh. Wow. Well, I figured it would be obvious in retrospect... I thought about that when first setting up the address ranges for each interface, then forgot it again.

So the question is,  where the heck is that /16 coming from? According to ASDM, all the interfaces have masks of  255.255.255.0. I sorta expected that to be passed down as part of dhcp. Unless someone was clever and assumed that 172. private addresses were by definition a /16 space and is setting that locally in the Pi. My fault for trying to be fancy and use something other than the 192.168 range, I suppose. 

My options seem to be:

1. Resolve why we're getting a subnet mask other than I intended, and fix that.
2. Go back to 192.168 address range, where /24 is the assumption, and hope the subnet masks suddenly become /24 as well.
3. Separate the interface address ranges in the second octet rather than the third, so /16 is correct. Since the public range is 172.16 to 172.31, I'd need to encode my current "address indicates interface number", moving to something like 17.20, 17.21, 17.22, 17.23, and something vaguely appropriate for the Management interface. This might be a least-change solution if (1) is not possible.

Am I still missing anything? Other than whether the subnet mask can be fixed, that is?

[Marius Gunnerud · Accepted solution]

Your understanding is correct that the DHCP lease that is sent from the ASA needs to be within the same subnet that is assigned to the ASA interface (in your case, the Public interface).  So why the Rasbian is showing with /16 I am not sure.  It might be as you say that there is some setting that is forcing the interface on the Raspbian to /16.

the options you have mentioned to solve this are correct.  You could probably use destination NAT to solve this also, but that would probably complicate this more than it needs to be.