topic Re: nat-control deprecated; any equivalent? (moved here) in Network Security

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

Loxmyth — Thu, 24 Aug 2023 04:09:05 GMT

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.)

Re: nat-control deprecated; any equivalent? (moved here)

tvotna — Fri, 18 Aug 2023 08:55:41 GMT

@Loxmyth, "nat-control" was deprecated and removed in version 8.3 when NAT code was completely re-written. There is no hidden equivalent or something like this. So, if NAT or PAT is not configured, proper ACLs are configured and routing is configured properly, traffic will pass between interfaces with different security levels in both directions subject to ACLs.

If NAT or PAT is configured (e.g. for subset of interfaces or traffic), things become more complicated. E.g. there is a feature "NAT RPF check" which can prevent communications depending on the NAT type being used (twice vs. manual) and software version. In such cases "packet-tracer" can help with troubleshooting.

Re: nat-control deprecated; any equivalent? (moved here)

Loxmyth — Fri, 18 Aug 2023 16:16:28 GMT

Thanks. What I can't figure out is why I'm having such trouble getting a basic "just keep lower security from opening connections to higher security, without explicit NAT" configuration going (and why it's working for Ricky). I'm starting to suspect that my error might not be in the .conf file but in something else.

Unfortunately I haven't found a good example of that minimal configuration in any of the docs or websites I've checked. I'd actually have expected it to be the default behavior of the box, but if so I haven't been able to find my way back to it.

Could I ask a HUGE favor, and ask you to take a look at my configuration and see if you can spot what I've botched?

(Quoting Frances Sternhagen as Dr. Marian Lazarus in Outland: "Such a smart piece of equipment, and a wreck like me trying to run it...")

Re: nat-control deprecated; any equivalent? (moved here)

tvotna — Fri, 18 Aug 2023 17:01:56 GMT

Are you asking about outside to inside access or inside to outside or dmz to public, etc?

nat (any,public) source dynamic any interface
nat (any,outside) source dynamic any interface dns
nat (any,DMZ) source dynamic any interface
nat (any,inside) source dynamic any interface

For example, if you remove "nat (any,DMZ) source dynamic any interface" you should still be able to access DMZ 172.17.2.x from inside 172.17.1.y (higher security level to lower security level). To access inside from DMZ you need to permit traffic with ACL.

Re: nat-control deprecated; any equivalent? (moved here)

Loxmyth — Fri, 18 Aug 2023 17:45:02 GMT

That's what I would have expected. But that isn't what I'm seeing.
With these NAT rules in place, I can ping or ssh from machines on inside to public (172.17.1.102 to 172.17.3.20).
If I use ASDM to delete the rule for public

ASDM sends the commands
no nat 1
clear xlate global 172.17.3.0 netmask 255.255.255.0
and I can no longer ping or ssh to anything on the ..3.0 subnet from machines on either inside (..1.102) or management (..17.100).

It isn't 100% clear whether the problem is that packets aren't getting out, packets aren't coming back, or somehow the target machines are themselves not accepting traffic from anything outside their own 255.255.255.0 masked range. If the latter, it might be that something is wrong with what dhcp is pushing out to them...

I haven't yet put wireshark on this.
ASDM traceroute from inside (or 172.17.1.1) to 172.17.3.20 without the NAT rule times out.
ASDM tcp ping from inside to 172.17.3.20 without the NAT rule succeeds
ASDM tcp ping from inside/172.17.1.102 to 172.17.3.20 without the NAT rule times out
ASDM icmp ping from inside to 172.17.3.20 without the NAT rule times out
ASDM traceroute from inside to 172.17.3.20 without the NAT rule times out
ASDM use-icmp traceroute from inside to 172.17.3.20 without the NAT rule times out

If I restore the NAT rule, communication down to public is permitted again.

It really seems to want the explicit NAT. I don't understand why, since everyone agrees that higher-to-lower-security connection is supposed to Just Work.

Re: nat-control deprecated; any equivalent? (moved here)

Marius Gunnerud — Sun, 20 Aug 2023 09:29:00 GMT

Is this a lab setup? Also, you mention the following:

Have you run a packet-tracer when you have removed the NAT rule? What are the results?

You could also run a capture on the public interface and inside interface simultaneously to see if you see traffic in both direction.

Re: nat-control deprecated; any equivalent? (moved here)

Loxmyth — Sun, 20 Aug 2023 14:46:51 GMT

Lab is a decent description. I can run experiments without seriously disrupting anyone's work.

Packet tracing: Let's see. With NAT disabled on public, using a host that I know is up:

ASDM traceroute to .3.20 without specifying source works, of course.
Setting source inside times out.
Setting source .1.1 (inside's address) times out.
Adding use-icmp still times out.

Windows tracert from .1.102 to .3.20: All * * * Request timed out.
Linux traceroute from .1.110: All * * *

Haven't used the capture feature before; I'll try it.

Re: nat-control deprecated; any equivalent? (moved here)

Loxmyth — Sun, 20 Aug 2023 15:43:10 GMT

ADSM packet tracer: I'm not 100% sure I'm grokking what this is telling me, but:

Tracing from Interface inside, type ip, from .1.102 to .3.20, with no NAT on public, everything is ok until
    NAT rpf-check, action DROP
    Config: nat(any,inside) source dynamic any interface
There shouldn't be any _outgoing_ NAT from inside to outside... should there?
    Input Interface: inside
    Output Interface: public
    Info: (acl-drop) Flow is denied by configured rule

If I set Interface: public, otherwise same parameters (which I think simulates what would happen if the packet was just being transferred from inside to public?), all actions are OK and the packet is allowed.

Re: nat-control deprecated; any equivalent? (moved here)

Marius Gunnerud — Sun, 20 Aug 2023 15:35:58 GMT

Yeah, that NAT statement there, nat(any,inside) source dynamic any interface, is your issue. Remove this and you should be good to go. Also, I highly recommend not using any as the source interface, use specific interface names. Use as specific NAT rules as possible and you will not run into these types of issues in the future.

Re: nat-control deprecated; any equivalent? (moved here)

Loxmyth — Sun, 20 Aug 2023 16:23:15 GMT

But without NAT on inside, I can't ping inside from management...?

Remember, the real problem here is that if I disable all the NAT rules, tcp is failing to make any connections... despite the intended behavior in that case being that things on higher security interfaces can talk to things on lower security interfaces. I can't even http out to the net unless there's a NAT rule for outside. (And wasn't NAT supposed to be protocol-aware so any tcp exchange that went through NAT got its responses converted back?)

I absolutely agree that for my simple case I shouldn't need or be using NAT at all. But it's the only way I've found to make things work vaguely as expected. Goal of this discussion was to figure out why that root problem exists on my box and fix it.

Re: nat-control deprecated; any equivalent? (moved here)

Loxmyth — Sun, 20 Aug 2023 16:58:43 GMT

In other words, the configuration attached hereto (same as above but delete all the NATs) does _not_ work on my 5510. And I don't know why not. I've been told that when my config was loaded onto a 5540 it did work without NATs, but I'm not sure we're at exactly the same firmware level.

I'm sure it's something obvious to someone who really understands the ASA. I grok many of the individual pieces but clearly not their interaction.

Re: nat-control deprecated; any equivalent? (moved here)

Marius Gunnerud — Sun, 20 Aug 2023 19:38:11 GMT

What type of devices are you pinging towards on the Public network? Are you sure that this is not a routing issue on those devices?

I highly suggest you do a packet capture on both the inside and public interfaces and then compare the two. If you see packets entering the inside interface, leaving the public interface, but not getting anything in return there is an issue between the public interface and the device you are trying to connect to. Keep in mind that the capture needs to be set up with the IPs you expect to see. So if you have NAT configured then on the inside interface you would configure the real source IP and real destination IP, but on the public interface you would configure the translated source IP and the real destination IP.

If you do not have NAT configured when testing you would just use the real IPs for both source and destination on both inside and public interfaces.

But without NAT on inside, I can't ping inside from management...?

You do not need NAT for communication between RFC 1918 IPs, you do need NAT for communication to public IPs from private IPs. So removing the NAT should not affect communication between networks connected or routed through the ASA. However you will not be able to connected to an ASA interface that is not the ingress interface. That is to say you cannot connected to the management interface from a device located on the inside network if that traffic passes through the ASA. The only way this will be allowed is if the management traffic does not pass through the ASA to reach the management interface.

Re: nat-control deprecated; any equivalent? (moved here)

Loxmyth — Sun, 20 Aug 2023 20:49:00 GMT

The devices on Public I'm pinging most often are Raspberry Pis running Raspbian linux. It's certainly possible they're misconfigured and didn't expect to talk to anyone outside their own LAN's address range.

Just tried pinging a different device on public, laptop running antiX linux. With NAT, ping succeeds. With the NAT rule for public disabled, ping fails. Again, it's possible that this laptop Linux is unwilling to listen to anything outside its own LAN, but it's another datapoint.

I can try reversing things, put that laptop on Inside and my working machine on public, and see if that changes matters. Of the two I'd expect Windows to have more problems in networking than Linux, but...

Lemme see if I can figure out packet capture, and I'll try that without NAT.

Yes, understand about connectivity. That's why I currently have the ASA permitting access on both the internal and management interfaces; I'm hardwired to one or the other of those, and I try not to alter both at once so I've got a reliable alternative route.

We all agree that I _shouldn't_ need NAT in this setup. It's certainly possible that the ASA is not at fault. The traceroute results specifically report "(acl-drop) Flow is denied by configured rule", but that may not imply a rule in the ASA's acl.

Lemme see if I can figure out packet capture, and I'll try that without NAT.

Re: nat-control deprecated; any equivalent? (moved here)

Loxmyth — Sun, 20 Aug 2023 21:51:46 GMT

I was going to say that the problem with the theory that it's the hosts that are misbehaving is that, in that case, I'm not sure why I need NAT to communicate with the WAN-facing outside. ... Oh. Maybe.

The ASA is plugged into a FIOS ONT (optical fiber). It's not impossible that this is blocking traffic from address ranges other than the one it assigned the via DHCP. That would require the translation from my 172.17 space, just as basic routers (I believe) run NAT to connect their 192.168 addresses to the ISP.

So that one NAT rule, and only that one, would make sense. Yes?

---

BTW, packet capture is starting to -- finally, maybe -- convince me that the problem is in the leaf machines rather than in the ASA.

Question: The interface configuration, when I set the interface address, insists that the subnet mask be 255.255.255.0 when the interface is placed at .x.1. My understanding was that this meant if 172.17.1.x was talking to 172.17.3.y, the packet needed to cross the firewall since they're separate subnets, otherwise the firewall could completely ignore that packet. If so, how would I express a /16 address range (all of 172.17) when setting the interface address?

Should I have done that (however it's done) as a single set of addresses shared by all interfaces, and used the third octet more as a comment indicating which physical subnet the device was on, rather than assigning each interface its own /24 address? I thought ASDM was keeping me from going that direction...

Re: nat-control deprecated; any equivalent? (moved here)

tvotna — Mon, 21 Aug 2023 08:39:40 GMT

Hi @Loxmyth . Answering few question here.

1. This is expected behavior of ASA NAT that it drops packets due to NAT RPF check when you remove NAT rule 1 and ping from inside to public:

nat (any,outside) source dynamic any interface dns
nat (any,DMZ) source dynamic any interface
nat (any,inside) source dynamic any interface

In this case "forward flow" matches none rules and "reverse flow" matches 3rd rule and ASA doesn't like it. But actually, this concept is not easy to explain taking into consideration that ASA is a stateful firewall (why should "forward" and "reverse" flows be separated?). Also, IOS routers don't have anything like this at all. The reason behind "NAT RPF check" is how ACLs work on ASA. For example, when you allow traffic from outside to internal Web server, you specify real-IP (private IP) of the server in the outside ACL, rather than its public IP. Even if you make an error and permit whole subnet range, NAT RPF check will prevent communications from outside to inside:

nat (inside,outside) source dynamic any interfacenat (inside,outside) source static obj-10.1.1.1 interface service obj-tcp-src-443 obj-tcp-src-4443access-list outside_in permit tcp any 10.1.1.0 255.255.255.0 eq 443access-group outside_in in interface outside

So, NAT RPF check is a security mechanism (sort of).

2. Yes, typically NAT is needed to access outside to translate private space to addresses which upstream devices understand and have routing to. You can check what IP address is assigned to your outside interface with "show int ip brief". You should see default route assigned by DHCP too. Single rule should work just fine:

nat (any,outside) source dynamic any interface dns

Traffic between other interfaces, e.g. inside to public or public to inside won't be NATed and everything should work if devices have proper routing configured via ASA.

3. Packet capture can be used from CLI (also packet-tracer tool), e.g.

capture cap-in interface inside match tcp host 10.1.1.1 host 192.0.2.10 eq 23capture cap-out interface outside match tcp host 10.1.1.1 host 192.0.2.10 eq 23
show capture cap-inshow capture cap-out

Capture is bi-directional.

4. In routed firewall mode ASA won't allow you configure overlapping address spaces. It will complain "two interfaces cannot be on the same subnet".

Re: nat-control deprecated; any equivalent? (moved here)

Loxmyth — Mon, 21 Aug 2023 21:17:48 GMT

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.)

Re: nat-control deprecated; any equivalent? (moved here)

Marius Gunnerud — Mon, 21 Aug 2023 22:21:35 GMT

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

Re: nat-control deprecated; any equivalent? (moved here)

Loxmyth — Tue, 22 Aug 2023 01:47:49 GMT

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.

Re: nat-control deprecated; any equivalent? (moved here)

Loxmyth — Tue, 22 Aug 2023 03:59:49 GMT

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.)

Re: nat-control deprecated; any equivalent? (moved here)

Marius Gunnerud — Tue, 22 Aug 2023 05:44:08 GMT

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?