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

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

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

L3 Networker

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?

1 accepted solution

Accepted Solutions

L3 Networker

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:

bi-directional_NAT.png

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.

View solution in original post

4 REPLIES 4

Not applicable

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

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

L3 Networker

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:

bi-directional_NAT.png

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.

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

  • 1 accepted solution
  • 3555 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!