About darren_g

OK, based on your Visio, I'd do the following. 1) Trunk VLAN 61 and VLAN 1 (you should *not* be using VLAN 1 for traffic on a Cisco network, BTW - it's bad practise since VLAN 1 is the default "untagged" VLAN in most installations) to the Palo Alto's over your existing links - you're probably going to have to reconfigure to make the physical interface a layer 2 interface rather than a layer 3, and move your layer 3 configuration/zone into a VLAN interface rather than a layer 3 type interface. 2) Add an interface for the VLAN 61 into your PAN device - make it the default gateway for the entire 1.1.1.1 subnet, and route *all* traffic across the trunk into the Palo Alto device. 3) Configure firewall zones/rules as appropriate to allow the access you want. Alternately, if you have a spare interface and if it's physically viable (I.E. you can cable the switch to suit), then plug the Adtran switch (1.1.1.1) network directly into a spare interface on the Palo Alto and remove the link to the 10.10.10.10 switch, then do the layer 3 configuration on the new physical interface, and likewise configure zones/rules as appropriate. I've attached a modified version of your Visio which indicates what I mean - the green lines indicate the first suggestion, the red the second. ... View more

That's a nice, polite corporate line, but I smell male bovine droppings. I don't mean to be confrontational, but on both occasions where I've needed a hotfix (in my current installation, not counting previous positions), it's been for fairly major issues - the high management CPU with 4.1.11-h1, and from memory a HA synchronisation issue with 4.1.8-h3 - issues, especially in the case of the high management CPU which were/are affecting a *lot* of people, judging by the comments and queries in this forum. Releasing these to general population and posting a broadcast email to subscribers (as is done for maintenance outages etc) would be the best action - then users can choose to apply the hotfix if they're experiencing the issue concerned. And your comment about thorough QA is patently untrue - if it was, then the issue with the management CPU wouldn't exist across several different releases 9I've seen reports of it from 4.1.11, 5.0.1 & 5.0.2 so far) - or, if it's true, Palo Alto needs to hire some new QA engineers, because the existing ones are falling down on the job - these aren't obscure, little problems - they're issues which are part of the *core* of the system which makes Palo Alto better than, say, Cisco or Checkpoint - and they...are...failing. Either Palo Alto's definition of a "full QA testing cycle" is different to mine, or it's not being done properly. OK, maybe I *do* mean to be confrontational. But with what we pay for these boxes compared to other solutions, I expect them to work WITHOUT running into such basic bugs. ... View more

Your way would work, but I always try to avoid layer-2 VLAN's on firewalls because I don't want to add the complexity of spanning-tree to the situation. Personally, I'd put your "satellite" network into a separate DMZ zone on a layer 3 interface, and just apply appropriate routing. Then, applying security policy is dead easy - source zone satellite, destination zone main, destination host ZZZ, allowed apps XXX & YYY. I use that method for a couple of client networks which connect via my PA's - have them in a separate layer-3 DMZ interface, route the appropriate subnets to the interface, then just apply security policy to the entire zone. Of course, this assumes you have spare ports to connect the additional networks to - if you don't, then I'd combine layer 2 VLAN's and layer 3 to get the same effect (trunk into the device, but put the VLAN into a layer-3 zone to do the security policy on). ... View more

The problem is the VTC device isn't ours - all we have is the dopey software component (RealPresenceDesktop) - the actual Polycom device is at the other end (and, annoying, in another state, so I can't just lob over and smack them upside the head while saying "hey mate, THIS is what you need". I found an old discussion on here which strongly suggests what you're saying (and what you're saying seems to confirm the older post) that the issue is the dumb device at the other end, not our end - especially when you consider the justification for the other end saying nothing is wrong is that they "Can make calls internally fine". Huge red flag for me, based on the older discussion (and your comments) says they've got it configured with an internal IP address, and it's being brain dead with the NAT'd stuff. What I may have to do is run Wireshark on the PC we're testing from, try to capture the traffic during testing, and then use that to ram down their throats. Cheers. ... View more

Trust me, I already have. 🙂 ... View more

I'd rather avoid another App Override if I can - I don't think it'd work anyway, since number 2 in my list exhibited the same problems as number 1 did. I'm just grasping at straws, trying to see if there's some trick to making this steaming pile of.....product work with a secure environment. Thanks ... View more

OK - how do you deal with application over-rides? (I know, I know, they're a case of baby did a bad, bad thing, but I need one). If I set "application default" on those, will they break anything else? In effect, an application override just looks at the port for the specified designation, right? So "application default" should be fine? ... View more

Thing is, I'm not "new" to PA. I had (have, I suppose) a PA certification in the V3 OS, and this is now the third place I've successfully pushed the installation of the PA firewalls into (yeah, I kinda like them compared to other stuff, how did you guess? :-)) - I just plain bloody *forgot*, and then asked a stupid question. Of course the firewall was trying to identify the application before dropping on non-standard ports - because I didn't tell it not to! I'm going to go hide my face in shame now. ... View more

> Just out of curiosity, what does your 'Service' column look like in your rule base? Is it set to 'application-default'? Damn, you're right, and I'm a butthead. It is set to "any", Because I'm a bloody idiot and missed changing that when i set up this (and a couple of other) rules. It'll shortly be set to "application default" and, I hope, resolve the issue. Cheers! ... View more

> I wouldn't call it "leaking" data.  It allows a handshake on that port, and then validates the application after the handshake takes place. But the port upon which the handshaking is taking place is *not* in the allowed list. It's not an issue is the app identification occurring after the handshake - the initial (SYN, I assume) is being logged as "allowed" on a port which is *NOT* in the list of ports covered by the "allow" list. In the example I originally quoted, the port identified is 1433 - MS-SQL - but the allow list for the rule concerned consists of web-browsing (tcp/80) subversion (tcp/3690, udp/3690) webdav (tcp/443, tcp/80) There is no allow for tcp/1433 which can possible be allowed under those rules. ... View more

>Since the traffic was initially leaked to make the determination for the application and no further processing happened on it since it was allowed. > It shows up as allowed in the traffic logs. But the actual traffic *is* dropped, yes? I'd hate to think some of this stuff actually leaks to the servers inside the DMZ! ... View more

Yes, I understand why they show as "incomplete" - what I want to know is why they are logged as ALLOWED by the firewall, not logged as dropped. Surely, the logic would be "if it matches, allow, if it doesn't match, or doesn't complete, then drop"? ... View more

No, it's definitely present in 4.1.11 (and the supposed "hotfix" 4.1.11-h1 breaks other things) - and as far as I'm aware you can't do agent-less userID on v4. ... View more