- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
11-22-2017 01:12 AM - edited 11-22-2017 01:18 AM
Hey guys,
We do have a headquarter and a branch office.
All services are located in the HQ, in the branch office there are just workstations that access the services of the HQ.
So I have to set up a site to site vpn connection between the BO and HQ.
Let's start with the Palo Alto in the branch office.
I have to create a tunnel interface and choose a security zone.
According to the manual:
"Security Zone: (select the layer 3 internal zone from which the traffic will originate)"
I don't understand that. there are more than one client interfaces/networks in the BO, and each interface is a single zone. So there are more than one internal zones which originate traffic to the HQ.
1) Which zone do I have to choose?
And my second question: 2) When I set up the security policies, which destination zone do I have to use for the traffic that's destination is the HQ ?
and 3) the destination zone in the security policies and the security zone of the tunnel interface, are these the same?
Thanks for any help!
11-22-2017 01:43 AM
there are 2 levels that need to be considered when building VPN tunnels and allowing traffic through
first you need to be able to create the VPN tunnel itself, this works at a lower 'network' level as you bind the tunnel to an interface (either physical or loopback)
so typically you will use your untrust interface to initiate the tunnel
once the tunnel is established, you need to allow user connections to enter the tunnel: creating the tunnel has also created a new interface: the tunnel interface
so any security policies that allow users to connect to the tunnel, will need to be from the user zones to the tunnel interface zone, and reverse in case HQ needs to make connections into the BO (think IT doing remote takeovers)
please check out this article to help you get started: Getting Started: VPN
11-22-2017 02:07 AM
I'm talking about that one: (That's from an instruction video)
Which security zone do I have to choose here?
11-22-2017 02:15 AM
This is where you create the tunnel interface: it is best practice to assign it it's own zone (create a new one, for example 'vpn-to-HQ') so you can control what goes in and out through security policies; from a security perspective it will behave as a physical interface with a zone
from trust to vpn-to-hq allow
from vpn-to-hq to trust allow
you can also choose to put it in the user zone and let the default intrazone poloicy simply allow everything in and out
11-24-2017 03:18 AM
Thank you, that will help me!
Another question, though:
My PA-820 is on 8.0.2 and my PA-3020 is on 7.1.7
1) is that a problem?
2) I want to update my PA-3020 in two months to Version 8, too. Will the Site to Site vpn remain?
11-24-2017 04:05 AM
1. No
2. Yes
ipsec parameters on both PAN-OS are identical so version mismatch is no problem and after an upgrade the configuration will remain identical and the tunnel will immediately work as before
11-24-2017 04:19 AM - edited 11-24-2017 04:44 AM
That's good to know!
I think there is a last question.
We do have a /22 public ip addresses.
And our Global Protect Gateway listens on one of that public addresses. The external interface on our firewall, however, is an ip from our ISP, so it's different from our public space.
The question is, for the site to site vpn. when I set up the IKE Gateway, can I use an address from our public space as a peer or do I need to use the external interface with the IP of our ISP?
For example with a loopback interface?
11-24-2017 05:30 AM
you can either add your public space to your external interface and use that addrss, or create a loopback interface and place it in the external zone (or a different zone and then control ipsec/ike with security policy)
if you need proxy-arp, you'll need to add the public IP range to the interface, and can then still add a loopback for a specific IP. If your ISP is forwarding the entire range to your firewall MAC, you can use the loopback without adding the range to your external interface
hope this makes sense
11-25-2017 08:55 AM
yeah that makes sense, I will try that:)
I finsihed the configuration on my remote firewall.
I'm wondering why I don't see any logs in the traffic monitor that the firewall wants to reach the gateway peer ip address?
Is that normal?
11-25-2017 01:01 PM
12-12-2017 02:45 AM - edited 12-12-2017 02:47 AM
Thanks for your help, the tunnel is working now.
When I want to connect to the firewall via https over the tunnel, the monitor traffic log says:
Application: incomplete
To Port: 443
Action: allow
Reason: Aged Out.
Can you tell me why it doesn't recognize ssl?
The same problem with ssh..
Is the encryption too strong?
12-12-2017 02:55 AM
once the tunnels are up, you need to make sure routing is fine on both sides for the sessions that need to go into the tunnel
you'll need to add a route on the virtual router with the remote subnet pointed at the local tunnel interface. you will also need security policies to allow in- and egress sessions to be created so you'll probably need a few "trust to vpn" and "vpn to trust" rules
are you trying to connect to the managment interface througfh the vpn tunnel?
is the management on the remote end connected to the 'lan' interface or is it in it's own network. you'll need to make sure the whole 'chain' can be reached
eg. routing from your client to your local firewall, routing from your local firewall into the tunnel, security policy on your local firewall to allow the connection. security policy on the remote fiorewall to allow the packets from the tunnel onto the lan, routing to your mgmt interface, routing from the mgmt interface to your client's ip (if there's a router in between you will need to add routing to the firewall), routing on the firewall to return the packet into the tunnel
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!