About kbrazil

kbrazil · ‎03-01-2010

If your security rule is blocking by port number then the traffic will probably be dropped before any type of application ID can be done or threat can be detected. If you are blocking by application signature then you will see the application in the traffic log, but the packets are being dropped before any threat can come through. In other words, you are seeing the application session initiation but no payload. A rule of thumb is to never turn on any profiles for a deny rule. There is no need since the packets are dropped by policy and not inspected any further. Profiles are only useful for allowed traffic. Kelly

kbrazil · ‎02-26-2010

As Mike stated, you need to allow the "web-browsing" application for web-based applications to function. This allows the HTTP decoder to activate. This only allows generic HTTP web-browsing and not other more-specific web applications we have signatures for. You can further control the generic "web-browsing" application via URL filtering profile. If you want to enable web-based IM you might want to create a policy that includes the IM and web-browsing applications, then add a URL filtering profile to that rule to block most categories of generic web-browsing that doesn't fit into an existing web application signature. You might need to tweak the URL filtering profile a bit and make some exceptions depending on how restrictive you make it. Cheers, Kelly

kbrazil · ‎02-24-2010

You might try adding a URL filtering profile to that security policy rule that only allows access to that web server or domain so the web-browsing application doesn't allow access to other URLs. Kelly

kbrazil · ‎02-17-2010

This should work with no problem, so you might want to work with Support so they can help troubleshoot. I have seen instances in the past where I had included an incorrect IPSEC application (it turned out to be Cisco VPN instead of generic IPSEC) and that caused the traffic to fail even when switching to an open policy. The reason is because the firewall cached the IKE session initiation but it was later determined to be the incorrect IKE type. All I had to do was to clear the session from the session table and the next IPSEC connection was correctly identified and allowed through. You can clear all sessions or selectively clear sessions from the CLI. Cheers, Kelly

kbrazil · ‎02-12-2010

Hi Michael, A couple other things to check: If the rest of the internal network is behind a router, make sure you have all of the network routes in the Virtual Router on the PAN. If you don't see anything in the traffic log it's usually an indication that there is a lower-level routing issue. Also, the PAN does not proxy-arp for the IP-Pool, so you will need to put a static route on your next-hop router with a destination of the IP-pool pointing back to the PAN. It is especially important to use an IP pool that is on a separate subnet from the internal network if there is no next-hop router to the internal network so you can easily force routing to the IP-Pool. Otherwise you are relying on ARPs, which the PAN does not do today for the IP-Pool. Cheers, Kelly

Member Since	‎04-08-2009 04:41 AM
Date Last Visited	‎08-18-2015 09:06 AM
Posts	217
Total Likes Received	82

Online Status	Offline
Date Last Visited	‎08-18-2015 09:06 AM

About kbrazil

Re: Upgrade to 5.x - the good, the bad, the ugly?

Re: multiple interfaces in a Zone

Re: Palo Alto BGP: Conditional Advertising

Re: Can VWire use aggregate links?

Re: Blocking Postal-Receipt.exe

Re: Policy Export

Re: OSPF A/P HA Config with Floating Static Routes

Re: Multicast Packets forwarding

Re: NAT question

Re: Hide protocols from display in ACC?

Re: Threats log for denied packets

Re: Best Practices for Application Policies?

Re: Why permitiing web-brosing is required while permitting custom http-based apps?

Re: Remote Desktop and IPSec in the DMZ.

Re: Getting SSL-VPN clients to see internal servers