Hi @DongQu ,   Most probably you don't have constant traffic running for both remote networks. If you see both active at different time this means negotiation is successfull for both and if there is real traffic tunnel should be fine. ... View more

Hi @LCMember20111    Yes, you don't need no-nat rule. The fact that you don't have default hide NAT makes you solid. It is good approach to have separate zone for each tunnel if this device is deisgnated as VPN concentrator. ... View more

Hi @JamesHamilton    Your NAT is correct and you still need it in order to have reply back via the correct ISP. But you still need routing. Think about it - routing desicions is based on the destination address. If you change/NAT the source IP of the packet that wouldn't make any difference for the route lookup.   I noticed in your NAT rule that you have specific Internet IPs as destination. If you have limit number of addresses that you already know you can simply create static routes for those hosts pointing the next-hop via eth1/6, next to your default pointing to eth1/5. But this approach can quickly because hard to manage if you start adding more and more addresses that needs to be routed via secondary ISP - eth1/6. This is where the PBF come in handy. With PBF you can tell that anything sourced from these four addresses, to any destination should be routed via eth1/6 (you can even specify ports based on your requirements). In this case you don't need to create multiple host static routes pointing to eth1/6.   Read more in the document from @BPry  ... View more

Hi @shrikant, I would strongly suggest you to start using Home : Beacon (paloaltonetworks.com)  There are tones of studing materials and most of them are free to access.   If you run virtual firewall without license you will not be able to use any of the "deep inspection" features (like IPS, AV, etc) and also the number of concurrent connections is limited. You wouldn't see any log enrty again because you don't have license. But for complete beginner as you will be still great, because you can poke with everything and test the basic stuff like routing, nat and basic layer4 rules (you may even run remote access vpn).   Register to the Beacon and without virtual FW beside you I believe most of your questions will be answered. ... View more

Hi @LCMember20111 ,   The answer really depends on your setup. You need to understand why NONAT was required for Cisco ASA to understand why it may not be required for PAN FW.   As you may know ASA was implementing the "policy based" VPN. This means that traffic for the tunnel is still routed to your outside/untrusted zone, but before leaving ASA is checking "the policy" (the crypto map) if this traffic needs to encrypted with ipsec or not. But you still have your hide NAT that will translate any source leaving through the outside/untrusted zone/interface. I hope you see the problem - VPN and Internet traffic are associated with same interface, so you need to have the no-nat exception to tell traffic doesn't need hide nat.   Palo Alto FWs on other hand apply "route based" VPN, so you need to create logical interface associated with that IPsec tunnel. You can abstract from the IPsec for a moment and treat this interfacase as any other physical interface. You associate this tunnel interface with a zone and you can have static routes and rules to and for that zone. If you put the tunnel inteface in zone separate from the outside/untrusted you will not need NO-NAT rule - why? Because the default hide NAT rule will not match this traffic. PAN FW security and NAT rules are matching source and destination zone (based on route lookup). So when you try to go to internet destination zone will match your default route and will match your default hide nat. But if you try to reach something over the ipsec, your destination zone will be different, because the static route is pointing to the tunnel and that tunnel is in different zone. You don't have to excplicetly tell the firewall that these are different - they already are, because they are related to different zones.   If you put the VPN tunnel interface in the same zone as your unstrusted/outside (which you may see as recommended in some very old PAN documents), that you way need the no-nat. But still really depends, if you configure your default hide nat with destination zone and destination interface, your vpn traffic will still not match the hide nat, because fw will see that destination interface is the logical tunnel and not your public interface.   Because NAT policy become much more easy to manage and because of the "Zero-Trust approach" you may consider creating separate zone for each IPsec tunnel, phyiscal or sub-interface. Some time ago I tend to put all IPsec tunnels into single "IPsec-VPN" zone, which could be fine if you have tones of IPsec tunnels on small box (limited numbers of zones), but not that often anymore (it is hard to come up with zone names thou) ... View more

@DongQuin suche case wher you have complete overlapping between local and remote networks, both sides of the tunnel must apply natting. Which means: - Each side will use the remote NAT network (users should know the IP 2.2.2.2 in order to connect to remote side) - Each side should apply NAT for its local network So I assume that the config on ASA side will be handled and we speaking only from your side. You will need: - static route for remote nat network pointing to tunnel interface (in your case route for 2.2.2.2 to tunnel.1) - NAT rule maching local network/host 10.10.10.10 from your internal zone, to vpn zone (use separate zone instead of your internet untrust/outside zone) and applying static source NAT. You can enable the bi-directional option to automatically create NAT rule when remote side needs to initiate traffic to you. - Or if you don't use bi-directional in the source nat, you need to create additional nat rule matching source remote nat network, to your local nat network applying destination nat (src: 2.2.2.2 to 1.1.1.1, apply destination nat to 10.10.10.10) -  For the rules you need to remember that security rules are using Post-NAT zones and Pre-NAT address: This means that for the     - outbound rule you need to allow your local address to remote nat ip     - inbound rule you need to allow remote nat address to your local nat address ... View more

