TLS and Static NAT with Port-translation

[tham89]

Hi! I've been following CLI Book 2: Cisco Secure Firewall ASA Series Firewall CLI Configuration Guide, 9.18 specifically around Static NAT with Port Translation for Non-Standard Ports. I'm attempting to listen on *:4433 and rewrite it inside to a server listening on 443. The 443 policy that doesn't attempt to modify the port works fine, onto both servers, only when I try and rewrite the port does the actual application fail. I'm almost starting to feel stupid for even asking, now that I've explained it in detail, but I guess here goes nothing.

It seems like both servers are in good working order, and the access policy, conn logs, xlate, and traffic from TCPDump at both ends of the capture, but I guess we never bothered to ask if the application layer will even tolerate mangling of this sort? Will having the client and server disagree about the destination port ever be tolerated by HTTPS/TLS? ... did I miss something else in this configuration?

Auto NAT Policies (Section 2)
1 (inside) to (outside) source static inside-server-althttps interface service tcp https 4433
translate_hits = 0, untranslate_hits = 4
Source - Origin: 192.168.1.2/32, Translated: 86.75.30.9/30
Service - Protocol: tcp Real: https Mapped: 4433
2 (inside) to (outside) source static inside-server-https interface service tcp https https
translate_hits = 0, untranslate_hits = 34
Source - Origin: 192.168.1.3/32, Translated: 86.75.30.9/30
Service - Protocol: tcp Real: https Mapped: https
3 (inside) to (outside) source dynamic lan-inside interface
translate_hits = 59830, untranslate_hits = 13770
Source - Origin: 192.168.1.0/24, Translated: 86.75.30.9/30

[MHM Cisco World]

I need to see NAT config 

[tham89]

object network server-https
host 192.168.1.3
object network lan-inside
network 192.168.1.0 255.255.255.0
object network server-althttps
host 192.168.1.2

access-list lan_inside extended permit ip object lan-inside any
access-list outside-access extended permit tcp any host 192.168.1.3 eq https
access-list outside-access extended permit tcp any host 192.168.1.2 eq 4433
access-list outside-access extended permit tcp any host 192.168.1.3 eq https

object network server-https
nat (inside,outside) static interface service tcp https https
object network lan-inside
nat (inside,outside) dynamic interface
object network server-althttps
nat (inside,outside) static interface service tcp https 4433

access-group outside-access in interface outside
access-group lan_inside in interface inside

[tham89]

The plot thickens... client reconfigured their server to listen on 4433, and I reconfigured the ACLs, Object NATs, etc. to listen on the same, and connections still fail. I don't understand what I'm missing here.

[MHM Cisco World]

object network server-https
nat (inside,outside) static interface service tcp https https
object network lan-inside
nat (inside,outside) dynamic interface
object network server-althttps
nat (inside,outside) static interface service tcp https 4433

your NAT is correct but the issue is NAT order 

you use Network object which check by FW according to order you config it, here there dynamic above static and that make NATing not work. 
solution is using Twice NAT 
nat (inside,outside) source static object-http interface service http http 
nat (inside,outside) source static object-https interface service https https

try this way and check result 

MHM 

[tham89]

I've set this up with

object service TCP443
service tcp source eq https
object service TCP4433
service tcp source eq 4433

%ASA-6-300000: Built inbound TCP connection 2000000 for outside:55.5.12.34/65136 (55.5.12.34/65136) to inside:192.168.1.2/4433 (87.75.30.9/4433)

The normal port works fine.

On the non-standard port, I receive normal diagnostics like the above client connection establishment, etc.

# show nat

Manual NAT Policies (Section 1)
1 (inside) to (outside) source static server-https interface service TCP443 TCP443
translate_hits = 16, untranslate_hits = 17
2 (inside) to (outside) source static server-althttps interface service TCP4433 TCP4433
translate_hits = 25, untranslate_hits = 25

Auto NAT Policies (Section 2)
1 (inside) to (outside) source dynamic lan-inside interface
translate_hits = 124, untranslate_hits = 265

... but the application traffic fails. A traffic capture seems to suggest that strangely, Edge is requesting out to both servers, despite specifying the correct port.

[MHM Cisco World]

There is NAT and un-NAT

2 (inside) to (outside) source static server-althttps interface service TCP4433 TCP4433
translate_hits = 25, untranslate_hits = 25

so the drop either in inspection or ACL
for ACL we can check via add log keyword to ACL and see log message 
for inspection 
check 
show asp drop 

[AHack210]

Can you give us a packet-tracer?

[tham89]

# packet-tracer input outside tcp 55.5.12.34 64151 86.75.30.9 4433

Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Elapsed time: 18432 ns
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Elapsed time: 18432 ns
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: UN-NAT
Subtype: static
Result: ALLOW
Elapsed time: 15872 ns
Config:
nat (inside,outside) source static server-althttps interface service TCP4433 TCP4433
Additional Information:
NAT divert to egress interface inside
Untranslate 86.75.30.9/4433 to 192.168.1.2/4433

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Elapsed time: 7296 ns
Config:
access-group outside-access in interface outside
access-list outside-access extended permit tcp object-group ext host 192.168.1.2 eq 4433
object-group network ext
network-object host 55.5.12.34
Additional Information:

