- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
10-27-2022 02:24 AM - edited 10-27-2022 02:26 AM
Hello,
I'm having trouble setting this up correctly.
We have eth1/2 where a PPPoE Connection is available that we use for Internet Traffic from our guest wifi.
We also have eth1/14 where our main Connection is running.
We have a GP Configuration which allows external Users to connect to via an external IP Address which is then NATted to the internal IP, which works great from anywhere BUT the PPPoE on the eth1/2 interface from the palo.
Due to an ISP switch from our main provider I moved all the external services to new ip addresses. Everything is working fine from external and internal, just the NATting from the guest net on eth1/2 does not. Before the ISP switch on the old external GP IP this worked.
The Setup from internal guest net:
1. Connect Notebook to guest wifi going out via PPPoE on eth1/2 using Google DNS 8.8.8.8 to resolve our FQDN for the GP Adress - it resolves to the new IP
2. Have a destination NAT rule from source guest and WAN zone to destination WAN pointing to eth1/14 where the new ISP connection is which translates the public GP IP to the internal IP
3. The NAT policy gets hit and i see traffic coming from the public IP of the PPPoE connection to our external GP IP which does not get blocked because its allowed by a corresponding security rule but the a ping just times out
4. The traffic I see has source eth1/14 and I see the NAT source IP as the public IP from the PPPoE connection from eth1/2
There is no traffic blocking at this stage, it's all allowed.
The NAT Session data looks like this (eth1/12) is a DMZ zone where the GP Portal is located.
I had to censor a few things, I hope it's still understandable.
Session 848193
c2s flow:
source: 212.110.XXX.XX [WAN]
dst: 93.159.XXX.XXX
proto: 1
sport: 8720 dport: 11
state: INIT type: FLOW
src user: unknown
dst user: unknown
s2c flow:
source: 192.168.50.1 [XX-Client-VPN]
dst: 212.110.XXX.XX
proto: 1
sport: 11 dport: 8720
state: INIT type: FLOW
src user: unknown
dst user: unknown
start time : Wed Oct 26 13:22:37 2022
timeout : 6 sec
total byte count(c2s) : 98
total byte count(s2c) : 0
layer7 packet count(c2s) : 1
layer7 packet count(s2c) : 0
vsys : vsys1
application : ping
rule : From-Any-To-GlobalProtect
service timeout override(index) : False
session to be logged at end : True
session in session ager : False
session updated by HA peer : False
address/port translation : source + destination
nat-rule : XXX - GlobalProtect NAT Policy(vsys1)
layer7 processing : enabled
URL filtering enabled : True
URL category : any
session via syn-cookies : False
session terminated on host : True
session traverses tunnel : False
session terminate tunnel : False
captive portal session : False
ingress interface : ethernet1/14
egress interface : ethernet1/12
session QoS rule : N/A (class 4)
tracker stage firewall : Aged out
end-reason : aged-out
We still have the old ISP on eth1/1 and we have the same NAT rule in place as for eth1/14 just the external IP of the GP is different. With this IP the traffic goes directly from the Guest Zone to the Zone where the GP Portal is located and I do not understand why. So with the old IP the same Setup works, but I dont understand why it's not going over the WAN connection?
Here is the NAT session to the old external IP:
Session 970134
c2s flow:
source: 10.0.106.220 [XX-Guest]
dst: 195.37.XX.XXX
proto: 1
sport: 11536 dport: 22
state: INIT type: FLOW
src user: unknown
dst user: unknown
s2c flow:
source: 192.168.50.1 [XX-Client-VPN]
dst: 10.0.106.220
proto: 1
sport: 22 dport: 11536
state: INIT type: FLOW
src user: unknown
dst user: unknown
start time : Wed Oct 26 13:24:24 2022
timeout : 6 sec
total byte count(c2s) : 98
total byte count(s2c) : 98
layer7 packet count(c2s) : 1
layer7 packet count(s2c) : 1
vsys : vsys1
application : ping
rule : From-Any-To-GlobalProtect
service timeout override(index) : False
session to be logged at end : True
session in session ager : False
session updated by HA peer : False
address/port translation : source + destination
nat-rule : GlobalProtect NAT Policy(vsys1)
layer7 processing : enabled
URL filtering enabled : True
URL category : any
session via syn-cookies : False
session terminated on host : True
session traverses tunnel : False
session terminate tunnel : False
captive portal session : False
ingress interface : ethernet1/11
egress interface : ethernet1/12
session QoS rule : N/A (class 4)
tracker stage firewall : Aged out
end-reason : aged-out
As you can see it directly uses eth1/11 as ingress (which is the guest net) and goes directly to eth1/12 and I don't understand why, can anyone help me out?
11-14-2022 11:12 PM
Hey,
sorry, I didn't write my solution to this.
To preface this, we had an ISP switch, so we got a new block of external IPs.
It was a failure on my end. We had both zones connected to a Virtual Router and I had a Policy Based Forwarding setup for my guest zone so that they were routed via a secondary ISP. In that PBF I had a negated entry for our external IP addresses that changed with our new ISP. So the issue was that I did not negate our new external IP addresses that I used, for example, for the GP Gateway. I hope that makes sense.
Thanks for your answers!
11-14-2022 10:55 AM
Hi,
I'm pretty confused by this. Happy to take a look but could you please sketch a diagram showing interfaces/zones/ip addresses to help us understand the topology?
Please also provide screenshots of your NAT policy.
Cheers,
Shannon
11-14-2022 12:37 PM
Hello @Falk-Schneider
Create a No NAT rule, no-nat rule for traffic from the Internal o internals zones networks to the public IP address of the firewall ( The IP Public you use for GlobalProtect Portal / Gateway ). Then you can connecto to global protect from internal notework without problems.
Cheers
11-14-2022 11:12 PM
Hey,
sorry, I didn't write my solution to this.
To preface this, we had an ISP switch, so we got a new block of external IPs.
It was a failure on my end. We had both zones connected to a Virtual Router and I had a Policy Based Forwarding setup for my guest zone so that they were routed via a secondary ISP. In that PBF I had a negated entry for our external IP addresses that changed with our new ISP. So the issue was that I did not negate our new external IP addresses that I used, for example, for the GP Gateway. I hope that makes sense.
Thanks for your answers!
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!