Static nat commit warning valid...?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Static nat commit warning valid...?

Not applicable

When I commit my configuration, I am currently getting the following commit warning:

· - Rule '<public ip removed>-snat' shadows rule '<public ip removed>-snat'

I know why I am getting this and its because I have 2 bi-directional static source NATs with 2 different public IPs that go to the same internal IP.  I understand that in the outbound direction, the lower rule will shadow the higher rule, but in the inbound direction, nothing will be shadowed and the 2 external IPs will go to the same internal IP just fine. 

My question is this:  1. Is there a way to remove this warning since we understand the shadowing and the configuration is accomplishing our requirements.

     2. Is there a better way to accomplish what we need which does not give us the warning?

Thank you.

-Johnny Schultz

1 accepted solution

Accepted Solutions

If im not mistaken the NAT rules are session based.

Meaning "host2, snat to x.x.x.x" wont collide with "x.x.x.x dnat to host1".

The good side (at least IMHO) of doing this manually for each direction is that it will be more visible whats actually going on.

If you use bi-directional it will depend on in which order you wrote the nat-rules because:

1) host1, snat to x.x.x.x, bi-directional

2) host2, snat to x.x.x.x, bi-directional

wont be the same result as

1) host2, snat to x.x.x.x, bi-directional

2) host1, snat to x.x.x.x, bi-directional

because the above case can be extracted into:

1) host2, snat to x.x.x.x

1.5) x.x.x.x dnat to host2 (hidden)

2) host1, snat to x.x.x.x

2.5) x.x.x.x dnat to host1 (hidden)

and since PA is top-down first-match any new sessions setup towards x.x.x.x will always be forwarded to host2 (until some admin some day unchecks the bidirectional checkbox and suddently host1 gets all incoming traffic (if there is a security policy that allows that).

View solution in original post

4 REPLIES 4

L6 Presenter

I think if you untick the "bidirectional" stuff and instead manually setup the outbound snat you should be fine.

I mean instead of (which I understand your nat currently is setup as):

1) host1, snat to x.x.x.x, bi-directional

2) host2, snat to x.x.x.x, bi-directional

set it up as:

1) host1, snat to x.x.x.x

2) host2, snat to x.x.x.x

3) x.x.x.x dnat to host1 (or which of the two hosts you wish inbound sessions to be sent to)

I have the same issue and am wondering what the effect is.  Basically, the client is using an ISA server on the inside to authenticate inbound access to web resources.  So, the client has multiple public IPs that are translated to the same internal IP.

If I set NAT up the way you recommend what would be the ramifications?  Traffic coming in is coming from 1 public IP and going out on another.  I realize this is how its going to work anyway but this is a config that's being migrated from another firewall so I haven't tested it yet to see what the consequences are.

Thanks!

If im not mistaken the NAT rules are session based.

Meaning "host2, snat to x.x.x.x" wont collide with "x.x.x.x dnat to host1".

The good side (at least IMHO) of doing this manually for each direction is that it will be more visible whats actually going on.

If you use bi-directional it will depend on in which order you wrote the nat-rules because:

1) host1, snat to x.x.x.x, bi-directional

2) host2, snat to x.x.x.x, bi-directional

wont be the same result as

1) host2, snat to x.x.x.x, bi-directional

2) host1, snat to x.x.x.x, bi-directional

because the above case can be extracted into:

1) host2, snat to x.x.x.x

1.5) x.x.x.x dnat to host2 (hidden)

2) host1, snat to x.x.x.x

2.5) x.x.x.x dnat to host1 (hidden)

and since PA is top-down first-match any new sessions setup towards x.x.x.x will always be forwarded to host2 (until some admin some day unchecks the bidirectional checkbox and suddently host1 gets all incoming traffic (if there is a security policy that allows that).

Thank you.  That explains it well.

  • 1 accepted solution
  • 3205 Views
  • 4 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!