topic I need to make two ACL from in Network Security

Nat reverse path failure

mahesh18 — Tue, 12 Mar 2019 07:58:03 GMT

Hi everyone,

I have config bidirectional ACL from inside to DMZ

inside(10.71.35.245)----ASA-----DMZ(192.168.134.33) port 389

packet tracer works fine

and now I config ACL

DMZ(192.168.134.33)----------ASA-----------inside(10.71.35.245) port 51173

packet tracer shows

# packet-tracer input dmz tcp 192.168.134.33 1024 10.71.3$

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

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

Phase: 3
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 192.168.134.0 255.255.255.0 dmz

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group dmz in interface dmz
access-list dmz extended permit tcp host 192.168.134.33 10.71.35.245 eq 51173 log

Additional Information:

Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
static (inside,dmz) 192.168.134.72 10.71.35.245 netmask 255.255.255.255
match ip inside host10.71.35.245 dmz any
static translation to 192.168.134.72
translate_hits = 58509, untranslate_hits = 749704
Additional Information:

Result:
input-interface: dmz
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

Hi Maesh,

Kornelia Gutierrez — Wed, 29 Jun 2016 20:14:20 GMT

Hi Maesh,

The problem is related to the nat rules in place:

- You are telling the ASA that when inside host 10.71.35.245 tries to reach something on the dmz network, the host will be translated to 192.168.134.72. That is fine, the only inconvenient that you face is that when some host on the dmz tries to reach inside host 10.71.35.245 using its real ip address (the 10.71.35.245) the asa will check the the original path and the returning path to make sure the nat and routing is symmetric, so the scenario will look like this:

-From DMZ host 192.168.134.33 is trying to reach host 10.71.35.245

At this phase the firewall will check routing and ACL in place, it will forward the traffic towards the inside using the following information:

source 192.168.134.33

destination 10.71.35.245

-On the inside side host 10.71.35.245 will receive the traffic and it will respond to the dmz host and it will send the traffic to the ASA with the following information

source 10.71.35.245

destination 192.168.134.33

-At this point the packet enters the inside interface and the ASA starts checking routing, nat and acl information for host 10.71.35.245, and he realizes that there is a nat for that host when it goes to the dmz:

static (inside,dmz) 192.168.134.72 10.71.35.245 netmask 255.255.255.255

So he will try to nat host 10.71.35.245, but then he also check his connection table and he realizes that the connection is like this:

DMZ Inside

S 192.168.134.33 --- > D 10.71.35.245

what the ASA will expect as a reply or return traffic is the following:

Inside DMZ

S 10.71.35.245 --> D 192.168.134.33

However the nat is telling the ASA to translate host 10.71.35.245 to 192.168.134.72

So the attempted reply will look like this

S 192.168.134.72 (10.71.35.245 NAT´D IP) ---> D 192.168.134.33

The ASA realizes that the above is a different from what he is expecting the connection to be, the communication is meant between host 10.71.35.245 and 192.168.134.33 not between 192.168.134.72 (10.71.35.245 NAT´D IP) and 192.168.134.33, for that reason he notices that the return traffic flow is not the same and drops the packet.

In order to fix this, if you need to access from the DMZ side the inside host using its real ip address wich is 10.71.35.245 you will need to build another nat.

For example

access-list inhost permit ip host 10.71.35.245 host 192.168.134.33

static (inside,dmz) 10.71.35.245 access-list inhost

Make sure that the given rule is above of the following nat:

static (inside,dmz) 192.168.134.72 10.71.35.245 netmask 255.255.255.255

Hope this helps.

Thanks for very great and

mahesh18 — Thu, 30 Jun 2016 00:07:22 GMT

Thanks for very great and detailed explanation.

I already have ACL from DMZ to inside that allows source 192.168.134.33 to access inside host 10.71.35.245.

This ACL is applied on DMZ interface.

Which nat config should I use?

Regards

MAhesh

Hi Mahesh,

Kornelia Gutierrez — Thu, 30 Jun 2016 00:31:16 GMT

Hi Mahesh,

You are very welcome!

Take the following NAT as an example:

access-list inhost permit ip host 10.71.35.245 host 192.168.134.33

This acl is not applied in any interface, its purpose is to tell the ASA to not translate the inside host 10.71.34.245 only when is trying to communicate with 192.168.134.33.

static (inside,dmz) 10.71.35.245 access-list inhost

This type of nat is called static policy nat

so if I use this ACL and NAT

mahesh18 — Thu, 30 Jun 2016 00:52:34 GMT

so if I use this ACL and NAT then it should not cause any outage if traffic is flowing between host servers in DMZ

and inside right?

Another way

1>Can I use the ACL from DMZ to inside where destination IP is 192.168.34.72 instead of 10.71.35.245?

current NAT for traffic flow from inside to DMZ where packet tracer works fine is

Phase: 7
Type: NAT
Subtype:
Result: ALLOW
Config:
static (inside,dmz) 192.168.134.72 10.71.35.245 netmask 255.255.255.255
match ip inside host 10.71.35.245 dmz any
static translation to 192.168.134.72
translate_hits = 58509, untranslate_hits = 749693
Additional Information:
Static translate 10.71.35.245/0 to 192.168.134.72/0 using netmask 255.255.255.255

Phase: 8
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
static (inside,outside) 192.168.134.72 10.71.35.245 netmask 255.255.255.255
match ip inside host 10.71.35.245 outside any
static translation to 192.168.134.72
translate_hits = 0, untranslate_hits = 0
Additional Information:

Phase: 9
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 10
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 472116636, packet dispatched to next module

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

is there any nat config that I can use instead of using that ACL?

Regards

Mahesh

Hi Mahesh,

Kornelia Gutierrez — Thu, 30 Jun 2016 13:37:53 GMT

Hi Mahesh,

The nat should not cause an outage since is only meant betweent the specific inside and Dmz host.

The packet looks fine because in that example the connection is sourced by the inside, another thing you could do is try to access from the DMZ the 192.168.34.72 instead of the real ip address which is 10.71.35.245

Hi,

mahesh18 — Thu, 30 Jun 2016 13:59:27 GMT

Hi,

From inside to DMZ all is ok.

Can I use this ACL for traffic flow from DMZ to inside

1>Can I use the ACL from DMZ to inside where destination IP is 192.168.34.72 instead of 10.71.35.245?

Hi Mahesh,

Kornelia Gutierrez — Thu, 30 Jun 2016 19:11:58 GMT

Hi Mahesh,

Yes you can try that 😃

try that still no luck.

mahesh18 — Fri, 01 Jul 2016 01:08:24 GMT

try that still no luck.

when I try the policy nat it shows that address is used in static nat?

Is there any other way I can fix this?

Regards

Mahesh

I need to make two ACL from

mahesh18 — Sat, 02 Jul 2016 04:12:11 GMT

I need to make two ACL from DMZ to fix the issue

Regards

MAhesh