About mlinsemier

  The quick and easy way would be to:   Create a static route to circuit one with a next-hop monitoring of an IP facing your main circuit that would not reply to pings if the circuit is down (say the far IP interface).  Create a second static IP address with a higher metric that points to a gateway on your secondary route.  When the monitoring IP is not reachable for X time, that static route is dropped from the FIB and your second route will begin to be used. Make sure that OSPF has a route to get to the network from both sides, with one being less prefered, so that it traffic is not blackholled at the backup site. Or, use a static route with next-hop monitoring to send traffic back over the backup link. You could get crafty with policy based routing and use it to forward some or all traffic in one direction or another, you just need to match the policy based route on the destination side as well with a matching policy.   We utilize both of these types of setup in our environment so I know that they work, and pretty well.   - Matt ... View more

This may be possible by creating multiple VSYS and then a transit zone, but I would be really careful with having the same IP subnets on the same firewall in the same VSYS.  We ran into an issue where we had the same public facing network on outside multiple interfaces and ran into an issue where bi-directional NAT feature did not work as it would randomly chose to start advertising the MAC address on an interface that did not have rules for that particular NATed IP.  We had to then create both inbound and outbound NAT rules.  Not even sure how this would look or what potential issues you could run into.   In our case we have a separate firewall for sandbox testing.    - Matt ... View more

Reading this post I thought it was myself asking this same question almost 3 years ago.    Up until recently I have had a similar Infrastrucutre (vWire) between our users and our data center to control internal traffic with security policies.  While vWire may be "supported" there are definately alot of caveats and are reasons why we are moving to L3 routed interfaces on the Palo Alto.    Issues with vWire we expereinced: PAN-OS 7.1.3 - 7.1.17 versions tested Cisco port-channeling (PaGP, LACP) will work over vWire interfaces (if tag0 is allowed), however be prepared for asymetrical traffic to be received on the firewall.  Even though we enabled features like allowing non-syn traffic there was odd traffic behaivor an occasion random drops of sessions. Active/Active vWire, along with Cisco port-channeling caused not only asymetrical traffic, but increased TCP response times on traffic.  Ever after multiple cases and debug sessions with Palo Alto we were never able to get this resolved so we moved to Active/Passive configuration. Active/Passive vWire, along with Cisco port-channeling, caused issues with failover as we could never get LACP pre-negotiation features to work correctly so there was always a loss of traffic when we failed over.  Supposively this was supported in vWire, but we could not  get it to work correctly.     As of now we are running all of our L3 traffic on PAN-5220 firewalls at the center which allows us to analyze any North-South traffic from any attached subinterface or VLAN, which is working fantasitc  Failover via to our passive firewall is working as expected with sub second delay (I lose 1 ping). If I was you I would anylze how much inter-VLAN routing you really need to do in the UCS and decide if you want to hairpin it off of the Palo Alto or create local routing.  My opinion, based on the world as it is now, visitibilty is everything.  Just my two cents.     I hope this helps. -Matt ... View more

What Netflow collector are you using?  I know in LiveNX (formely LiveAction) you have to change the flow to Firewall or All Flows to see data.  Additionally, Palo Alto only exports ingress data of an interface (at least that is all I see), so you need to make sure you are looking at inbound traffic. ... View more