- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
12-15-2023 05:21 AM
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.
12-15-2023 09:51 PM
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.
12-15-2023 09:51 PM
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.
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!