About aleksandar.astardzhiev

Hi @FarzanaMustafa,   It doesn't sound you have enough investigation to exclude problems with adjacent devices... - Have you done a packet capture when the issue occur? - Can you confirm that the packets are coming from the right interface/zone? - Have you compare packet captures when the issue occurs and when there is not issues?     ... View more

Hi @a.jones ,   It sounds that you are mistaken tunnel interface with IPsec tunnel source interface. - " the tunnels have a local IP and peer address." - local IP and peer address are the public address of your gateway and the remote device that will be used for building the IPsec tunnel. In addition Palo Alto is using route-based VPN implementation. Which means that if you want to send traffic through the tunnel you need to have a route in the routing table pointing to that tunnel. Since the "tunnel" is logical (it doesn't exists physically) you need a logical (virtual) interface that is bound to that tunnel. - "When I configure the tunnel nat source translation I am using DIPP with the tunnel interface, IP none" - It sounds that you have bound your IPsec tunnel with tunnel interface that has no IP configured. While a tunnel interface can be configured without IP address, such source NAT rule is not valid. If you think about it you said to your FW - for source nat use the address for this interface which doesn't have ip assigned...   The two solutions would be: - Configure your Source NAT DIPP rule with "Translated address" instead of "Interface address" and define the address you want to use for the hide nat - Assign an IP address on the tunnel interface that is bound to your IPsec tunnel. After that you should be able to use it in source nat rule   I don't believe there is any difference between the two. Most important in both cases is that your proxy-id should use the NAT address as local. And at the same time the remote side of the tunnel should use the NAT address as remote proxy-id       ... View more

Hi @husetech, Well it still sounds like a bug for me. It doesn't make sense to have separate service route for EDL if it using the URL filtering route.   Me personally prefer to define any service route using the destination tab. It is bit more flexible - for example when you define two different LDAP servers reachable via different interfaces     ... View more

Hi @DShofkom33x ,   I am still searching for the best approach, but meanwhile our setup is: - Created onе "Default Device Setting" template defining only: DNS, NTP, SNMP, Banner, Dynamic Updates, ContentID and session settings, logging setting and etc (any other setting that is considered standard for us and applied on all devices) - Created one "Site Specific Network settings" template defining anything needed in the Network tab (interfaces, routing, IPsec, GP etc). In the same template defining the HA setting. For this template we have defined some template variables: $peer-ip - used in HA config general tab for peer ip address $ha1-ip - used in HA config, HA1 local IP address $ha2-ip - used in HA config, HA2 local IP address $gw-ip. - used in HA config, for path monitoring.   - Created on template stack per site - the stack include default device settings and the site specific network and HA config. - Each member in the cluster is overwritting and uses specific value for all three variables   At the beginning I liked this approach as it is using fewer tempaltes = fewer templates to support. The disadvantage is that template variables supprot only ip addresses and network. Which means that you cannot set different priority for the to members using same template (so we define it locally).   So I am starting to preffer the approach to use separate stacks for each member. Depenting on the standartization between your sites (firewalls) you can try to create two tempplate for HA peer one and HA peer two. So the two stack will use the same network template and the "standard HA" templates   ... View more

Hi @myky ,   I was using tcpdump on the management interface recently and I notice that every time the capture is started the file is overwriten, not amended. So as some kind of workaround you can just run new tcpdump with some dummy filter (at will not capture any traffic). This will overwrite and replace the content of the file from the previous capture.     ... View more

Hi @Cindy-Resiter,   For configuration simplicity I would suggest to use the firewall public IP for the GlobalProtect. The reason for that is you need to select an interface on which you want to enable the GP. So the firewall will allow you to set an IP address that is already assigned to it, and the simpliest configuration would be to just select publicaly faced interface.   Technically speaking I am not even sure that you can use different IP for the GP in all cases: - If your fiirewall is assigned with 1.1.1.1/29 and you ISP gives you (route to your FW) 2.2.2.2. You can configure the 2.2.2.2 as a loopback and use it for the GP - But if your firewall is assigned with 1.1.1.1/29 and you try to use 1.1.1.2 for GP, I don't believe FW will allow you that. If you try to configure loopback with 1.1.1.2/32 it should overlap with your public interface and commit should fail.   So my personal prefferable way to configure GlobalProtect is always use the firewall IP - simple, standard, always work, without interfering other services ... View more

Hi @BigPalo,   What model are you running?   I am asking because a few months ago I notice something similar for a brand new PA-820. Before this device we had only PA-3000 and PA-5000 series. So I opened a case to TAC and the engineer was very kind to give me a very nice explanation:     The difference between those platforms (PA-3000 and PA-5000) and PA-8XX is that they have a dedicated dataplane. For platforms like PA-8XX and PA-2XX with one CPU there are always some cores dedicated to MP and others for DP, and the DP cores of that single CPU are generally maxed out.     ... View more

Hi @Pattarachai,   Can you explain a bit more your setup or what you want to achive? Like any other vendor Palo Alto support - active-standby cluster - where you deploy to FWs in HA cluster. Both firewalls share same IP address and in case of failuer on the primary member traffic is handovered to secondary member. Since both member are using same IP address for the rest of the network nothing has changed   - active-active cluster - wher both FWs in the cluster are active and used different IP address. BUT you can configure VIP (floating IP) which can be used by the neighbour devices to forward traffic to only one of the member. In case of failuer the secondary member took over the VIP addresses   - If you want to run VRRP between the FW and a router, so in case of failuer in the firewall the traffic to be send the router, so you will loose security, but will maintain connectivity - Unfortunately that is not possible. Palo Alto doesn't support any First Hop Reduncency protocols (VRRP, HRSP etc) ... View more

Hi @Maxstr,   Unfortunately that is correct, service routes can be configured only through one interface.   However a workaround would be to configure service route based on destination. Take for example LDAP: - You must leave the service route for LDAP on default - On tab destinations configure two or more LDAP servers. Each server can be assignd with different interface The catch here is that firewall will use the IP from the interface as source address when trying to connect to LDAP, BUT it will always perform route lookup first to check how to get to the LDAP server.     ... View more

Hi @fatboy1607,   - ICMP packets generated by tunnel monitor are not logged - Packet capture on the firewall cannot capture those packets - The only way to see if tunnel monitor is sending and receiving (if receiving) packets is via the comman you already know > show vpn tunnel-flow id The ping packets generated by tunnel monitor ARE definately encrypted and send try the tunnel, that is the whole point of the tunnel monitor, to see if both phases of the IPsec tunnel are up and actual traffic can pass through it.   The common reason for your tunnel monitor to show down is - proxy id. If your tunnel is using multiple proxy id, tunnel monitor will fail. For more details see my comment in the following post - Fail-over VPN site-to-site ... View more

@BPry,   If you utilize a NAT translation for your VPN traffic to the other company, you would still require the associated route statements to actually direct the traffic to the right location. That is pretty much the same what I have said - you only (or mainly) need route for the remote networks to point to the right tunnels. But my understanding here is not the remote network overlapping with existing tunnels or local networks, but that the local network is in used behind the remote peer. Also based on the @cheez explanation I got the expression that only traffic initiated from local to remote will pass through the tunnel.   Which should means: - simple route to remote_network via tunnel.1 - source nat, with dynamic ip and port for traffic from:local_lan to:remote_network - ipsec tunnel with proxy id local:natted_ip remote:remote_network At this point it really doesn't matter what ip you will user for the source nat, as long the remote side accept it       ... View more

  Hey @BPry, Apologies, but I am confused by your reply for the routing table...   @cheezif understand your question correctly you want to: - create site-to-site IPsec tunnel - inside this tunnel hide NAT your private source behind public IP (which also used for ike peer) - use the public (peer) IP local encryption domain (proxy-id)   I haven't personaly done it, but I have seen it multiple time on other tunnel. And it shouldn't be any problem to achive this: a) on the palo the decision if traffic should be encrypted with given tunnel is based on routing (aka route-base vpn), so it doesn't matter what source are you using (as long you have a rule of course) b) when you are creating your hide NAT rule you need to specify source zone your lan and destination zone your vpn zone (where the tunnel interface is), and also match based on original destination - this will assure that only traffic to the vpn is NAT-ed           ... View more