Phase: 5
Type: NAT
Subtype:
Result: ALLOW
Elapsed time: 7296 ns
Config:
nat (inside,outside) source static server-althttps interface service TCP4433 TCP4433
Additional Information:
Static translate 55.5.12.34/64151 to 55.5.12.34/64151

Phase: 6
Type: NAT
Subtype: per-session
Result: ALLOW
Elapsed time: 7296 ns
Config:
Additional Information:

Phase: 7
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Elapsed time: 7296 ns
Config:
Additional Information:

Phase: 8
Type: NAT
Subtype: rpf-check
Result: ALLOW
Elapsed time: 29696 ns
Config:
nat (inside,outside) source static server-althttps interface service TCP4433 TCP4433
Additional Information:

Phase: 9
Type: NAT
Subtype: per-session
Result: ALLOW
Elapsed time: 22528 ns
Config:
Additional Information:

Phase: 10
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Elapsed time: 1024 ns
Config:
Additional Information:

Phase: 11
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Elapsed time: 65536 ns
Config:
Additional Information:
New flow created with id 1999999, packet dispatched to next module

Phase: 12
Type: INPUT-ROUTE-LOOKUP-FROM-OUTPUT-ROUTE-LOOKUP
Subtype: Resolve Preferred Egress interface
Result: ALLOW
Elapsed time: 14336 ns
Config:
Additional Information:
Found next-hop 192.168.1.2 using egress ifc inside

Phase: 13
Type: ADJACENCY-LOOKUP
Subtype: Resolve Nexthop IP address to MAC
Result: ALLOW
Elapsed time: 3072 ns
Config:
Additional Information:
Found adjacency entry for Next-hop 192.168.1.2 on interface inside
Adjacency :Active
MAC address 0030.dead.beef hits 1366 reference 69

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow
Time Taken: 218112 ns

[MHM Cisco World]

NOTE:- packet tracer not show traffic is drop by ACL or not sometimes 
I share how you can check ACL with log

[AHack210]

HI, so your NAT statement appears to be working as designed:

Untranslate 86.75.30.9/4433 to 192.168.1.2/4433

And it is being arped and delivered to the destination segment:

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

So the firewall is not the issue. You can verify this with a packet capture on the inside interface.

I suspect you either have a downstream issue or the service is not running or allowing access. a TCP ping from the firewall can help verify this:

ping tcp inside 192.168.1.2 4433

[tham89]

Very cool, didn't realize these had a TCP ping on-board, that's incredibly useful! However,

# ping tcp inside 192.168.1.2 4433 source 192.168.1.1 63417
Type escape sequence to abort.
Sending 1400 TCP SYN requests to 192.168.1.2 port 4433
from 192.168.1.1 starting port 63417, timeout is 0 seconds:
???????????????????????????????????????????????????????????
Success rate is 0 percent (0/59)

# ping tcp inside 192.168.1.3 443 source 192.168.1.1 63417
Type escape sequence to abort.
Sending 1400 TCP SYN requests to 192.168.1.3 port 443
from 192.168.1.1 starting port 63417, timeout is 0 seconds:
???????????????????????????????????????????????????????????
Success rate is 0 percent (0/59)

# show run access-group
access-group outside-access in interface outside
access-group lan_inside in interface inside
access-group lan_inside out interface inside

# show run access-list lan_inside
access-list lan_inside extended permit ip object lan-inside any

# show run object
object network lan-inside
subnet 192.168.1.0 255.255.255.0

# show asp drop

Frame drop:
Flow is denied by configured rule (acl-drop) 118

and a short-term clear of show asp suggests that it is an ACL drop rather than an application issue. As a matter of fact, the 192.168.1.3 server actualy works from the outside despite having the inside TCP ping dropped. Color me confused.

[MHM Cisco World]

# ping tcp outside 192.168.1.2 4433 source 192.168.1.1 63417

This must source from outside  not from inside 

Also you need to not use any asa interface IP in packet tracer 

[AHack210]

The purpose of the TCP ping is to verify that the backend service is up and reachable from the firewall. TCP Ping from the firewall inside interface bypasses NAT and ACLs and verifies that the service is indeed up and listening and answering 3-way handshakes without the firewall being involved in the communication.

[tham89]

Alright, I was able to confirm that the TCP ping towards both servers succeeds, I think this is after adding a line to the firewall to permit inside traffic appearing at the outside interface:

# ping tcp inside 192.168.1.3 443 timeout 0 repeat 1400
Type escape sequence to abort.
No source specified. Pinging from identity interface.
Sending 1400 TCP SYN requests to 192.168.1.3 port 443
from 192.168.1.1, timeout is 0 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (1400/1400), round-trip min/avg/max = 1/1/1 ms

# ping tcp inside 192.168.1.2 4433 timeout 0 repeat 1400
Type escape sequence to abort.
No source specified. Pinging from identity interface.
Sending 1400 TCP SYN requests to 192.168.1.2 port 4433
from 192.168.1.1, timeout is 0 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (1400/1400), round-trip min/avg/max = 1/1/1 ms

... but still, only one server works from the outside.