Bi-directional NAT is still requiring a /32 static route

[nthen]

I have two VPN tunnels established with a vendor.  1 is in San Digeo and 1 is in Las Vegas.  The subnet in SD uses 10.220.1.0/24 and LV uses 10.220.2.0/24.  With both tunnels they want me to NAT my IP of 172.16.1.235 to 10.200.249.30.  I have a NAT statement configured that says to NAT all traffic coming from zone Inside to zone VPN Tunnels coming from my IP to both of the remote subnets to the 10.200.249.30.  My security policy right now says to allow any > any both ways.  I added 2 static routes in my virtual router for both subnets.

I can ping all addresses in San Diego and Vegas without issue and the NAT translation is working.  When my vendor tries to ping me the request times out.  They can ping me from both data centers only if I add 10.200.249.30/32 using one of the tunnel interfaces as a static route.  It doesn't matter if I use tunnel.8 or tunnel.9 for the static route.  It seems as long as the 10.200.249.30 is in the routing table pings will go through from them.

Has anyone seen this behavior?  Is this the proper way to get this to work or so I need to use some type of alternate interface to pin the NAT'd IPs to?  Or should this not be happening at all and there is a software bug somewhere?

[uscit]

do you have Ping enabled in the Management Profile on the interface(s) that they cannot ping you on?

[nthen]

No traffic could pass through the tunnel from the vendor to me until I added the route.  However it worked 100% the other way

[ckindel · Accepted solution]

The behavior you described is expected.

When you create a bi-directional NAT policy there are actually two policies that are added to the running NAT database. 

NAT policy configured:

Two NAT policies in database:

example {

        from Inside;

        source 172.16.1.235;

        to VPN Tunnels;

        to-interface  ;

        destination [ 10.220.1.0/24 10.220.2.0/24 ];

        service  any/any/any;

        translate-to "src: 10.200.249.30 (static-ip) (pool idx: 5)";

        terminal no;

}

example {

        from any;

        source any;

        to VPN Tunnels;

        to-interface  ;

        destination 10.200.249.30;

        service  any/any/any;

        translate-to "dst: 172.16.1.235";

        terminal no;

}

The ingress zone used in the NAT policy look up is, of course, determined by the interface on which packet was received. The egress zone is determined by the routing table.  When you pinged the vendor this worked fine: the firewall received a packet on the 'Inside' interface destined to an address specified in one of the static routes pointing across your tunnels, so it was able to determine the destination zone as 'VPN Tunnels' based on the routing table.  This would match the first rule.  However, when the vendor tried to ping you, the firewall received a packet from the tunnel, so the ingress interface was 'VPN Tunnels', but when it attempted to look up the destination zone the only route that matched was the default, so it would be associated with your 'Untrust' zone and would not match the second NAT rule, causing the ping to fail.

Ultimately, the firewall needs a route in order to determine egress interface and destination zone, so creating a static route pointing to the tunnel is a valid option in this scenario.

Alternately, you could make your current NAT policy uni-directional and explicitly create the NAT policy for traffic from the vendors, specifying source zone of VPN Tunnels and destination zone Any, along with the other criteria. Then you could remove the static route, as you wouldn't need to determine the destination zone.  Personally, I would configure it this way because it is easier to understand.

Let me know if this helps clarify things.

[nthen]

Perfect!  That helps a lot.  Thanks for your response.