About aleksandar.astardzhiev

aleksandar.astardzhiev · ‎05-11-2021

Hi @Nikko, If I understand correctly what you are asking it is possible yes. set rulebase nat rules Web-Server-Destination-NAT to loopback-zone set rulebase nat rules Web-Server-Destination-NAT from [ vlan5-zone vlan10-zone] # or select any if set rulebase nat rules Web-Server-Destination-NAT source any set rulebase nat rules Web-Server-Destination-NAT destination loopback_192.168.6.2 set rulebase nat rules Web-Server-Destination-NAT service any set rulebase nat rules Web-Server-Destination-NAT destination-translation translated-address server_192.168.4.4 In addition you need to create allow rule: set rulebase security rules Access-to-Web-Server profile-setting group default set rulebase security rules Access-to-Web-Server to [ server-zone ] set rulebase security rules Access-to-Web-Server from [ vlan5-zone vlan10-zone] set rulebase security rules Access-to-Web-Server source any set rulebase security rules Access-to-Web-Server destination [ loopback_192.168.6.2 ] set rulebase security rules Access-to-Web-Server application [ web-browsing ] set rulebase security rules Access-to-Web-Server service application-default set rulebase security rules Access-to-Web-Server action allow set rulebase security rules Access-to-Web-Server log-setting default You need to note couple of thinks: - In the security rule you need specify the destination zone where your web server is located. - In the security rule you need to specify the destination address of your loopback, aka the destination address before the NAT (users will use the loopback to access the server) - In the NAT rule you need to specify the destination zone where your loopback interface is located. This is because the NAT is evaluated first and applied later. Which means that when the original packet (from user) hit the firewall, FW will use the original destination IP (in this case the loopback) to determine which is the destination zone By the way - based on your network setup it is not necessary to have the IP as loopback on the FW to use it in NAT. Your devices only need to know to route 192.168.6.2 to the firewall (either with specific or default route)

aleksandar.astardzhiev · ‎05-11-2021

Hi @Lucaaslr , Expand log entry details by clicking on the magnifying glass on the very left. - Check if you have NAT applied on the source address - Check if you have bytes sent and bytes received (the incomplete indicates TCP hadnshake is not completed, so I assume received would be zero) - If your nat is correct you should run basic network check to see if you have proper routing

aleksandar.astardzhiev · ‎05-07-2021

Hi @MichaelMedwid , From your log it seems you are using the "new" feature connect before login, not pre-logon, is that right? I haven't had a chance to test the new method (not 10.0), but the error message indicates that FW is failing to match client config for the connected agent. Previously with Pre-Logon method, PC was establishing tunnel to FW with "hardcoded" username "pre-logon". The login process is absolutely the same as if end user is connecting (it first connect to gp portal, get config, connect to gp-gateway). Once user logins to Windows GP will rename/re-establish the tunnel with the actual user and replace (which will again go through the same process, gp portal, config, gp gateway). Which means that in your portal and gateway client config you need to have config that will match username "pre-logon", either config specific policy matching this user, or have "any" for matching criteria. Looking at your log it seems this is not exactly the case as you can see the actual username in the portal login event. But I still believe the problem is that your user is not matching any client config under the gp portal. How it is configured? What you have for matching criterias? I am not sure if understand @reaper as GP 5.2 new features guide says: Because Connect Before Logon prompts you to authenticate twice on the portal and gateway when logging in to the Windows endpoint for the first time, the Authentication Override cookie is not working as expected. https://docs.paloaltonetworks.com/globalprotect/5-2/globalprotect-app-new-features/new-features-released-in-gp-app/connect-before-logon.html

aleksandar.astardzhiev · ‎04-29-2021

Hi @DongQu , I am probably missing something... The PAN FW has nothing to do with 5.5.5.x addresses, isn't this the whole purpose of the GRE tunnel? - Packets from the client will enter the router - Which will add GRE encapsulation, which boilse down to new IP header - Now the outer IP header (that is used for routing desicion) is has different source and destintion addresses - more specificaly your gre tunnel addresses, right? - When the packet reaches the PAN FW and if you don't apply any tunnel content inspection it will see only the 3.3.3.3 and 192.168.55.250.

