About John_Braswell

All,   I'm attempting to alleviate some of the day-to-day operations that we do, and found that VM-information sources might be useful. I've got a test environment that can talk to a test vCenter and pull the attirbutes, but I'm not able to get the tags back from the server. Are tags a readable parameter for the Palo to use to build dynamic address groups? If so, what's that look like on the match criteria. the documentation is very sparse on how to build the criteria. I've found that notes are something that can be used, but tags would be more apt I think. Maybe not. Is anyone using this feature? Do you like it, not like it, is it ever troublesome, has it helped with Ops on a daily basis or is it still about the same as before you implemented? I know that's a lot of questions, I'm really trying to understand if this is where I should be focusing my efforts at.   Thanks, John ... View more

Hello all,   I'm trying to get some access restricted to a few subnets that fall into our /16 range that we currently have in our Palo. The way it would look is we would have 2 subnets smack in the middle of the /16 that we only want to allow access to a handful of hosts in that subnet, yet block everything else in that range. To explain it clearer, we currently have access from our DC servers to all the subnets contained within a superset of 192.168.0.0/16. That means the DC's can get to all hosts behind this range and do what they need to. It's been determined that a couple of /24's need to have access restricted to them, say the 192.168.2.0/24, and 192.168.100.0/24 range, allowing the DC's to access a few hosts in those ranges excluding the remainder of hosts in 192.168.2.0, and 192.168.100.0. Everything else would remain the same. The way I've figured to do it is to clone the rule and do some subnetting that allows that same access, but carves around the 192.168.2.0, and 192.168.100.0 subnets, except those hosts in those ranges. Would that be how you guys tackle that, or is there a cleaner way to do it that I'm not thinking of? Any guidance is appreciated, thank you! ... View more

Hey guys,   Looking for some assistance on getting a strange issue resolved. I've got a site-to-site VPN set up for a connection to AWS for one of our customers. I've created two loopbacks, loopback.5 and loopback.6, on the outside zone that fall in the same subnet as our regular ethernet interface, which is a /29. I've verified that our peers IP's can reach each other successfully, so routing is good there. I've also had two techs from AWS look at the Palo config, everything is matching their side, they saw our traffic, our cookie ID, all that good stuff. I've entered in the PSK at least 6 times, and nothing is coming up. I also asked about the proxy ID's, just to make sure they weren't needed, tech said they don't use them. I decided to do a pcap just for grins to see what was actually happening, and from what I'm seeing, the Palo is taking the traffic from the AWS side and shunting it from loopback.5 to loopback.1 for whatever reason, where it gets dropped, because that's just wrong. Is there any explanation that you guys could think that would explain why the packets are being processed this way? I'm going to include some logs for you guys to review, I'm hesitant to upload the pcaps, but I can if it's helpful. Thanks a lot for looking, hope the answer jumps out at somebody!   Palo Alto 5050-PanOS 5.0.12   GwID   Name                 Peer Address/ID                 Local Address/ID               Protocol   Proposals -------- ----                 ---------------                 ----------------               --------   ---------        1 ike-vpn-e0c72a89-0   xx.xx.xx.xx (ipaddr:xx.xx.xx.xx) xx.xx.xx.xx(ipaddr:xx.xx.xx.xx) Main       [PSK][DH2][AES128][SHA1] 28800-sec   tunnel   IPSec-Tunnel1         id:                     4         type:                   IPSec         gateway id:             1         local ip:               xx.xx.xx.xx         peer ip:                 xx.xx.xx.xx         inner interface:         tunnel.3         outer interface:         loopback.5         state:                   init         session:                 12359         tunnel mtu:             1427         lifetime remain:         N/A         monitor:                 off         monitor packets seen:   0         monitor packets reply:   0         en/decap context:       19494                 local spi:               00000000         remote spi:             00000000         key type:               auto key         protocol:               ESP         auth algorithm:         NOT ESTABLISHED         enc   algorithm:         NOT ESTABLISHED         proxy-id local ip:       0.0.0.0/0         proxy-id remote ip:     0.0.0.0/0         proxy-id protocol:       0          proxy-id local port:     0             proxy-id remote port:   0         anti replay check:       yes         copy tos:               no         authentication errors:   0         decryption errors:       0         inner packet warnings:   0         replay packets:         0         packets received           when lifetime expired:0           when lifesize expired:0         sending sequence:       0         receive sequence:       0         encap packets:           0         decap packets:           0         encap bytes:             0         decap bytes:             0         key acquire requests:   1429   phase-1 SAs GwID/client IP   Peer-Address           Gateway Name           Role Mode Algorithm           Established     Expiration       V   ST Xt Phase2 --------------- ------------           ------------           ---- ---- ---------           -----------     ----------       -   -- -- ------               1 xx.xx.xx.xx          ike-vpn-e0c72a89-0     Init Main PSK/ NO/ TBD/ TBD                                 v1   3   2       0   Show IKEv1 IKE SA: Total 1 gateways found. 1 ike sa found.   phase-2 SAs GwID/client IP   Peer-Address           Gateway Name           Role Algorithm               SPI(in)   SPI(out) MsgID     ST Xt --------------- ------------           ------------           ---- ---------               -------   -------- -----     -- --               1 xx.xx.xx.xx:0       ike-vpn-e0c72a89-0     Init     /     /   /     /     00000000 00000000 00000000   0   0   Show IKEv1 phase2 SA: Total 1 gateways found. 1 ike sa found.   System log, I tried GoogleFu, not much luck other than passphrase:     2015/11/11 13:44:31 info     vpn     ike-vp ike-neg 0   IKE phase-1 negotiation is failed as initiator, main mode. Failed SA: xx.xx.xx.xx[500]-xx.xx.xx.xx[500] cookie:bf1b32ec25b3acd5:0000000000000000. Due to timeout. 2015/11/11 13:44:31 info     vpn     ike-vp ike-neg 0   IKE phase-1 SA is deleted SA: xx.xx.xx.xx[500]-xx.xx.xx.xx[500] cookie:bf1b32ec25b3acd5:0000000000000000. 2015/11/11 13:44:33 info     vpn     ike-vp ike-neg 0   IKE phase-1 negotiation is started as initiator, main mode. Initiated SA: xx.xx.xx.xx[500]-xx.xx.xx.xx[500] cookie:d5290c9ce7032f8d:0000000000000000. ... View more