Static nat commit warning valid...?

[Rjschultz]

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

[mikand]

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)

[CafNetMatt]

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!

[mikand · Accepted solution]

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

[CafNetMatt]

Thank you.  That explains it well.