About Raido

Raido · ‎07-13-2020

From 9.1 you can't commit unless all dynamic peers have same crypto profile.

Raido · ‎07-12-2020

Are your peers configured with dynamic IPs?

Raido · ‎04-21-2020

It is always safer to create 2 NAT policies for DNAT and SNAT than bi-direcitonal. If you check bi-directional NAT rule in cli you can see that for DNAT source zone will be "any". For your TCP RST problem. Most likely your security policy is incorrect. Are you using pre-nat IP and post-nat zone in security policy?

Raido · ‎07-23-2019

When you purchased Panorama you got serial number for it. Go to Assets > Devices > Register new device After that you should have access to download Panorama images.

Raido · ‎07-22-2019

Is it new setup and has never worked? Are you using user or computer certificates?

Raido · ‎07-22-2019

Panorama uses 33% of log disk space for logd database for downgrade compatibility. If you don't have plan to downgrade to pre-8.0 it is wasted space. There is feature request 10931 to get rid of it. https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cm5aCAC

Raido · ‎04-11-2019

You need IP on tunnel interface only if you do dynamic routing or tunnel monitoring.

Raido · ‎04-11-2019

debug dataplane packet-diag clear filter-marked-session all https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClgDCAS

Raido · ‎04-11-2019

Use 10.248.250.10/32 as IP on tunnel interface. Then you are fine.

Raido · ‎04-11-2019

As step 1 you need to enable ssl decryption to start this working.

Raido · ‎04-11-2019

According to policy: "Devices that are currently end-of-sale cannot be re-certified. For our current end-of-life policy and listing of products, please see our support web site." PA-500 went end-of-sale year ago. https://www.paloaltonetworks.com/services/support/end-of-life-announcements/end-of-sale

Raido · ‎04-10-2019

If you open URL Filtering profile there is "URL Filtering Settings" tab. Last option is "X-Forwarded-For" If you check it then Palo will capture real source IP from the http session and log it. Proxy must add X-Forwarded-For to the traffic and unless you decrypt ssl you see this only for http sessions not https. You would need to be inline with vwire to decrypt. Maybe they can switch proxy to transparent mode. Also if you don't want to expose internal IPs then would be nice to strip this information after it passes Palo. Device > Setup > Content-ID > X-Forwarded-For Headers > Strip X-Forwarded-For Header

Raido · ‎04-05-2019

If you don't need interface IP to be object replace it back with regular IP and change object to /32. If you do need then create 2 objects. One for interface with /29 and other for security policies with /32

Raido · ‎04-05-2019

According to documentation: "These are the interface counters from the time the data-plane started on the firewall. These counters can be cleared with a data-plane restart only." https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClWoCAK

Raido · ‎04-05-2019

You can create object OUTSIDE. On every firewall you have local object with same name but public IP of specific location. On ethernet1/1 you assign object OUTSIDE as IP.

Raido · ‎04-04-2019

Do you have any other logs?

Raido · ‎04-04-2019

Because dot is separator between substrings so *.itsalmo.st does not match itsalmo.st https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClWYCA0

Raido · ‎04-04-2019

By timing out you mean session end reason? Well this is normal for udp and icmp protocols. In case of TCP there is session setup and teardown procedure.

Raido · ‎04-04-2019

You need 2 entries: itsalmo.st *.itsalmo.st

Raido · ‎04-04-2019

Panorama > Setup > Management > Panorama Settings > Share Unused Address and Service Objects with Devices

Raido · ‎04-04-2019

If it is not constant ping thenyou might miss it because ping sessions are cleared after 6 seconds. https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClRiCAK

Raido · ‎04-04-2019

Go to Monitor > Session Browser Use filter: (application eq 'ping') Do you see active sessions? What rule do they match against?

Raido · ‎04-04-2019

Did you enable loggign on intrazone-default rule? Do you see incoming pings now?

Raido · ‎04-04-2019

Are you using External Dynamic List? In this case you can see entries if you go to Objects > External Dynamic Lists Open the one you are using as source address. List Entries And Exeptions tab.

Raido · ‎04-04-2019

debug dataplane packet-diag set filter off debug dataplane packet-diag clear filter all debug dataplane packet-diag set filter match source 67.107.166.142 debug dataplane packet-diag set filter match destination 67.107.166.142 debug dataplane packet-diag set filter on show counter global filter delta yes packet-filter yes ping source 67.107.166.142 host <ip of your laptop> show counter global filter delta yes packet-filter yes Now post here output of the last show counter global result. And then to clean up: debug dataplane packet-diag set filter off debug dataplane packet-diag clear filter all

Raido · ‎04-04-2019

Well if the rule would have matched it would be in the log. For example if you have following Security policy then you should see log: From zone - wan To zone - wan From address - any To address - fw public IP Application - ping As soon as you add DNAT rule like the one below your security policy does not match any more because destination zone of the session is now LAN (not WAN): From zone - wan To zone - wan Service - any To address - fw public IP Destination NAT to - some internal ip In this case the rule does not match any more because <some internal ip> is in LAN zone and destination zone is switched in session header before security policy is checked so without knowing exactly how your security and nat policy were set up we don't know if the rule supposed to match. For this reason i suggested to enable logging on default rules.

Raido · ‎04-04-2019

It does not pass security policy. Enable loggign on intrazone-default and interzone-default rules. If no rule mathes then they will.

Raido · ‎04-04-2019

Security policies are evaluated top to down. First one that matches will take effect (either permit or deny). If you don't have custom rule like this: from zone - wan from address - any to zone - wan to address - fw public ip application - ping (or more relaxed like any) Then at the bottom intrazone-default rule will match. This is not configured to write log by default. Click on intrazone-default rule. Click override at the bottom. Open rule. Actions tab. Check "log at session end" Do the same with interzone-default

Raido · ‎04-04-2019

web-browsing traffic: SYN SYN-ACK ACK HTTP GET - Palo get's URL and checks the category. Server sends back website - Palo shifts application from insufficient-data to web-browsing In case of SSL URL is received from data on certificate. So if cert says *.google.com Palo can't identify if user went to mail.google.com or maps.google.com To get detailed URL categorization you need to decrypt SSL. https://urlfiltering.paloaltonetworks.com/query/

Raido · ‎04-04-2019

You mention service many times and then refer to web-browsing or ssl. I think you mix up with application. Because service column specifies regular tcp or udp port. Regular Layer 4. In my example top rule permits traffic if application is identified as ms-update. Palo always tries to identify application based on signature or heuristics. If application signature does not identify this traffic as ms-update then second rule will permit web-browsing or ssl on their regular port (application-default) if it is going to URLs that are specified in custom url category called windows-updates. Simple packet flow in Palo And detailed packet flow https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClVHCA0

Date Registered	‎02-10-2015 12:44 AM
Date Last Visited	a week ago
Total Messages Posted	797
Total Likes Received	270

Online Status	Offline
Date Last Visited	a week ago

Strata

Prisma

Cortex

About Raido