Hi @Kevin234    GlobalProtect 4.1 is officialy end of life so you may consider upgrading to newer version 5.1 and above (if you don't search for new features I would suggest yuo to stick with 5.1). That being said error message you receive usually indicates what is actually said - the SSL certificated that is installed on the firewall that you use for GP gateway is invalid. If you said you was able to use it was week it is possible that the ceritifcate has expired.   The easiest and quickest way to check the certificate is to open the address that you use to connect with web browsers (it is not always the case, but usually the certificate that you will see in the web browser will be the same that GlobalProtect will receive when establishing the tunnel). If you browser trust the provided certificate so the GP will. If there is an issue with the ceritifate (either it is expired or signed by untrsuted authority or something else) you will receive warning message and the padlock next the URL in your browser will say the connection is not secure.   Do you manage the firewall that is being used for the GlobalProtect VPN or someone else?   ... View more

Hi @bambox  - What is the application in your error message? - Do you have the latest dynamic package upate installed? - If you copy the name of the problematic application and search it with the Global Search in the GUI do you find it anywhere used? - Do you use Panorama like the previous post? If yes have you compared the dynamic updates between the Panorama and the problematic firewalls? ... View more

Hi @mjensen40400  Try to check the global counters as described here - How to check global counters for a specific source and destinat... - Knowledge Base - Palo Alto Networks - Set the same filter you have set for the packet capture - Run the command >show counter global filter packet-filter yes delta yes (note that with the option delta the output will show only the difference between last and previous execution of the show command. ) ... View more

Hi @jsafranek ,   You don't have to anything from your side. It all up to the ISP to properly route the new /29. - Because your firewall have assigned IP in the /27 when ISP needs to route traffic to your ISP will ask who has the MAC address of <your-fw-ip> and send the traffic directly - Now the new /29 is not assigned anywhere (and there is no need). So in ISP gateway needs to know how to reach this network. For which they need to create static route pointing to your firewall, an IP that will reply to the ARP request.   To put it simple: - Your IP needs to create route on their end for the new /29 pointing to the IP assigned to your FW in the old /27 - You don't have to do any routing or IP configuration. - You can simply start creating NAT rules assigning IP addresses from the new /29       ... View more

Hey @dtran , I am curios how did you find the spikes?   Thanks! ... View more

Hey @vsys_remo ,   I just found that there was FR2729 - pull groups from Radius. Ref - https://live.paloaltonetworks.com/t5/general-topics/how-to-use-quot-retrieve-user-group-quot-feature-in-radius/td-p/51441/page/2   Not sure if it is still active. ... View more

Hi @alessandroco ,   There are two ways to use users and user groups in policy: - Local database: You can create the users (username and password) localy on firewall and then create user group again localy. After that in your security rule you can refer indivituals local users or the local user group. Local users and groups are configured under Device -> Local Users Database   - Group Mapping: Unfortunately currently only LDAP is supported. So if you have Active Directory, firewall will use LDAP to query the AD and "extract" all user groups that you have already created at the AD (you can set some filters and limit the groups that firewall will query, but by default FW will try to collect them all).   So to anwert your question - No, user groups information cannot be collected over RADIUS. You need LDAP to gather group membership information (which user is member of which group). ... View more

Hi @Nisha_Bharadia , - Good think that you have upgraded as Big Sur had issues with older versions. 5.1.7 is the lowest that is working normaly (if I recall correctly). But if you are running latest on 5.2 you should be fine. - I still see "(T10900)Debug(9176): 03/04/21 08:18:25:311 No portal configuration. User group is loaded." and I still believe users are failing to match the criteria defined fo the portal agent config.   Can you try to create test portal and gateway agent config at the bottom of your config, on the "Config Selection Criteria" tab leave it as default with any OS and any user group. If the test user manage to connect with this configuration the problem is definately with missing group membership.   By the way have you checked the logs on the firewall? Looking your logs you probably using Prisma Access, right? I guess you are managing the settings via Panorama, I assume you should still have similar GP related logs. For the working users you should see log saying which portal config this user has matched and same for the gateway. Do you see similar logs for the non-working users? ... View more