About cosx

cosx · ‎11-12-2015

Running 6.1.2 and keep up-to-date with the application-threat updates. Yeah, it all worked fine when we weren't allowing quic. We didn't start seeing problems until we expressly allowed it.

cosx · ‎11-12-2015

If you are using a loopback address that is in the same range as the Ethernet interface, are you sure that the provider router is finding the loopback via ARP? Since the address is local to the provider's address on that link, it is going to try to resolve it directly rather than route it to your firewall on the next-hop address. FWIW, we terminate a bunch of VPNs on a loopback, and it works fine. The loopback is "behind" the firewall from the provider router's point of view, so it routes to the firewall as the next hop.

cosx · ‎11-11-2015

We started getting complaints from users that various Google services were showing intermittent disconnects. I think we've tracked it down to the QUIC protocol not being accurately identified by the PAN firewalls and getting blocked. I see 443/udp traffic from the hosts in question getting dropped as "unidentified-udp" mixed in with the allowed "quic" traffic on the same ports to the same general set of Google servers. Google has been rolling out QUIC for a while now, but we only recently allowed it in the firewall. It's been since then that we've seen the Google issues start. I am considering adding a rule allowing "any" application out on 443/udp as a workaround. Has anyone else seen similar problems? That is, do you allow "quic" out to the Internet, but otherwise would drop 443/udp and see or not see this issue? Did you implement a workaround like this or something else? (BTW, I am not overly concerned about the security implications. PAN firewalls don't understand the QUIC traffic like HTTPS to guess at the Google "applications" inside.)

cosx · ‎10-16-2015

From what I understand, you need to explicitly allow "depends on" apps for a given app to work, https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Check-if-an-Application-Needs-Explicitly-Allowed/ta-p/61893 However, what if I want to only allow the "child" application, but not the parent? My example is "logmein." We explicitly block it since it violates policies to have employees to set up their own remote access into our network. However, Microsoft uses LogMeIn as a support tool. I think that functionality is the "logmeinrescue" application. So how can I set up my security policy to allow logmeinrescue, but not allow generic logmein? I'm not sure if it is possible.

cosx · ‎03-27-2015

Yes, I can limit source IP addresses at either the Interface Mangement level or within the Security Policy. But any administrator will then be able to access from the allowed IP addresses. I want to restrict some IP addresses to only certain administrators. For example, the administrator "johndoe" can only access HTTPS or SSH management via the management interface and/or from 10.100.0.0/16. Another user, "joefailsafe," can get in over an Internet-facing interface from <some-public-internet>/29 addresses. Whether joefailsafe also has access via the management interface and internal IPs, I don't care. What I do not want is for johndoe to be able to get in from the Internet at <some-public-internet>/29. Using the features mentioned in the two previous responses, there is no difference in accessibility for johndoe and joefailsafe. (Again, I'm not sure that there is a way to do this in PANOS. I thought I had seen the feature somewhere, but now I'm pretty sure I must have imagined it or be confusing our firewalls with some other device/OS.)

cosx · ‎03-26-2015

Is there a way to restrict access for specific administrators by interface or IP address? I really thought I'd seen this somewhere, but now I cannot find it in GUI or docs. Quick explanation of what we want to do. We want to have a sort of backdoor, emergency access to the firewalls directly from the Internet. That is, should some catastrophic network event (big misconfiguration or failure of the firewalls themselves, the core network, or remote access devices) break our usual ability to log in via remote access VPN and come into the firewalls' management interfaces, we want to be able to connect directly into the firewalls from the Internet. These firewalls are in a data center, so it's at least a half-hour car ride even during business hours, plus we want our off-site managed services provider to also have this ability. Usually, we use AD-backed authentication for administrators on the internal network. However, in the event of a failure, the AD servers may not be reachable, plus from a security point of view, using simple username-password authentication does not seem secure enough to face the Internet, even with source IP address restrictions. We would want to have a more secure local authentication method. Luckily, using public-key-based authentication (SSH keys and HTTPS client certs) are both options for local administrator authentication. So, those local accounts would seem to work out fine, but how do we block regular AD-based authentication from the Internet and allow it for the special local accounts?

