About gwesson

An HTTP CONNECT is the correct type of request for an SSL site when using a proxy. The CONNECT request is actually on port 80, and is an instruction to the proxy that it should connect to the site using port 443. The manual 'http://hostname:443' is not quite the same thing that the GP client will use. A raw HTTP request on port 443 would look like: TCP Destination Port: 443 GET / HTTP\1.1 Host: hostname.example.com Whereas the CONNECT would look like: TCP Destination Port: 8080 CONNECT HTTPS://67.214.245.37:443/ HTTP\1.1 Host: hostname.example.com If your browser also uses a proxy, you can go to "https://67.214.245.37:443" and it should return valid data. A packet capture would show the CONNECT request from your browser as well. Hope this helps, Greg ... View more

There are a few things that need to happen for an application to be identified, mainly for TCP traffic there needs to be at least the TCP handshake and another packet or more. "non-syn-tcp" is blocked by default, so your firewall seems to have that enabled. Check the Device > Setup > Sessions tab. If you've got it set to allow, the firewall will let a connection be established, and if it's possible to identify the traffic it will do so. "incomplete" is traffic that did not actually complete the TCP handshake. That you likely don't have to worry about. "insufficient-data" is traffic that has not had enough packets to identify what it is. Some traffic can be identified easily on the 4th packet (web-browsing, for example has an HTTP GET or similar as soon as the TCP handshake is done), but other traffic may take some time to identify. In the case of github, if it's going on port 80 as your traffic log shows, there has to be some additional traffic before it can be identified. It will have to go through git-base initially, and then be identified as github after git-base is identified. In your screenshot, it never gets that far. Likely there are only a couple packets, which is common for C&C traffic, and so the firewall is unable to identify it positively as github by the time the traffic is done. My recommendation is to disable non-syn-tcp in the session to start, but that may impact other applications so check to see why that was enabled to begin with. The rule in your screenshot doesn't have the last 2 columns, so if there is no AV/Vuln scanning, you'll want to add that as well. Beyond that, if you want to restrict the rule further by adding a URL category or a specific URL for the destination traffic, that may help. Best, Greg ... View more

GlobalProtect is indeed proxy-aware. Prior to version 1.2.6 there was a failure to detect a PAC file when connecting to the gateway, but that was resolved. Depending on how the portal and gateway are reached, you may have to modify the registry if the Gateway and Portal have different directives. From the release notes: ===== 54487— GlobalProtect was failing to automatically discover Web Proxy Autodiscovery Protocol (WPAD) and proxy auto-config (PAC) settings and was not connecting to the proxy portal. This did not occur when the proxy was configured statically using the web interface. 54230—GlobalProtect was failing to automatically discover proxy auto-config (PAC) settings and was not connecting to the proxy gateway. With the fix, GlobalProtect will now use the same proxy server for the portal and gateway, as determined from the PAC file. If the PAC file has specific directives to use a different proxy server for the portal and gateway(s), then a registry setting must be added on the client: HKEY_LOCAL_MACHINE\SOFTWARE\Palo Alto Networks\GlobalProtect\PanGPS. Create a new key named ProxyMultipleAutoDetection, with a type of DWORD and a value of 1. This key is only required if the PAC file specifies a different proxy server for the portal and gateway(s). ===== The challenge may be in the initial discovery of the PAC file, but if using something like wpad.dat or the proxy configuration from Windows (assuming a Windows client) Internet connection settings, GlobalProtect should have no problem connecting using the proxy settings. -Greg ... View more

You could always use the "count yes" syntax of the CLI command show session all By adding progressively more specific filters, you can narrow down the sessions you are looking for. For example: > show session all filter count yes > show session all filter count yes from trust > show session all filter count yes from trust application web-browsing > show session all filter count yes from trust application web-browsing source 192.0.2.5 ... and so on. By getting the count for each filter, you can find what may be odd in favor of what you are looking for. With the filter, you may not be able to display more than 3000 entries or whatever is present, but the count should help narrow down what is causing the imbalance. Hope this helps, Greg Wesson ... View more

While I cannot answer your question directly as I have never attempted a modem connection to the console port, you may be able to get away with a minimal investment if you have a linux server. I found this site, which goes over the details of getting a fully-functional linux-based console server for very little cost investment. Linux-based serial console server | Network Tech Blog Hope this helps at least a little bit if you can't get the modem itself to work. -Greg ... View more

You can click the 'follow' link on these documents to be notified of the releases: 5.0: https://live.paloaltonetworks.com/docs/DOC-4148 4.1: https://live.paloaltonetworks.com/docs/DOC-3422 There are others as well. Please check the main page of the KnowledgePoint page. There is a section near the top that says "Software Release Notices" with several documents to follow for various releases: KnowledgePoint Best regards, Greg ... View more

