topic Re: bi-directional nat ok, tcp failing in Network Security

bi-directional nat ok, tcp failing

Collin Clark — Mon, 11 Mar 2019 22:36:26 GMT

For the life of me I can't get his one working. Public IP range is 1.1.1.128 255.255.255.128 and internal networks are 10.1.3.0 /24 (servers) and 10.1.7.0 /24 (clients). I have a static NAT translation so outside users can access an internal web server. I have another NAT statement for bi-directional NAT so inside users can access the web server using it's public IP. Outside users work fine. Inside users don't when pointing to public IP, but when pointing to the internal, it works just fine.

Client IP: 10.1.7.100

Server Private IP: 10.1.3.77

Server Public IP: 1.1.1.177

Looks like the NAT translation is working just fine-

Feb 28 2012 12:11:21: %ASA-6-302013: Built outbound TCP connection 3343090 for outside:10.1.3.77/80 (1.1.1.177/80) to inside:10.1.7.100/1221 (1.1.1.254/49099)

But we can see that the TCP session never establishes-

Feb 28 2012 12:11:51: %ASA-6-302014: Teardown TCP connection 3343090 for outside:10.1.3.77/80 to inside:10.1.7.100/1221 duration 0:00:30 bytes 0 SYN Timeout

Packet Tracer says everything should work-

my-fw# packet-tracer input inside tcp 10.1.7.100 2345 1.1.1.177 80 detail

Phase: 1

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in id=0xace546a8, priority=12, domain=capture, deny=false

hits=773213, user_data=0xacf01938, cs_id=0x0, l3_type=0x0

src mac=0000.0000.0000, mask=0000.0000.0000

dst mac=0000.0000.0000, mask=0000.0000.0000

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

Forward Flow based lookup yields rule:

in id=0xab56e078, priority=1, domain=permit, deny=false

hits=375991564, 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

Phase: 3

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

static (outside,inside) 1.1.1.177 10.1.3.77 netmask 255.255.255.255

match ip outside host 10.1.3.77 inside any

static translation to 1.1.1.177

translate_hits = 0, untranslate_hits = 141

Additional Information:

NAT divert to egress interface outside

Untranslate 1.1.1.177/0 to 10.1.3.77/0 using netmask 255.255.255.255

Phase: 4

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 10.1.0.0 255.255.0.0 inside

Phase: 5

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group inside_access in interface inside

access-list inside_access extended permit ip any any

Additional Information:

Forward Flow based lookup yields rule:

in id=0xab8d6900, priority=12, domain=permit, deny=false

hits=1965550, user_data=0xa8b144c0, cs_id=0x0, flags=0x0, protocol=0

src ip=0.0.0.0, mask=0.0.0.0, port=0

dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 6

Type: CONN-SETTINGS

Subtype:

Result: ALLOW

Config:

class-map class-default

match any

policy-map global_policy

class class-default

set connection decrement-ttl

service-policy global_policy global

Additional Information:

Forward Flow based lookup yields rule:

in id=0xab8b3000, priority=7, domain=conn-set, deny=false

hits=1992234, user_data=0xacbc9750, cs_id=0x0, flags=0x0, protocol=0

src ip=0.0.0.0, mask=0.0.0.0, port=0

dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 7

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in id=0xab56ebc0, priority=0, domain=inspect-ip-options, deny=true

hits=3020755, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0

src ip=0.0.0.0, mask=0.0.0.0, port=0

dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 8

Type:

Subtype:

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in id=0xacf23650, priority=17, domain=flow-export, deny=false

hits=1152312, user_data=0xad004220, cs_id=0x0, flags=0x0, protocol=0

src ip=0.0.0.0, mask=0.0.0.0, port=0

dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 9

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

static (inside,dmz) 10.1.0.0 10.1.0.0 netmask 255.255.0.0

match ip inside 10.1.0.0 255.255.0.0 dmz any

static translation to 10.1.0.0

translate_hits = 17798, untranslate_hits = 77556

Additional Information:

Forward Flow based lookup yields rule:

in id=0xace4f290, priority=5, domain=host, deny=false

hits=2923798, user_data=0xacf40cf8, cs_id=0x0, reverse, flags=0x0, protocol=0