cosx · ‎03-26-2015

For the record, I did go to PAN support with this. They provided a patched version of Panorama, 6.1.2-h1, with the fix. I assume that the fix will be present in future releases.

cosx · ‎01-20-2015

I recently upgraded Panorama to 6.1.1 from 5.0.11. When I did so, RANCID was no longer able to log into Panorama and do its configuration tracking. I tracked down the problem to a superreader not being able to issue the "set cli pager off" command. This worked in 5.0.11. It still works on a firewall running 6.1.1, just not on Panorama. In 6.1.1 on Panorama, the "set" command is totally restricted. On a PA-4060, I get what I expect, only the "set cli" and "set password" commands are available. I can temporarily give the account RANCID uses superuser permissions, but there isn't a reason this account needs write permissions. Am I the only one having this problem? Something about my Panorama setup? Or can other reproduce this? Any idea at which version this was broken?

cosx · ‎10-27-2014

Yes, it does show lifetime. I was looking for the lifesize. There is a mention of it in the flow output, packets received when lifetime expired:0 when lifesize expired:0 But that's not about what the current lifesize counter is at. I guess you can use the encapsulated and decapsupated byte counts to figure it out.

cosx · ‎03-18-2014

The firewall/router in question is not an ABR between two areas. It is only in a single area. It is an ASBR. The external routes it is bringing into OSPF are static routes configured on itself. It is listing itself as the forwarder. Section 2.3 of RFC2328 discusses what the forwarding field is used for, "...the OSPF protocol allows an AS boundary router to specify a "forwarding address" in its AS-external-LSAs. [The ASBR] would specify [the other router's] IP address as the "forwarding address" for all those destinations whose packets should be routed directly to [the other router]." There is no other router in this case. The ASBR itself is the correct next hop for the traffic. It also doesn't seem to make sense for a router to specify itself as the forwarder. The field should be zeroed if the ASBR itself is the next best hop.

cosx · ‎03-12-2014

I'm having some problems getting our traffic engineering working with OSPF, and I think I've finally figured out what's happening. But I can't figure out how to stop it. I think the problem is coming from how the PAN firewalls are importing the external static routes into the area. Here is a "dumplsdb" snippet for one such network, 3 0.0.0.1 10.33.151.86 10.89.4.0/22 type-7 (NSSA Ext) 0x800002FB 0x0000825D 559 36 Options: [NSSA] Mask 255.255.252.0, type 1, tos 0 metric: 1, forward 10.56.1.22, tag 0.0.0.0 Note that "forward 10.56.1.22" field. I think that's what's messing us up. I don't think that needs to be there, i.e. it should be 0.0.0.0. That address is on an interface of the advertising router (a PAN firewall at 5.0.11). When other routers calculate the cost to that 10.89.4.0/22 network, they calculate the cost to reach 10.33.151.86, add the metric on external route, 1, and then also add the cost of reaching the network where 10.56.1.22 resides (even though it's an address on the ASBR itself). Adding that last network is wrong, and it's messing things up. It causes OSPF to choose a non-optimal path to that external network. But I can't figure out why the PAN is adding anything to the "forward" field and cannot figure out how to clear it. I have an open ticket on this, but was hoping maybe someone in the community might be able to answer more quickly. Thanks.

cosx · ‎08-26-2013

What solutions are used to backup Panorama VMs? We want to make a full backup of the VM, not just the configuration and log export tools built into the system. This is for DR purposes. However since we cannot access the system at the OS level, our sys admins can't put vmtools on the system to facilitate with their usual backup procedures. How do other Panorama users do backups of the whole VM?

cosx · ‎08-26-2013

Sorry about that, the version is actually 4.1.6. (When I first looked at the "show system info" output, the "logdb-version: 4.1.2" line caught my eye first.) However, now I'm not really sure I even have a problem... Upon some more testing, it look like even though I have 92 translations "in use," when I actually try to create a new translation, it works. One of the translations that's listed gets bumped out. Presumably it's one of those that has no active sessions associated with it. Maybe the PAN retains some memory of inactive sessions so internal IPs get the same external IP address next time, but those external IPs are still available to new active sessions if needed? So now I may have to look elsewhere for what caused our problems... or maybe we really did run out of mapped addresses. Seems I can't tell by just looking at "show running nat-rule-ippool" how many addresses are really available, if the IP pool is at 100% usage.

