SNAT for multi WAN IP

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

SNAT for multi WAN IP

L0 Member

Hi All,

I have ISP provide 4 public IPs can be use.

But I can use 1 public ip to outbound traffic only., if i create another SNAT to 2nd public IP, it can't go out to internet.

 

e.g. Interface IP:  20.1.20.20/29

 

Not work NAT configuration 

 

NAT:

DMZ NAT : DMZ Source IP 10.1.10.0/24 to DIPP 20.1.20.21-20.1.20.22

APP SNAT: DMZ2 Source IP : 10.1.20.0/24 to SNAT 20.1.20.20 

 

Security :

DMZ and DMZ2 Any to Any Out Allow.

 

Working NAT Configuration

 

NAT:

DMZ NAT : DMZ Source to Untrust Any IP 10.1.10.0/24 to DIPP   20.1.20.20 

APP SNAT: DMZ2 Source to Untrust Any  IP : 10.1.20.0/24 to SNAT  20.1.20.20 

 

Security :

DMZ and DMZ2 Any to Any Out Allow.

 

I can see the traffic is allow.

How can I separate different subnet to use different workload WAN IP, which configuration am I missing?

 

Thanks.

 

1 accepted solution

Accepted Solutions

Cyber Elite
Cyber Elite

@jthk215,

When you look at the traffic logs you can add the columns for 'NAT Source IP' or go into the detailed log detail on a couple of the logs and verify that the proper NAT policy is actually being applied. You can also do this through the 'Test Policy Match' functionality available in the bottom right of the GUI when looking at your NAT policies, or through the CLI command 'test nat-policy-match' and verifying that your traffic is matching as expected.

Since sometimes people like to obfuscate information and end up actually hiding important information in that process, can you verify that the IP that you're attempting to NAT with actually falls into the subnet of the IP on the untrust interface. I know your example here does, but if it doesn't it explains the behavior that you're running into fully. If you NAT to an address that doesn't fall into a subnet of the IP on the untrust interface, you'll need to actually add a route for it. 

 

It's also important in instances like this that you actually share the NAT policy in a screenshot if you can. 

View solution in original post

1 REPLY 1

Cyber Elite
Cyber Elite

@jthk215,

When you look at the traffic logs you can add the columns for 'NAT Source IP' or go into the detailed log detail on a couple of the logs and verify that the proper NAT policy is actually being applied. You can also do this through the 'Test Policy Match' functionality available in the bottom right of the GUI when looking at your NAT policies, or through the CLI command 'test nat-policy-match' and verifying that your traffic is matching as expected.

Since sometimes people like to obfuscate information and end up actually hiding important information in that process, can you verify that the IP that you're attempting to NAT with actually falls into the subnet of the IP on the untrust interface. I know your example here does, but if it doesn't it explains the behavior that you're running into fully. If you NAT to an address that doesn't fall into a subnet of the IP on the untrust interface, you'll need to actually add a route for it. 

 

It's also important in instances like this that you actually share the NAT policy in a screenshot if you can. 

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