aleksandar.astardzhiev · ‎04-29-2021

Hey @ENMAXAdmin , Can you explain a bit more, what are you trying to achive? From PAN-OS 9.0 and later there is "test policy" tool build-in to the GUI. You can access it either from Device > Troubleshooting, or as button at the bottom of the Policy tab You can use the CLI tool as well: > test security-policy-match + application Application name + category Category name + check-hip-mask check hip mask + destination destination IP address + destination-port Destination port + from from + protocol IP protocol value + show-all show all potential match rules until first allow rule + source source IP address + source-user Source User + to to | Pipe through a command <Enter> Finish input But I don't understand what you meand by "from monitoring logs". The each log entry contain the name of the rule that this traffic has matched.

aleksandar.astardzhiev · ‎04-28-2021

Hi @GideonKonga , I believe I have experiance similar issue once long ago. Try to change the authentication protocol under the TACACS server profile. If I remember correctly this behaviour will happen when your tacacs server is using different auth protocol from what is configured on the FW. Verify that what is configured on the FW is matching your server.

aleksandar.astardzhiev · ‎04-28-2021

Hi @MichaelMedwid , Probably Cortex XDR is what you looking for - https://docs.paloaltonetworks.com/cortex/cortex-xdr.html

aleksandar.astardzhiev · ‎04-28-2021

Hi @clarkevans Is this what you looking for: Note it is for 5200, but I believe it should be exactly the same for 5050. You should see the same information under the firewall itself

aleksandar.astardzhiev · ‎04-28-2021

Hi @pomologist , Have you tried to disable "Verify update server identity" under Device > Setup > Services? I know it is not good idea to disable this, but you can try to see if you disable it for a moment, can you get updates. In my FW I don't see default decrtyption exception for "updates.paloaltonetworks.com". You can try to add decryption exclusion for this FQDN and enable the verification again. It is possible that you will need to add aditional exceptions, but I am really not sure.

aleksandar.astardzhiev · ‎04-28-2021