When you look at your traffic log, there is a column that shows the rule that is being hit. Do you see your Black List rule listed or is that rule being missed and it's instead hitting the bottom rule? Generally, this should work the way you mention. The one caveat I can think of is the URL filtering logs. Those logs will show up no matter what, as a deny is a log action. There is no concept of denying a URL category and not logging it to the URL filtering rules. You may be able to get this to work by not using the URL filtering profile and instead selecting the categories in the rule itself with a deny action and unchecking the logging options on that rule, but I have not tried doing so yet. Hope this helps, Greg ... View more

mikand - You're absolutely correct about the deny happening if there are no other rules to allow the traffic. If no rule matches a port to allow the traffic, it will be denied. I suspect that a review of the full security policy will show what is happening. As for the manual rule at the end, it can cause significant trouble if implemented incorrectly. I have often run into things like GlobalProtect failing because the initial Portal request is same-zone, but an any-any-deny rule would block that traffic. We recommend against the default rule at the bottom since the firewall already blocks inter-zone traffic. There's a CLI logging option if you want to log that traffic (up to 5 minutes at a time) to do any rule-based troubleshooting: set system setting logging default-policy-logging <0-300sec> This lets you check for default deny hits without logging everything all the time, or denying traffic unexpectedly. For customers who must log all denies, I recommend instead of a generic any-any-deny to put in inter-zone specific denies: From External; to [internal/vpn/dmz]; deny From Internal; to [External/vpn/dmz]; deny From dmz; to [Internal/vpn/external]; deny From vpn; to [internal/dmz/external]; deny This lets the logging take place, and mimics the default behavior by allowing same-zone traffic. Your mileage may vary, it's just an observation Cheers, Greg ... View more

As a test, I set up something similar with a server I have running behind my test firewall. The server is listening on 22, 25, 80, 443, 4443, and 5001, and I set up the same policy as you, except I also added a rule right below that one that denies all traffic to that IP. When I run nmap on that system, it gives me the following (I obfuscated the names since it's my personal server): ~ $ nmap x.x.x.x Starting Nmap 6.00 ( http://nmap.org ) at 2013-09-25 12:26 PDT Nmap scan report for x-x-x-x.abc.def.example.com (x.x.x.x) Host is up (0.027s latency). Not shown: 997 filtered ports PORT    STATE  SERVICE 21/tcp  closed ftp 80/tcp  open   http 443/tcp open   https Nmap done: 1 IP address (1 host up) scanned in 4.03 seconds As you can see from that, it is only showing the services defined in my allow rule with application_default as the service. When I delete the rule below the allow rule (the one that blocks everything else), my other rules allow all the configured ports to reply. Here's the output when I add the "application_default" rule: Not shown: 994 filtered ports PORT     STATE  SERVICE 21/tcp   closed ftp 25/tcp   open   smtp 80/tcp   open   http 443/tcp  open   https 5001/tcp open   commplex-link 8080/tcp closed http-proxy Nmap done: 1 IP address (1 host up) scanned in 4.53 seconds And with my default rule set: Not shown: 994 filtered ports PORT     STATE  SERVICE 22/tcp   open   ssh 25/tcp   open   smtp 80/tcp   open   http 4443/tcp open   pharos 5001/tcp open   commplex-link 8080/tcp closed http-proxy Nmap done: 1 IP address (1 host up) scanned in 5.89 seconds One thing you'll notice is that with your test rule in place, port 21 is explicitly reset (showing closed). When that rule is gone, the port 21 traffic is just dropped since I don't have that port listening on the server. Best regards, Greg ... View more

gafrol that's true when the session begins, such as with an HTTP GET or an FTP command. But with just the 3-way handshake the firewall has no way of knowing what the application is. The security policy is matched twice per initial packet: Once if a policy would allow the traffic if there were no applications selected, and again when the application is determined. If this was the only rule in the policy (something that's not clear from the screenshot), then it would make sense that it should be blocked as it is not the default app for those ports. I think there is probably a rule above or below that, if there was no application, would allow the traffic to the server. -Greg ... View more

This stems from a combination of three things: 1. Lease time on the IP address given to the VPN user 2. Not disconnecting the SSH session when leaving 3. Timeout duration on SSH #1 cannot be changed, and since you can't really control #2 it falls to adjusting the SSH timer. I believe the GP IP address timer is around 1 hour before reuse, but you may have to experiment with that a bit. You can change the SSH timer under Objects > Applications. Doing so would be a global change, so you may run into issues if you have long-lived idle SSH connections going through the firewall. Another way I could think of doing this would be to run a script that checks for current GP users, and if one leaves you could run a CLI command to wipe out any sessions with the associated IP address: > clear session all filter source 192.0.2.10 Hope this helps, Greg ... View more