<?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 starting the GP linux client blocks inbound communication in GlobalProtect Discussions</title>
    <link>https://live.paloaltonetworks.com/t5/globalprotect-discussions/starting-the-gp-linux-client-blocks-inbound-communication/m-p/380513#M802</link>
    <description>&lt;P&gt;Hello.&amp;nbsp; I have a server that I use as a "bridge" that I use to keep a persistent VPN connection active to a restricted network, to extract report data.&amp;nbsp; We were previously using the openconnect client for the bridge, but recently, the secure network changed to use GlobalProtect.&amp;nbsp; When I tried to replace openclient with the linux GP client, something odd starting happening.&amp;nbsp; Typically, I ssh into the bridge server, and start up the vpn client, and then ping some of the restricted servers to make sure the vpn connection is running correctly.&amp;nbsp; This worked fine with openclient.&amp;nbsp; Now though, after establishing the ssh connection, and starting the GP client, my ssh session seems to become blocked, and any attempt to start a new ssh session also fails.&amp;nbsp; I left a little script running on the bridge server to see if the connection is being established ok, and it looks like it is, so it would appear that starting the connection is somehow preventing inbound connectivity.&amp;nbsp; Does the GP client enable/change inbound firewall rules or something?&amp;nbsp; The only way I can get back into the bridge server is to reboot the server, or possibly wait for the vpn connection to disconnect.&amp;nbsp; If it does start up some firewall rules, is there some way to allowlist specific subnets or something?&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Mon, 18 Jan 2021 14:36:56 GMT</pubDate>
    <dc:creator>chrisr</dc:creator>
    <dc:date>2021-01-18T14:36:56Z</dc:date>
    <item>
      <title>starting the GP linux client blocks inbound communication</title>
      <link>https://live.paloaltonetworks.com/t5/globalprotect-discussions/starting-the-gp-linux-client-blocks-inbound-communication/m-p/380513#M802</link>
      <description>&lt;P&gt;Hello.&amp;nbsp; I have a server that I use as a "bridge" that I use to keep a persistent VPN connection active to a restricted network, to extract report data.&amp;nbsp; We were previously using the openconnect client for the bridge, but recently, the secure network changed to use GlobalProtect.&amp;nbsp; When I tried to replace openclient with the linux GP client, something odd starting happening.&amp;nbsp; Typically, I ssh into the bridge server, and start up the vpn client, and then ping some of the restricted servers to make sure the vpn connection is running correctly.&amp;nbsp; This worked fine with openclient.&amp;nbsp; Now though, after establishing the ssh connection, and starting the GP client, my ssh session seems to become blocked, and any attempt to start a new ssh session also fails.&amp;nbsp; I left a little script running on the bridge server to see if the connection is being established ok, and it looks like it is, so it would appear that starting the connection is somehow preventing inbound connectivity.&amp;nbsp; Does the GP client enable/change inbound firewall rules or something?&amp;nbsp; The only way I can get back into the bridge server is to reboot the server, or possibly wait for the vpn connection to disconnect.&amp;nbsp; If it does start up some firewall rules, is there some way to allowlist specific subnets or something?&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 18 Jan 2021 14:36:56 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/globalprotect-discussions/starting-the-gp-linux-client-blocks-inbound-communication/m-p/380513#M802</guid>
      <dc:creator>chrisr</dc:creator>
      <dc:date>2021-01-18T14:36:56Z</dc:date>
    </item>
    <item>
      <title>Re: starting the GP linux client blocks inbound communication</title>
      <link>https://live.paloaltonetworks.com/t5/globalprotect-discussions/starting-the-gp-linux-client-blocks-inbound-communication/m-p/381009#M810</link>
      <description>&lt;P&gt;Apparently, starting up the GP client changes the routing tables on the box, blocking inbound connections.&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 20 Jan 2021 15:48:09 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/globalprotect-discussions/starting-the-gp-linux-client-blocks-inbound-communication/m-p/381009#M810</guid>
      <dc:creator>chrisr</dc:creator>
      <dc:date>2021-01-20T15:48:09Z</dc:date>
    </item>
    <item>
      <title>Re: starting the GP linux client blocks inbound communication</title>
      <link>https://live.paloaltonetworks.com/t5/globalprotect-discussions/starting-the-gp-linux-client-blocks-inbound-communication/m-p/381010#M811</link>
      <description>&lt;P&gt;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/168616"&gt;@chrisr&lt;/a&gt;,&lt;/P&gt;
&lt;P&gt;This depends entirely on how the folks running this secure network have configured GlobalProtect, and if it is in fact a secured network I would expect them to not allow local network access while the VPN is active. This is a pretty common configuration option, and I would expect that it's entirely intentional. That being said, it may be worth asking if it was intentional to see if they even realize that they checked that option. My guess is they know what they've done however.&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 20 Jan 2021 16:01:06 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/globalprotect-discussions/starting-the-gp-linux-client-blocks-inbound-communication/m-p/381010#M811</guid>
      <dc:creator>BPry</dc:creator>
      <dc:date>2021-01-20T16:01:06Z</dc:date>
    </item>
  </channel>
</rss>