src ip=10.1.0.0, mask=255.255.0.0, port=0

dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 10

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (inside) 1 0.0.0.0 0.0.0.0

match ip inside any outside any

dynamic translation to pool 1 (1.1.1.254 [Interface PAT])

translate_hits = 1882494, untranslate_hits = 193619

Additional Information:

Dynamic translate 10.1.7.100/2345 to 1.1.1.254/41106 using netmask 255.255.255.255

Forward Flow based lookup yields rule:

in id=0xab9763b0, priority=1, domain=nat, deny=false

hits=1883739, user_data=0xab9762f0, cs_id=0x0, flags=0x0, protocol=0

src ip=0.0.0.0, mask=0.0.0.0, port=0

dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 11

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

static (outside,inside) 1.1.1.177 10.1.3.77 netmask 255.255.255.255

match ip outside host 10.1.3.77 inside any

static translation to 1.1.1.177

translate_hits = 0, untranslate_hits = 141

Additional Information:

Forward Flow based lookup yields rule:

out id=0xace38270, priority=5, domain=nat-reverse, deny=false

hits=140, user_data=0xad0236f8, cs_id=0x0, flags=0x0, protocol=0

src ip=0.0.0.0, mask=0.0.0.0, port=0

dst ip=10.1.3.77, mask=255.255.255.255, port=0, dscp=0x0

Phase: 12

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

static (outside,inside) 1.1.1.177 10.1.3.77 netmask 255.255.255.255

match ip outside host 10.1.3.77 inside any

static translation to 1.1.1.177

translate_hits = 0, untranslate_hits = 141

Additional Information:

Reverse Flow based lookup yields rule:

in id=0xad001480, priority=5, domain=host, deny=false

hits=168, user_data=0xad0236f8, cs_id=0x0, reverse, flags=0x0, protocol=0

src ip=10.1.3.77, mask=255.255.255.255, port=0

dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 13

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Reverse Flow based lookup yields rule:

in id=0xab96b448, priority=0, domain=inspect-ip-options, deny=true

hits=3183895, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0

src ip=0.0.0.0, mask=0.0.0.0, port=0

dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 14

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 3343232, 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: outside

output-status: up

output-line-status: up

Action: allow

Any ideas? Thanks.

Re: bi-directional nat ok, tcp failing

sudbose — Wed, 29 Feb 2012 17:34:35 GMT

Please add the following commands to make it work:

# nat (inside) 1 0 0

# global (inside) 1 interface

# static (inside,inside) 1.1.1.177 10.1.3.77

# same-security-traffic permit intra-interface

/ Sudeep

Re: bi-directional nat ok, tcp failing

Collin Clark — Wed, 29 Feb 2012 19:13:35 GMT

Same results after making the above changes. Packet Tracer now shows

Phase: 9

Type: NAT

Subtype:

Result: DROP

Config:

nat (inside) 1 0.0.0.0 0.0.0.0

match ip inside any inside any

dynamic translation to pool 1 (No matching global)

translate_hits = 5, untranslate_hits = 0

Additional Information:

Forward Flow based lookup yields rule:

in id=0xacf3d288, priority=1, domain=nat, deny=false

hits=75, user_data=0xacf50698, cs_id=0x0, flags=0x0, protocol=0

src ip=0.0.0.0, mask=0.0.0.0, port=0

dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Re: bi-directional nat ok, tcp failing

haivrajesh — Wed, 29 Feb 2012 21:10:51 GMT

please enable dns re write then it will work

Rajeswar

Re: bi-directional nat ok, tcp failing

Collin Clark — Wed, 29 Feb 2012 21:19:18 GMT

The application uses the IP address and not a hostname.

Re: bi-directional nat ok, tcp failing

Maykol Rojas — Thu, 01 Mar 2012 06:19:54 GMT

From the top of my head, if you remember, statics do routing first than the routing table itself.... Check on this static:

Phase: 9

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

static (inside,dmz) 10.1.0.0 10.1.0.0 netmask 255.255.0.0

match ip inside 10.1.0.0 255.255.0.0 dmz any

static translation to 10.1.0.0

translate_hits = 17798, untranslate_hits = 77556

Additional Information:

Forward Flow based lookup yields rule:

in id=0xace4f290, priority=5, domain=host, deny=false

