<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: SNAT for multi WAN IP in General Topics</title>
    <link>https://live.paloaltonetworks.com/t5/general-topics/snat-for-multi-wan-ip/m-p/570139#M114912</link>
    <description>&lt;P&gt;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/147193717"&gt;@jthk215&lt;/a&gt;,&lt;/P&gt;
&lt;P&gt;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.&lt;/P&gt;
&lt;P&gt;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,&amp;nbsp;&lt;EM&gt;but&amp;nbsp;&lt;/EM&gt;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.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;It's also important in instances like this that you actually share the NAT policy in a screenshot if you can.&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Sat, 16 Dec 2023 05:51:27 GMT</pubDate>
    <dc:creator>BPry</dc:creator>
    <dc:date>2023-12-16T05:51:27Z</dc:date>
    <item>
      <title>SNAT for multi WAN IP</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/snat-for-multi-wan-ip/m-p/570057#M114906</link>
      <description>&lt;P&gt;Hi All,&lt;/P&gt;
&lt;P&gt;I have ISP provide 4 public IPs can be use.&lt;/P&gt;
&lt;P&gt;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.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;e.g. Interface IP:&amp;nbsp; 20.1.20.20/29&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Not work NAT configuration&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;NAT:&lt;/P&gt;
&lt;P&gt;DMZ NAT : DMZ Source IP 10.1.10.0/24 to DIPP &lt;STRONG&gt;20.1.20.21-20.1.20.22&lt;/STRONG&gt;&lt;/P&gt;
&lt;P&gt;APP SNAT: DMZ2 Source IP : 10.1.20.0/24 to SNAT 20.1.20.20&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Security :&lt;/P&gt;
&lt;P&gt;DMZ and DMZ2 Any to Any Out Allow.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Working NAT Configuration&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;NAT:&lt;/P&gt;
&lt;P&gt;DMZ NAT : DMZ Source to Untrust Any IP 10.1.10.0/24 to DIPP&amp;nbsp; &amp;nbsp;&lt;STRONG&gt;20.1.20.20&lt;/STRONG&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;APP SNAT: DMZ2 Source to Untrust Any&amp;nbsp; IP : 10.1.20.0/24 to SNAT&amp;nbsp; 20.1.20.20&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Security :&lt;/P&gt;
&lt;P&gt;DMZ and DMZ2 Any to Any Out Allow.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;I can see the traffic is allow.&lt;/P&gt;
&lt;P&gt;How can I separate different subnet to use different workload WAN IP, which configuration am I missing?&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Thanks.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Fri, 15 Dec 2023 13:21:57 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/snat-for-multi-wan-ip/m-p/570057#M114906</guid>
      <dc:creator>jthk215</dc:creator>
      <dc:date>2023-12-15T13:21:57Z</dc:date>
    </item>
    <item>
      <title>Re: SNAT for multi WAN IP</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/snat-for-multi-wan-ip/m-p/570139#M114912</link>
      <description>&lt;P&gt;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/147193717"&gt;@jthk215&lt;/a&gt;,&lt;/P&gt;
&lt;P&gt;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.&lt;/P&gt;
&lt;P&gt;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,&amp;nbsp;&lt;EM&gt;but&amp;nbsp;&lt;/EM&gt;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.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;It's also important in instances like this that you actually share the NAT policy in a screenshot if you can.&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Sat, 16 Dec 2023 05:51:27 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/snat-for-multi-wan-ip/m-p/570139#M114912</guid>
      <dc:creator>BPry</dc:creator>
      <dc:date>2023-12-16T05:51:27Z</dc:date>
    </item>
  </channel>
</rss>

