When establishing a connection via PPPOE there is no possibility to select the IP ("None") assigned by ISP in the Global Protect portal configuration, only the interface, which is not sufficient for it to work. I would expect that the IP assigned by ISP is created as an dynamic address object.
To make GP work with portal & gateway, I had to create a loopback, then doing a NAT from the pppoe interface's (in my case eth1/1) ip:some other port not being 443 to the loopback:443. I had to create an additional address object where I manually had to put in the dynamic ip. I now have to amend this address object manually every time the interface ip changes. Am I missing something here or is it really this cumbersome using PPPOE?
It seems PAN is not that much interested in supporting PPPOE connections- besides this, there is also lack of vlan tagging support once the L3 interface has been set to PPPOE which many ISPs require and no option for a scheduled reconnection.
This should be work with 'None' in IP address field.
Here is my testbed (sorry, mine is dhcp client - not pppoe)
With above interface, if I configure GP as below...
The device recognizes IP address which retrieved from ISP.
admin@PA-220> debug ssl-vpn global-protect-portal
portal : gptest
portal address IPv4 : 58.156.1xx.xxx
admin@PA-220> debug ssl-vpn global-protect-gateway
gateway : gptest
gateway address (IPv4 Only) : 58.156.1xx.xxx
after having spent two whole days on the topic of getting the GP-gateway up and running to connect via androids native ipsec client on a PPPoE interface with dynamically assigned IP...I gave up... and can confirm:
1.) 'cumbersome' is an euphemism
2.) the 'solution' presented herein does not work for scenarios with dynamically assigned IP via PPPoE
3.) selecting 'none' IP in GP-gatway config will not work in this scenario -> the paloalto PA220 (SW Ver. 10.1.4) will not respond to IKE traffic on the PPPoE interface (captured via a transparent linux bridge on respective WAN uplink)
4.) I also tried Pan219s trick with NATting the ipsec traffic to a loopback interface with a static IP on which the GP-portal would reside with the modification of using the FQDN destination object of my WANs DDNS address in my NAT-rules' 'original packet' section. Here I had the problem that the FQDN object was not reliably translated and suddenly reported that it had 'no value assigned'.
After all I share the impression that paloalto really does not pay too much attention to these SOHO scenarios, i.e. the lack of VLAN support, the DDNS implementation (had to use a linux box behind the palo to update my DDNS provider with firewalls external address) and now the non-functional GP-portal.
I don't want to put another router in front of the palo just to get the GP-portal up and running.
How are chances to get above functionalities implemented/fixed? Or anybody around with some virtuos workaround?
Any help would be highly appreciated.
after some fiddling and trial an error I found the solution. Initially I also tried the fqdn workaround you mentioned above, also no success. The breakthrough: Instead of using an address object limited to the assigned WAN IP I have created an address object with the ip range 0.0.0.0/0 which is used in any rules (NAT as well as Security Policy).
That's the only change I have made to the original setup. Lo and behold, this configuration works flawlessly since 2 years.
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!