About panman

In the Network>IPSec Tunnels GUI, you have basic monitoring functionality for the status of each IPSec VPN connection...using those green/red "LEDs". If you need more than that, usually something on that IPSec peer is abnormal, and you have to view the logs anyway to troubleshoot. From the help section of that page: Viewing IPSec Tunnel Status on the Firewall Network > IPSec Tunnels To view the status of currently defined IPSec VPN tunnels, open the IPSec Tunnels page. The following status information is reported on the page: Tunnel Status (first status column)—Green indicates an IPSec SA tunnel. Red indicates that IPSec SA is not available or has expired. IKE Gateway Status—Green indicates a valid IKE phase-1 SA. Red indicates that IKE phase-1 SA is not available or has expired. Tunnel Interface Status—Green indicates that the tunnel interface is up (because tunnel monitor is disabled, or because tunnel monitor status is UP). Red indicates that the tunnel interface is down, because the tunnel monitor is enabled and the status is down. Hope that helps... ... View more

That article doesn't really apply for building out the multihomed design from the diagram I previously attached. Unfortunately I can't change our production PANs to make screenshots for you. However, I am expecting a PAN VM-100 lab license here in the next day or two, so once I have a lab firewall running, I can build and and export a lab PAN configuration, with included screenshots. If you would be willing to PM or email me the following CLI output of your PAN setup, we'll get the sample config as close as possibly to your environment and then all you should have to do is copy it to get yours working correctly show interface show interface all show routing summary show routing route show routing route type bgp show routing protocol bgp summary show routing protocol bgp peer show routing protocol bgp loc-rib show routing protocol bgp rib-out Good Luck, Josh ... View more

