- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
05-13-2019 02:38 PM
im having big problem , after my remote vpn connects i cannot reach my internal network even though my core switch is directly connected to palo alto , i checked i set the access range for the vpn for 0.0.0.0/0 and i set a security rule from vpn zone to inside zone , also i can ping the inside interface on the firewall itself but not the directly connected core switch , when i check the traffic under monitor it all shows "aged out" , i even set a ip route to the vpn ip pool pointing to the inside of the firewall but with no use , im at a lose here
05-14-2019 12:01 AM
@chuckles: The GlobalProtect gateway is related to the vpn tunnel interface and so are the routes for the client ip pools.
You can do a traceroute from the switch (or a client behind the switch) to a vpn client and vice versa.
Then you got a clue, where the packets are misrouted.
You will have a transfer network between PA and your coreswitch - the transfernet address of the PA is the next hop for the VPN network from router view.
Do you use different virtual routers in your PA?
05-13-2019 02:52 PM
Hello,
Its a routing issue from the sounds of it. In the switch make sure it has a route to the PAN regarding the VPN subnet. Also in the PAN make sure you have routes for the VPN subnet as well.
Regards,
05-13-2019 03:05 PM
the switch can reach the inside interface of the PAN as the inside network can reach the internet , but i dont understand how do i make route in the pan for the vpn subnet? like the vpn ip pool have no interface? do you mean like give the tunnel interface an ip address in the same vpn ip pool addresses and set a static route for the vpn ip pool through the tunnel ip address?
05-14-2019 12:01 AM
@chuckles: The GlobalProtect gateway is related to the vpn tunnel interface and so are the routes for the client ip pools.
You can do a traceroute from the switch (or a client behind the switch) to a vpn client and vice versa.
Then you got a clue, where the packets are misrouted.
You will have a transfer network between PA and your coreswitch - the transfernet address of the PA is the next hop for the VPN network from router view.
Do you use different virtual routers in your PA?
07-25-2021 01:51 AM - edited 07-25-2021 01:56 AM
Can somebody check this?
admin@PA850-FW1(active)> show session id 117862
Session 117862
c2s flow:
source: 10.0.1.51 [SNS_VPN]
dst: 10.0.0.2
proto: 1
sport: 1 dport: 12088
state: INIT type: FLOW
src user: vpn_user1
dst user: unknown
s2c flow:
source: 10.0.0.2 [SNS Trust]
dst: 10.0.1.51
proto: 1
sport: 12088 dport: 1
state: INIT type: FLOW
src user: unknown
dst user: vpn_user1
pbf rule: Web Access 1
start time : Sun Jul 25 13:27:24 2021
timeout : 6 sec
total byte count(c2s) : 74
total byte count(s2c) : 74
layer7 packet count(c2s) : 1
layer7 packet count(s2c) : 1
vsys : vsys1
application : ping
rule : GPZone_to_SNS_Zone
service timeout override(index) : False
session to be logged at end : True
session in session ager : False
session updated by HA peer : False
layer7 processing : enabled
URL filtering enabled : False
session via syn-cookies : False
session terminated on host : False
session traverses tunnel : True
session terminate tunnel : False
captive portal session : False
ingress interface : tunnel.1
egress interface : ae1
session QoS rule : N/A (class 4)
tracker stage firewall : Aged out
end-reason : aged-out
What I am missing here?
I can ping internal (trust) PA interface IP (10.0.0.254) from VPN connected host, but any host from the 10.0.0.x network is unreachable. 10.0.0.254 is the default GW.
07-25-2021 04:30 AM
Do you see arp entries for these hosts in the 10.0.0.0/24 subnet on the firewall? Do these IPs respond to ping? Are you able to ping these IPs directly from the firewall?
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!