<?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 PPPoE and GlobalProtect Issues in GlobalProtect Discussions</title>
    <link>https://live.paloaltonetworks.com/t5/globalprotect-discussions/pppoe-and-globalprotect-issues/m-p/568430#M4706</link>
    <description>&lt;P&gt;Hi everyone,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Hoping someone could tell me where I'm going wrong with this.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;We have recently acquired a secondary ISP line which is connected to our PA's eth1/1 via PPPoE, which includes /28 available IPs. I am looking at moving one of our client's GlobalProtect portal and gateway from our primary ISP line (Which is via static IP) to the secondary's .162/28 public IP is the public IP in particular. I attempted this migration last night and stumbled on issues.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;The PPPoE public IP is set to .175/28. The ISP has set it so that this is the CPE IP, without me having to manually set a static IP on eth1/1.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;What I simply attempted was changing the GP's loopback, NAT, and security policy addresses to that of the new IP (.162/28). Then when attempting to browse to the portal on HTTPS, I see the traffic coming into eth1/1 on 162/28 (seeing loopback.2 as destination interface correctly), but aging out. So it seems for some reason to not know how to reach the portal. I note that it works if I set the GP address to the eth1/1 CPE address (175/28).&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;I'm at odds at where I'm going wrong here. It works fine via static IP but not PPPoE. Any ideas are appreciated.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Many thanks!&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Tue, 05 Dec 2023 14:25:32 GMT</pubDate>
    <dc:creator>JaredBaglietto</dc:creator>
    <dc:date>2023-12-05T14:25:32Z</dc:date>
    <item>
      <title>PPPoE and GlobalProtect Issues</title>
      <link>https://live.paloaltonetworks.com/t5/globalprotect-discussions/pppoe-and-globalprotect-issues/m-p/568430#M4706</link>
      <description>&lt;P&gt;Hi everyone,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Hoping someone could tell me where I'm going wrong with this.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;We have recently acquired a secondary ISP line which is connected to our PA's eth1/1 via PPPoE, which includes /28 available IPs. I am looking at moving one of our client's GlobalProtect portal and gateway from our primary ISP line (Which is via static IP) to the secondary's .162/28 public IP is the public IP in particular. I attempted this migration last night and stumbled on issues.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;The PPPoE public IP is set to .175/28. The ISP has set it so that this is the CPE IP, without me having to manually set a static IP on eth1/1.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;What I simply attempted was changing the GP's loopback, NAT, and security policy addresses to that of the new IP (.162/28). Then when attempting to browse to the portal on HTTPS, I see the traffic coming into eth1/1 on 162/28 (seeing loopback.2 as destination interface correctly), but aging out. So it seems for some reason to not know how to reach the portal. I note that it works if I set the GP address to the eth1/1 CPE address (175/28).&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;I'm at odds at where I'm going wrong here. It works fine via static IP but not PPPoE. Any ideas are appreciated.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Many thanks!&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 05 Dec 2023 14:25:32 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/globalprotect-discussions/pppoe-and-globalprotect-issues/m-p/568430#M4706</guid>
      <dc:creator>JaredBaglietto</dc:creator>
      <dc:date>2023-12-05T14:25:32Z</dc:date>
    </item>
    <item>
      <title>Re: PPPoE and GlobalProtect Issues</title>
      <link>https://live.paloaltonetworks.com/t5/globalprotect-discussions/pppoe-and-globalprotect-issues/m-p/568453#M4707</link>
      <description>&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-center" image-alt="Capture2.PNG" style="width: 804px;"&gt;&lt;img src="https://live.paloaltonetworks.com/t5/image/serverpage/image-id/55672i37A1DAAD0239B016/image-size/large/is-moderation-mode/true?v=v2&amp;amp;px=999" role="button" title="Capture2.PNG" alt="Capture2.PNG" /&gt;&lt;/span&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 05 Dec 2023 16:23:16 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/globalprotect-discussions/pppoe-and-globalprotect-issues/m-p/568453#M4707</guid>
      <dc:creator>JaredBaglietto</dc:creator>
      <dc:date>2023-12-05T16:23:16Z</dc:date>
    </item>
    <item>
      <title>Re: PPPoE and GlobalProtect Issues</title>
      <link>https://live.paloaltonetworks.com/t5/globalprotect-discussions/pppoe-and-globalprotect-issues/m-p/569015#M4715</link>
      <description>&lt;P&gt;Anyone, please?&lt;/P&gt;</description>
      <pubDate>Fri, 08 Dec 2023 08:33:44 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/globalprotect-discussions/pppoe-and-globalprotect-issues/m-p/569015#M4715</guid>
      <dc:creator>JaredBaglietto</dc:creator>
      <dc:date>2023-12-08T08:33:44Z</dc:date>
    </item>
  </channel>
</rss>