hits=2923798, user_data=0xacf40cf8, cs_id=0x0, reverse, flags=0x0, protocol=0

src ip=10.1.0.0, mask=255.255.0.0, port=0

dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Thats something that you should fix, however NOT the problem perse.

Based on what you are saying clients and server are internal which are on the range of 10.1.7.0/24 and the server is 10.1.3.77. So why are we seeing and outside connection being build?

Feb 28 2012 12:11:21: %ASA-6-302013: Built outbound TCP connection 3343090 for outside:10.1.3.77/80 (1.1.1.177/80) to inside:10.1.7.100/1221 (1.1.1.254/49099)

Basically because of the same reason I highlited the Phase 9 of the packet tracer. Even thou you have a route statement that says every 10 network should be routed to the inside, this static

static (outside,inside) 1.1.1.177 10.1.3.77 netmask 255.255.255.255

Is saying that 10.1.3.77 (based on the real interface which you claimed to be the outside). Now, it is really true that if you dont come out with some sort of static, this wont work properly because of two things

1-The dynamic nat which is taking 0 0 will need and will actually turn on nat control for a matter of speaking on the ASA, meaning everything will need to be translated

2-And second, but not less important, the firewall needs to route the packet and do the proper translation to send the packet when it is going back to the inside for someone asking for the public IP.

Now that being said and just to leave the theorical part aside remove the static as sundeep told you.

First of all, remove this

static (outside,inside) 1.1.1.177 10.1.3.77 netmask 255.255.255.255

From this point and forth you have two options depending on your needs.

1- If you need your clients on the far network (the one that is behind the layer 3 device, not sure it it is the 10.1.3 or the 10.1.7) anyhow, if you need that far end network NOT to do connections to the direcltly connected one, you can just add one command to the commands already given by sundeep, it would be just a global inside in order to avoid asymetric routing

Global (inside) 1 interface

You can give it a try, but it will definetly break something else.

2-The second option you have is just to use TCP state bypass for the two networks. The main issue you are facing right now is asymetric routing, so by just putting two self translations, leaving that static as it is, removing proxyarp on the inside, that will do the trick and will allow you back and forth connectivity between the two networks: Here is the config

sysopt noproxyarp inside

static (inside,inside) 1.1.1.177 10.1.3.77

static (inside,inside) 10.1.3.0 10.1.3.0

static (inside,inside) 10.1.7.0 10.1.7.0

access-list tcp_bypass permit tcp 10.1.3.0 255.255.255.0 10.1.7.0 255.255.255.0

access-list tcp_bypass permit tcp 10.1.7.0 255.255.255.0 10.1.3.0 255.255.255.0

class-map tcp_bypass

match access-list tcp_bypass

policy-map global_policy

class tcp_bypass

set connection advanced-options tcp-state-bypass

From the top of my head, giving those two different networks you have there you have something like this:

10.1.3.0----l3_Device-----10.1.7.0------ASA-----Internet

That being said, when the host 10.1.7.100 tries to initiate a connection to the server, it will go to the ASA (SYN), then the reply (SYN-ACK) will go directly to the 10.1.7.100 host, as the l3 device sees the 10.1.7.0 direclty connected and will send the packet directly to the host who tried to initiate the connection, the ASA on the other hand never saw that SYN-ACK packet, which will make the state table incomplete forcing the Firewall to drop the packet and never completing the 3 way handshake and the connection will timeout with a SYN timeout on the system log message. No matter what it is, if the server is the one directly connected or if it is the client that is directly connected, potato potato....

If you have any questions, feel free to throw them out.

Mike Rojas.

Re: bi-directional nat ok, tcp failing

Collin Clark — Thu, 01 Mar 2012 14:41:25 GMT

Thanks for your time Mike. The fix was adding Global (inside) 1 interface suggested by Sudeep.

Re: bi-directional nat ok, tcp failing

sudbose — Thu, 01 Mar 2012 15:00:53 GMT

Hi Colin,

Great to see that it is working fine. Still, I would recommend that you remove the following static as it is incorrectly defined.

# static (outside,inside) 1.1.1.177 10.1.3.77 netmask 255.255.255.255

Let us know if you have any questions regarding same.

/Sudeep