In this blog post we are going to be focusing on site-to-site VPN. There are a couple of important things to take into consideration when planning and implementing site to site VPN. The technical configuration part is I guess the easiest part, that is being able to get the connection up and running between two endpoints or sites so to speak. However, the main job or work is to plan the network design and implement the site-to-site configuration accordingly. I guess the main thing to consider or remember is that the implementation or I should rather say, the design should fulfil the business needs and not other way around. However, the solution should provide a solid defense against known and unknown threats alike. I have previously worked with Cisco primarily ASA firewalls, however, going over to Paloalto Networks Firewalls made me really forget that world without really missing anything.
We are going to be focusing on Paloalto Networks Firewall site to site VPN, with UserID enabled on the entire tunnel along with UserID connector. The user will be authenticated on the remote site, and then their ID will be passed along to the central site (firewall) using UserID connector. Having this approach, the user would not need to re-authenticate when connecting to or trying to access resources found at the central site. I will not be listing out any obvious requirements that are like licenses required and stuff like that but I will rather be focusing on the key points and elements that require design decisions and planning before implementation time.
The solution can be implemented with the smallest Paloalto networks firewalls to the largest ones. Depending on what kind of equipment you have and what kind of infrastructure you own and are planning to invest within. The scenario described here has been implemented with a PA-3220 and a PA-220 at several remote offices. Needless to state that the 3220’s are clustered and if you need the same level of redundancy and high availability you would do the same with the PA-220, i.e. setting up a clustered instance. However, if you are going along that path, you should also have at least redundant power supplies, and redundant internet service providers providing reliable internet connections, redundant switches etc. You can then not have a single point of failure. I have been working with Paloalto Networks Firewalls for 5-6 years and have yet to see a firewall fail due to hardware issues.
In a site-to-site scenario the main thing to consider is the IP plan, I guess everyone gets that, but there are also a couple of other things to consider. For example, when you will be deploying a firewall at a remote site and need to manage it centrally, you would require a backdoor into the firewall management plane. If you are following security best practices, you should at least differentiate between production and management networks. By management networks I mean, the management network for the firewall, switches and any other servers present at the remote site. Normally or actually the standard configuration on Paloalto firewalls is that the management interface is utilized for services like DNS, CRL etc and Paloalto services (downloads, Wildfire, Updates etc). As a general rule of thumb, you do not want to expose your management interface to internet. If you are going to do that, or if you are forced to do that, you should at least safeguard it as much as possible.
My general implementation or call it rather standard design is a have at least a couple of VLANs which are dedicated to firewall and infrastructure components, including servers. Normally for server rules, we end up using IP addresses as filtering mechanism as using UserID is normally not an option. Let’s assume that you have created at least a couple of VLANs for this purpose.
First thing is first, in order to use service interfaces the PA-firewall must be configured with a static IP address otherwise you would not be able to specify the interface as service-interface. This is done under Network, and interfaces.
After you have configured an IP address on your public interface you can start working with the service interfaces.
After you have made sure that configuration is correct as well as functional and all the service routes are functioning you can now proceed to the next step of the configuration. Again, for the sake of complicity, you would be configuring the rules prior to start configuring site-to-site VPN. This should also include enable management of firewall from internet, but only from specific and know IP addresses belonging to you or your corporate. You should also configure zone protection for internet facing interface and download and install the latest PAN OS version that you are using within your enterprise environment. Not have to large gap between central and remote firewall PAN OS version will save you from a lot of headaches, however, my experience with PAN OS version newer that 8 has only been positive, meaning there has not been any known problems with regards to site-to-site VPN due to PAN OS version mismatch. Occasional problems might surface, hence the advice to upgrade the software to acceptable level.
I personally like to configure intra zone rules to drop all traffic within the zone, especially for internet facing zones, I do not know why Paloalto prefers to consider Internet facing interface traffic to and from internet okay, and still protect the firewall, however I find it very confusing as the firewall logs keeps on showing that rather strange traffic is being allowed through the firewall. The easiest solution, at least for the comfort of my mind is to drop all and any traffic that I do not want or do not know.
Now you need to start configuring the site-to-site VPN, and here is where you get the first couple of design decisions. You start the configuration under Network, Network Profiles, IKE Crypto
You can either choose to use one of the built-in policies or you can choose to create your own. Please remember that this IKE phase 1 policy must be configured using same parameters on both ends that is on the central firewall and on the remote firewall. After you have configure a policy the next step is to configure the IKE Gateway, this is done under Network, Network Profiles and IKE Gateways
If you specify IKEv2 only mode, which I would recommend you must remember to configure the settings under Advanced tab, this is where you specify profile for IKEv2.
Next step in the configuration is to define the IP-Sec tunnel settings. This is configured under Network, IPSec Tunnels. This is also the place where you can watch the status of the VPN tunnel. As long as the tunnel is up and running the icon appears green while if its down the icon appears red.
Now to the more fun stuff. In order to use UserID on the VPN tunnel, you first must enable UserID on the zone which is being utilized by the tunnel. This is done under Network, Zones by selecting the zone and checking the box Enable User identification.
Now if you are like me and a blocking intra zone traffic within internet zone, you would at least require a firewall rule to allow inbound IKE traffic, otherwise the firewalls will not be able to establish a site-to-site VPN connection. It should be sufficient only with the IKE application as identified by Paloalto App ID
So now the basic foundation has been laid and for UserID to function we need one more block or piece of puzzle. In order to make UserID function, your firewall must be able to read the domain controller security log files or you must set up a windows based agent which does this job on behalf of the firewall. In my customers case I normally set up the firewall to perform this action. The firewall must utilize the VPN tunnel to perform UsedID, however, this has its own cost with regards to bandwith usage along with the problem that if UserID fails the entire remote office would be without internet access. To cope with this scenario, you can configure catch all rules at the end of the rule set allowing limited internet outbound traffic without UserID. However, the problem arises with regards to DNS as the clients at the remote site would most probably be using an internal DNS server. The best solution would be to have local one, however, depending on the size of the remote office you might not have a local DNS server. In that case you can either use the DNS servers at the central site or you can choose to use DNS proxy within Paloalto firewalls.
Remember the VLANs that I mentioned during the first few paragraphs and introduction of this blog post? Now it would be a good time to utilize of these for DNS and well as for keberos and Ldap traffic, because you cannot specify a tunnel interface for the service interface, however, you can specific a VLAN that utilized the tunnel interface.
Another important thing to configure is that routing, you must specify static routes through the VPN Site-to-Site tunnel and specify the default route through the internet facing interface ethernet1/1 in my case.
Another tip or thing I almost forgot is the configuration of UserID Connector. You must allow traffic to you partner firewall on port 5007 (udp). In addition to configuration of UserID, you must also configure the redistribution which is done under Device, User identification, Redistribution.
The password you specify here, must be specified on the receiving end i.e. on the central firewall. Once this has been done, you would have functioning UserID from end to end and only minimum amount of traffic must be allowed based on IP addresses.
Apart from the configuration of firewalls and site-to-site VPN it is a good idea to define a site in active directory services and connect that site with some specific Domain controllers so that you do not need to add all the domain controllers to the remote firewalls. You can for example consider the remote clients as client machines and route all traffic to specific Domain controllers rather than some random ones. I have worked in environments where customers have had more than 100 domain controllers, and believe me, you do not want to start querying all these domain controllers all the time! If that becomes that case, your firewalls will be consuming a large amount of bandwidth just for DNS and UserID, not to mention the Wildfire and updates traffic. I hope you find the blog post useful. I normally tend to get a lot of questions from my customers regarding site-to-site VPN and UserID and hope that most of these have been answered here. The beauty of this design is that, you can use internal DNS servers for the firewall as well, because the site-to-site VPN is not dependent on DNS to get established as long as you have used IP address based site-to-site VPN.
However, if you have any questions feel free to ask them/post them, I will try to respond to these whenever I get the first change.
Software Version considerations
As I already have mentioned, you should try to have save level of PAN OS running on your firewalls, however, that recommendation is easier said than to practice for most folks. So at least try to have the same major version of PAN OS. When it comes to virus definition version and application ID version, these should match and be identical, reason being, you do not want one application to be identified on one firewall, not being identified on the other or would you? (considering one of these having an older definition of AppID package/verion).
Hopefully you already have considered the bandwidth needs and requirements for you remote offices , however if you have not, now it would be a good time to consider what is available and not. Major things to take into consideration are
- Bandwidth required by infrastructure components
- Bandwidth required by end users
- Bandwidth required by Paloalto networks Firewall
Besides this you should always consider throughput for the firewall being utilized and with the capabilities and features that have been enabled. Luckily if you are reading this blogpost you will be using Paloalto Networks firewalls which are single pass firewalls, meaning the packet is inspected once by the engine and does not require additional resources when you enable features. I personally have not been involved in any implementation where this has been an issue, but have helped customers who were in similar scenarios and situations.
Monitoring Site to Site VPN connection
For day to day monitoring you can check the system logs on the firewalls. However, I would recommend forwarding syslog messages and applying some sort of filtering on the receiving part. Can can also configure resources on the other end to continuously be monitored and raise alerts when the resources are unavailable, however, you then would also require some sort of altert notification unless you are planning to monitor the networking tabs and check the IPsec tunnel status to always be green. If you are using a monitoring tools like Operations manager from Microsoft or any other tool for that matter and it supports and URL monitoring, you can configure URL monitoring from the remote office to the central office. Sadly a whole lot of my personal customers rather focus on not setting up monitoring to save the costs and rely on end users to report any problems, which sort of works for the most, but when you get problems, you really do not have clue about what and why stopped the things from working. Hope the blog post has somewhat been informative and helps shred some light on new aspects of site to site VPN using USERID based access and UserID forwarding. Untill next time, take care.