Thanks Kelly. Yep, better late than never Yes I do remember now that configuring Nonstop Forwarding will allow a route process to continue processing and forwarding session packets upon a peer failure or stateful failover. So in your reply, am I understanding correctly that when a failover occurs on the active/passive PAN pair, the BGP routing instance (and any dynamic protocol) is reset and actually has to re-converge once the passive firewall takes over the "high-availability state functional" status? Nick's reply (Apr 4, 2011 12:40 PM) above contradicts this. Or, are we all saying the same thing, that if the PANs and upstream BGP peers at the ISPs are NSF aware (by use of GRES), then BGP forwarding will be completely uninterrupted by a PAN failover event. Gosh I can't remember if 'Graceful Restart' was enabled by default (in the VR's BGP>Advanced tab) on the PANs when we deployed PANs...either that or I did enable NFS awareness with our ISPs at the time, as you had suggested to do so in your document. Just for fun, can you elaborate more on your "management plane BGP sessions" comment. I'm still confused on the PAN functionality of handling routing processes on the management plane vs data plane, and that hardware offload for packet processing (which is perhaps totally unrelated to the planes)? I've concluded the same as you regarding a BGP default plus partial tables, as the best option for small/medium enterprise. Josh ... View more

As far as configuring a physical interface with the public /24, some would debate whether to do so or not. I have seen where some architects/engineers will place the publicly published hosts directly on the /24 subnet (which is configured on a physical interface). Personally I see no need to do that, and would prefer to hide published hosts behind a NAT and the firewall. I'm sure there are various designs which work well too. Sometimes it's handy to have a physical port on your CE or CPE devices to uplink a laptop for example, directly on your /24 public subnet, for performing penetration testing or traffic simulaiton etc. which is sourced externally of your firewalls. In that case you can configure a spare interface on the PANs with you public subnet, but be careful what public IPs the PANs learn via that interface, so that published traffic doesn't blackhole traffic to that interface. You will also have to evaluate how this affects the requirements of pre-NAT source on the routing table. The purpose of having the public /24, is one of your ISPs most likely assigned you a /24 from their owned prefixes. Because you are obtaining a commercial ISP circuit, its easiest for them to require you to peer via BGP. Therefore, the /24 was most likely assigned to you because commercial BGP requires no less than a /24 per public eBGP speaker to keep Internet routing tables manageable. In essence, you secured a public /24, (which is quite difficult anymore) and you have a lot of flexibility to publish your public services at least while IPv4 is around . For the high availability of your public services that you mentioned earlier, now what you can do is to throw a ADC (I recommend a F5 LTM) on a PAN interface, and publish each public IP/service from the ADC. The ADC will then load balance on the backend (routed through the PAN firewalls security) to your configured pool of servers for each published service. Correct. You would use a "connect" for the Redist profile, and leave the interface blank. I'm working on a screenshot thing...need some more free time -Josh ... View more

I did the same thing too the first time. Basically what you want to do is revert the firewall you upgraded, and then when the HA pair is back how they were running 4.1.7, you can start over and follow the proper method. If I remember correctly, this should work... On active (4.1.10) firewall you upgraded, export the last several configs that the system saved before and after you upgraded the firewall. You can do this from Setup>Export>Export>Config Verison in the GUI. This step is precautionary, just so you have a copy of the config it was running before and after you upgraded the firewall.                    Next, make sure the running configs are synced in the GUI's Dashboard>HA pane. This will ensure your latest config will be retained on the HA pair. Suspend your primary (4.1.10) firewall using the Device>HA>Operation Commands>'suspend local device' in the GUI, or the "request high-availability state suspend" from CLI. The 4.1.7 firewall will now be the active firewall. Now in Device>Software you can install the 4.1.7 software to revert the firewall back. After it reboots, the config (we just synced) from the active 4.1.7 firewall will be pushed over. Both firewalls are now running the same OS again, and you can make the downgraded firewall the active node again by performing the 'suspend' and 'make functional' procedure on the opposite firewall. Now you are back to square one, and you can follow this guide for the correct procedure to upgrading a clustered pair: ... View more

You have the correct idea. If you are new to BGP, it sounds like you are needing to set up a multihomed ISP edge. 'Kbrazil' put together a really good PDF on the different designs that are possible. Please reference this post: Your main job to deploying the edge is to correctly route your company's public traffic to and from your ASN: a) Announce your ASN to the Internet via one or more BGP-peered ISPs. (This is so that external, ingress traffic knows how to reach services that you'll publish on your ASN, that is, your allocated public /24 subnet) b) Peer to one or more ISPs and receive BGP tables (routes). (This is so that internal, egress traffic can route to the correct Internet destination via the best AS path) So to answer your original post, the BGP edge design you choose will dictate how the interfaces will be configured on the PANs, since there are a bunch of different ways depending on what you're trying to accomplish. The main questions that you need to answer:      a) how many ISPs you want to peer to (via BGP, we assume)      b) if you have a single or pair of PAN firewall(s)      c) active/passive or active/active cluster configuration (if a pair)      d) BGP tables passed to you from each ISP:           You will need to collaborate with your ISPs to provide one of the following BGP table options (the same option for all ISPs)           i) Full Internet tables (you'll need to verify your PANs support this, and your BGP speakers (the PANs) cannot flap -unless the ISPs configure hold down timers (dampening) on your AS announcement to              prevent flapping BGP propagation)           ii) Partial tables with a default route (best method)           iii) Default route only Once you've identified the above questions, post them here and we can define how you'll configure the various public and private networks on the PAN interfaces. As a summary, your ISPs will each mostly likely give you a /30 public subnet that you will peer to them via BGP using 'external' interfaces. Then you will place your public AS /24 subnet on your PAN routing table, either with a static route, or locally connected on a interface (or preferably both-using metrics- for stability). Finally, you'll configure BGP to announce your ASN to each peer and implement BGP filter/export lists applied outbound toward each ISP to prevent transient routing between your ISPs (and so will they). You'll also need a metric of some type that will default or load balance internal, egress traffic, for example a filter/import list that applies a higher weight to one of the ISPs default route.  The rest of your private networks can be configured on 'internal' interfaces, and your publicly published services (www, dns, mail etc) from those interface(s), (DMZ etc) can be NAT published to the public AS /24 subnet, which will then require a matching public DNS record to resolve each NAT'd service to the corresponding public IP. ... View more

Hi kbrazil- Regarding Dual box multi-homed bgp config – full mesh, HA cluster (Active/Passive) on page 6 of your document...we are currently using that design on our production Palo cluster deployed just a few weeks ago. I'm interested in what you mean by 'GRES for BGP failover' as one of the pros/cons, could you explain more how that works? The best peering setup that I have come up with for the above design is: ISP A and ISP B peers announce the summary routes of their owned prefixes, plus a default route. We announced our AS prefix (public /24) to both ISPs. An import route map sets a higher weight on learned routes from ISP A than those from ISP B. This installs on the Palo only the default route (0.0.0.0/0) from ISP A, and will install the ISP B default route only if ISP A peering fails.            The result is: Externally sourced, ingress traffic bound for our AS arrives at the Palo on the closest AS path via either ISP. Internally sourced, egress traffic bound for prefixes announced by either ISP will egress via that same ISP peer (closest AS path). All other internally sourced, egress traffic will egress on the Palo's default route. I am debating whether there would be any benefits to removing the default route method, and instead route internally sourced egress traffic out across both ISPs with some type of load balancing mechanism. This could theoretically double our ISP bandwidth among other benefits. Any ideas on what the best BGP path selection algorithm would accomplish this? Also I'm thinking that there would need to be some type of mechanism on the Palo for source and destination IP address binding; basically to ensure sessions route symmetrically, that is, the packets flow ingress and egress on the same path. On the other hand I am thinking that the only real improvement to my current set up listed above would be to have both ISPs announce full internet BGP tables, and remove the default route, bu that comes with another set of responsibilities... Anyone have input on this BGP routing setup? ... View more