Hi @DongQu , Your NAT for the "stage1" seems fine. The outbound rule also seems ok, but it the inbound rule is incorrect. I used to look at my notes every time when I was about create NAT rule: "NAT rule must be configured with pre-NAT zones (zones matching the addresses before the NAT) Security rule must be configured with pre-NAT addresses, but post-NAT zones" This means that your inbound rule should be: ipsec zone > trust zone, source IP 3.3.3.3, dst IP 4.4.4.4 (dst zone after the NAT, but dst IP before the NAT) Unfortunately this will not solve your ping problem. The inbound rule will allow you remote site to initiate traffic, but should not have any effect on the return traffic for your outbound pings. If you see the "allow" log with correct NATed source it sound your rule, nat and route are correct (if the route was not correct I wouldn't expect rules to match the dst zone) - Do you see the counter for encrypted packets increasing while you are pinging? What about the decrypted packets? - In the traffic log what is the counter of "packets send" and "packets received"? - Can you check on the ASA if the counters of encrypted and decrypted packets are increasing? About the second part of your question - I really don't understand what you want to achieve... From the diagram I understand that you will bring GRE tunnel between two Cisco routers. This traffic will be routed through IPsec tunnel between ASA and PAN FW. What I don't understand is what are "tunnel IP 5.5.5.5" and "tunnel IP 5.5.5.6". Is this another tunnel inside the GRE? Or your want to "hide" the client ip behind 5.5.5.6 and the server behind 5.5.5.5?

aleksandar.astardzhiev · ‎04-23-2021

Hi @Akhil_B , Interface status (the icon in the very right) is showing the status of the logical tunnel interface associated with that IPsec VPN. This tunnel is logical (something like loopback interface) it will never go done by itself. The other two icons (green/red dots) are representing the actual IPsec Phase1 and Phase2 status. So if you see any of the dots red this means that this phase failed to negotiate. Going back to the interface status. In short you can completely ignore this status unless you are using tunnel monitor. Without tunnel monitor the tunnel interface will always be up. Tunnel monitor is a feature which will "shutdown" the tunnel interface if it detects issue with the tunnel.

aleksandar.astardzhiev · ‎04-23-2021

Hi @ZEBIT , I would say the problem is not with the app-id signature, but how networks work... When you visit the download page and browser create new HTTP connection firewall will first see the TCP connection, then the SSL neogtiation and only after that the actual data. As you can imagine FW need some amount of packets to pass in order to categorize the application. So even that your wetransfer app rule is above, for the first couple of packets FW will not match this rule (because it will identify it as application = web-browsing/ssl), so it will match our generic web browsing rule (the one with url filtering). FW will be able to categorize the URL and therefore take the action base on your url filtering profile. If it is allowed more traffic will start passing over the FW so the app-id engine will have enough data to detect that it is actually wetranfer and not the generic web-browsing. In that moment FW will make another policy lookup (because the app has changes) and now it will match your wetransfer specific rule. I guess you can try to submit request for app optimisation so the wetransfer app signature match earlier (but not sure if that is possible) What you could do is: - Create custom URL category and add wetransfer domain (with wildcard or specific subdomains you choose) - Go to your URL filtering profile and choose alert/allow for the category you create above This will create whitelist only for the wetransfer while you still block "online storage and backup" category

aleksandar.astardzhiev · ‎04-23-2021

Hi @DongQu , I am not sure I understadn your last comment. Run > test vpn ipsec-sa tunnel tu-ITIVIT:tu-ITIVIT > show vpn flow What is that status of this tunnel? Immediately run > test vpn ipsec-sa tunnel tu-ITIVIT:tu-ITIVIT-2 > show vpn flow What is the status of second tunnel? If you execute "test vpn" for both proxy-id immediately one after another, are one still showing inactive? Have you checked the logs? Go to system logs (where the ipsec s2s log are located) and you can add this filter ( object contains tu-ITIVIT )

aleksandar.astardzhiev · ‎04-23-2021

Hi @DongQu , This is a bit tricky. You see PAN first determine the destination zone and then evaluates NAT. For this reason for the NAT rule you need to use pre-NAT zones. Which means that for the destination zone you need to use the zone, which correspond with the network before the nat...I know it may sound confusing (even worst with my bad english) but take simpler example: Imagine you want to do destination NAT so Internet users to reach your internal server. In this case you will create NAT rule like: - source zone: unstrust/public - source IP: any - destination ip :50.50.50.50 (your public server ip) - destination zone: untrust/public - translated destination 10.10.10.10 (your private server ip) You may notice that destination zone is not your internal (as you expect, because the server is in the internal zone), but it is again untrust. That is bacause 50.50.50.50 is not in your routing table and the FW is following the default route, deciding that 50.50.50.50 is related to untrust zone. In your case you need to configure destination NAT, but not from public, but from the vpn tunnel. Which means your NAT will look like this: - source zone: vpn-tunnel - source ip: remote networks - destination zone: this is the trickypart - destination ip: local NAT network - translated destination: local original network And here come the tricky part: Your firewall will perform route lookup for the "local NAT network" to see which zone it is related. If it doesn't match any specific route it will match your default, therefor fw will think the destination zone is your untrust. So at the end your nat should use destination zone untrust (or what ever zone match the route for nat network) This could be a bit misleading for someone else that is looking at the config after some time. For that reason in @harishsidhartha example configuration you will see static route for the local NAT network pointing to the tunnel. The only purpose of this route is to tell the FW to associate this NAT network with vpn-tunnel zone. That way when you configure your NAT rule you need to use source and destination zone = vpn-tunnel Another approach would be to leave the destination zone to any. Select souce zone and ip, and destination ip, but this will be equivelent to just enabling bi-directional option in the source nat rule (from local to remote). Even that you use destination zone any you don't have to worrie if different traffic match this rule, because you have still specified source zone and destination ip. And because there is no way similar traffic to be received from any other interface or tunnel, you can be sure that only traffic from that tunnel will be nat-ed

aleksandar.astardzhiev · ‎04-22-2021

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.

Member Since	‎08-01-2017 11:18 PM
Date Last Visited	‎12-22-2025 12:06 AM
Posts	1,077
Total Likes Received	448

Online Status	Offline
Date Last Visited	‎12-22-2025 12:06 AM

Unlock your full community experience!

About aleksandar.astardzhiev