cosx · ‎08-19-2013

I am using the original IP address for the <source> and the translated address <xlate-source> since those would be the IP addresses the firewall would see on the original packet that hits the system. So for example, from the "show running nat-rule-ippool" I see, 172.26.202.152 xxx.xxx.xxx.104 1 And I can find, crclark@scea-rhq-sc-pa5050a(active)> show session all filter source 172.26.202.152 -------------------------------------------------------------------------------- ID Application State Type Flag Src[Sport]/Zone/Proto (translated IP[Port]) Vsys Dst[Dport]/Zone (translated IP[Port]) -------------------------------------------------------------------------------- 889910 playstation-network ACTIVE FLOW NS 172.26.202.152[51781]/bp-gaming/6 (xxx.xxx.xxx.104[51781]) vsys1 54.241.139.10[443]/internet (54.241.139.10[443]) However, if I look for, 172.26.200.133 xxx.xxx.xxx.161 30 crclark@scea-rhq-sc-pa5050a(active)> show session all filter source 172.26.200.133 No Active Sessions And if there were to have been an incoming connection (there really shouldn't be, but since I'm troubleshooting, I want to cover all possibilities), it would be found with, crclark@scea-rhq-sc-pa5050a(active)> show session all filter destination xxx.xxx.xxx.161 No Active Sessions Since that would have been the IP address on the original packet that came in from the Internet side before NAT. So I understand why 172.26.202.152 is still holding a slot in the IP pool, but why is 172.26.200.133?

cosx · ‎08-19-2013

I am indeed doing one-to-one NAT, "dynamic IP" only. I do get output from "show running nat-rule-ippool." Are you saying the output is bogus? crclark@scea-rhq-sc-pa5050a(active)> show running nat-rule-ippool rule "Gaming to Internet" Rule: Gaming to Internet ----------------------------------------- Reserve IP: no 0.0.0.0-255.255.255.255 => xxx.xxx.xxx.100-xxx.xxx.xxx.191 Source Xlat-Source Ref. Cnt TTL(s) ---------------- ---------------- ---------- ---------- 172.26.200.133 xxx.xxx.xxx.161 30 172.26.200.250 xxx.xxx.xxx.101 980 172.26.75.32 xxx.xxx.xxx.108 17 172.26.201.27 xxx.xxx.xxx.166 1 172.26.202.152 xxx.xxx.xxx.104 1 [snip] Total IPs in use: 88 Total entries in time-reserve cache: 0 Total freelist left: 92

Member Since	‎06-14-2011 01:52 PM
Date Last Visited	‎01-14-2019 01:28 AM
Posts	26
Total Likes Received	3

Online Status	Offline
Date Last Visited	‎01-14-2019 01:28 AM

About cosx

Re: Google QUIC Disconnects

Re: Issue creating IPSec VPN using loopback

Google QUIC Disconnects

How to Allow an App But Block a "Depends On?"

Re: Restrict Individual Administrators by Interface or IP

URL Filter - Block one and log the rest

Re: superreader Cannot Set CLI Parameters in Panorama

Panorama Backup

Re: Google QUIC Disconnects

Re: Issue creating IPSec VPN using loopback

Google QUIC Disconnects

How to Allow an App But Block a "Depends On?"

Re: Restrict Individual Administrators by Interface or IP

Restrict Individual Administrators by Interface or IP

Re: superreader Cannot Set CLI Parameters in Panorama

superreader Cannot Set CLI Parameters in Panorama

Re: IPsec Phase 2 Lifesize Coutdown

Re: "Forward" Field on External OSPF Routes

"Forward" Field on External OSPF Routes

Panorama Backup

Re: NAT IP Pool Clean Up

Re: NAT IP Pool Clean Up

Re: NAT IP Pool Clean Up

Network Security

Cloud Security

Security Operations

About cosx