...terminate one or two of your sites to the Palo and evaluate it We just migrated to Palo firewalls and we switched our IPSec VPN architecture over also. We have Cisco routers at a dozen or so remote sites with static public IPs that terminate thier IPSec tunnels back to the Palos at HQ. Prior to switching our VPN over, I did a lot of lab testing with different IPSec VPN scenarios such as full mesh, hub/spoke, static VPN routes and found that I found that the Palos are very versatile and and seem to handle almost any design. We use Cisco at the remote sites, but Juniper routers should work just as well...the SRX series for example, can do policy based or route based VPN. I used this guide for our set up...but for your Juniper routers you will just have to do some lab testing for the VPN termination architecture. How to Configure Dynamic Routing over IPSec against Cisco routers: https://live.paloaltonetworks.com/docs/DOC-2250 As for your stability comment about Juniper releases...I know what you mean. We use the Juniper SA Series and the software releases upset stuff very frequently. The stability of your new design would be determined by how often you upgrade software on your remote Juniper routers and on the Palo. Because you will be working with the dedicated Palo hardware (vs your current VPN termination approach using the Juniper NSM), I don't expect core features (such as IPSec) on the Palo changing as much where it should cause stability issues with VPN tunnels. ... View more

I assume when you say UTP, you mean that both active and passive Tier 2 Palo firewalls will each have a ethernet uplink (CAT5e) to the Tier 1 firewalls? In order for this to work, the uplinks of the Active/Passive Tier 2 firewall cluster which would be placed downstream of the Tier 1 firewall cluster would need to be connected to layer 2 ports which share the same state table on the corresponding upstream Tier 1 firewall (that is....the same ARP and MAC table). This would be required for HA transition to operate on the Tier 2 firewalls. I guess it depends on what kind of firewalls the Tier 1 are it may work...if you have Cisco ASAs for example, you might be able to use two layer 2 switch ports to uplink to the Tier 2 firewalls. Or other vendor firewalls might let you put those ports into some kind of layer 2, pass-through mode. No guarantees here without lab testing though...this is theoretical. ... View more

...well we are working on a hot site co-lo effort based on Cisco's OTV using Nexus 7000s, with 1Gig dark fiber as the co-lo circuit....so Im not sure if I can offer much advise for your type of senario. For a small shop, your DR project might be something to involve a 3rd party consultant if your business requirements need it to absolutely work. What I can tell you from what I have concluded through budget research efforts for our company's DR model, is that basically DR sites and co-location is not a defined thing that you can grab a standard design template off a Google search and deploy it, because the business requirements in each given situation will dictate what the design will be (ei, simple data backup site, cold/warm/hot site) and how much you can spend on it. Most businesses will need to take small steps, one at a time, to reach a desired DR model. Given that, one will probably find an industry trend that small businesses typically will limit DR efforts to doing data replication, log shipping via a IPSec VPN for example. Mostly, you will find that WAN bandwidth to a co-location/DR site will dictate what type of DR model you build out and how much a company is willing to spend on it. A DR design such as a cold site that stores replicated gigabytes of data, or maybe some backups of production VMs, will require decent bandwidth itself, with offline replication often happening during off hours depending on your technology. You'll find that an IPSec VPN will very quickly saturate for what you are trying to build out. Any more significant design than a very basic cold site such as I described, will most likely require a dedicated WAN medium or private circuit to the co-location for feasibility of the technology involved....and once you get into purchased bandwidth/WAN circuits, whatever medium you choose to use, the coin dropped on these efforts start quickly start sky rocketing and at that point your business may as well implement a decent, [more]expensive solution. Thus, you'll find that larger business and enterprises with expensive data to protect are are the ones spending dollars on DR and co-lo cold/warm/hot sites or farming out the DR model's physical infrastructure to a cloud computing service or third party. Hope that helps. ... View more

I guess its not very clear what you are trying to accomplish with your proposed subnetting architecture.....why would you want you use overlapping subnets at Site A and Site B for a IPSec VPN? That just introduces routing complexity by introducing the NAT requirement, and then also having to resolve DNS at Site xx for the opposite Site xy to the NAT'd ranges. It really depends on what you need the design to do. It almost sounds like you are trying to design a "mirrored" co-lo architecture, which is a bit beyond using a simple IPSec VPN for the inter-site routing. If you are planning to operate your Active Directory and VMWare infrastructure, for example, across g eographically disparate datacenters then that would involve extending your Layer 2 networks using some type of routing technology like Cisco's DCI... http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11_493718.html ... View more