way to do site-to-site with single tunnel and preserve security rules for intra and interzone?

[matthew.hanyok]

hello all,

I've got to add a new satellite office into our network and I was hoping to do this with a single tunnel. If that were all that was required I'd probably be fine, but it's complicated by the fact that several years ago when our network was built it was decided, presumably for budget reasons, to use our PA hardware as router, firewall and switch. Our current configuration is less than ideal but I don't have the ability to bring new hardware into the mix or to substantially change the architecture right now.

What I mean by this is that all of an office's internal traffic flow is decided by the security policies on the PA device. Here's an example:

Site A:

interface 1/2.60, tagged 60, "office" zone, IPs 10.1.1.0/24

interface 1/2.70, tagged 70, "lab" zone, IPs 10.1.2.0/24

Site B:

interface 1/2.60, tagged 60, "office" zone, IPs 10.1.11.0/24

interface 1/2.70, tagged 70, "lab" zone, IPs 10.1.12.0/24

And so on (we have 7 sites).

There's an intrazone-allow rule at each site, but inter-zone is blocked.

Why it was done this way instead of using the switches to block off the vlans, I couldn't say (I wasn't on the team when the architecture was built), and I can't go and make significant changes right now as I'm working on our production network.

Further complicated things, for site-to-site, the prior designer decided to just establish a tunnel for each zone:

tunnel.60 - "office tunnel"

tunnel.70 - "lab tunnel"

Then set additional rules to allow "office" and "office tunnel" to talk to each other, and "lab" and "lab tunnel" the same. They also put each zone into a separate virtual router so they could set the routing tables to look like:

vr "office" (member interfaces 1/2.60 and tunnel.60)

10.1.0.0/16 -> interface -> tunnel.60

0.0.0.0/0 -> next-vr -> "exit"

vr "lab" (member interfaces 1/2.70 and tunnel.70)

10.1.0.0/16 -> interface -> tunnel.70

0.0.0.0/0 -> next-vr -> "exit"

vr "exit" (member interfaces eth1/1, "untrust/internet")

0.0.0.0 -> eth 1/1

It keeps them isolated while going from site to site, and it works, I can't argue with that, but you can imagine that the design isn't really scalable if you need to add more zones to all of the sites. Especially if you're on PA-500s for some of your satellite offices, which only support 3 virtual routers and have a 50mbps vpn tunnel limit.

I'm looking for any suggestions on the best way to shrink this design to a single tunnel / virtual router. Ideally I'd like to preserve the tagged vlans and have the PA on the other end of a connection recognize the tag and consider it traffic from a certain zone. For instance:

ping from Site A, 10.1.1.50 to Site B, 10.1.11.50 is tagged with vlan 60

traffic routed to tunnel for Site B

packet received in Site B, PA sees it is tagged with vlan 60

traffic routed to interface 1/2.60

vlan 60 recognized as "office" network and traffic is allowed

The only option that I've come up with so far would be to use address ranges in my security rules, like so:

address group "office-addresses":

10.1.1.0/24

10.1.11.0/24

10.1.21.0/24

etc

address group "lab-addresses":

10.1.2.0/24

10.1.12.0/24

10.1.22.0/24

etc

Rules:

"office" is allowed to "tunnel"

"lab" is allowed to "tunnel"

"tunnel" and source "office-addresses" is allowed to "office"

"tunnel and source "lab-addresses" is allowed to "lab"

This would work, but it's... well, it isn't pretty, and I was hoping for a more elegant solution. Is there another way to do this using only PA firewalls? If I can figure a way to do it I can utilize globalprotect satellite tunnels and avoid writing out our entire network in routing tables, without having to come up with a complicated way to keep the security rules valid.

[jpeters]

It doesn't get much more segmented than that lol. One thing I was not clear on was are your remotes in a mesh or hub and spoke topology?

Since vlan tags are at layer 2 and ipsec layer 3 passing along vlan tags over your vpn tunnels using PANs would not be possible. You would need MPLS capable devices to accomplish this and at that point wouldn't really need the VPNs 🙂

Also I wouldn't say the firewall is switching but is basically acting as a router on a stick with the sub-interfaces. I am assuming your port 1/2 is trunked to a switch on your LAN? This is actually pretty common if you can't spare a seperate interface on the firewall per vlan. And yes switches are good at segmenting layer 2 by vlans, but are blind to ip traffic (unless they are L3 switches) so unless you had one firewall per vlan, this seem like a good setup and also pretty common.

-I would say scale back to one vpn zone and 1 tunnel interface per site in that zone

-I would scale back to one VR per firewall with all interfcaces in the same VR.

-Setup your routes accordingly out the tunnel interface

-Setup security policies from your office zone subnets in site A to your Site B office subnets and vice versa with VPN as the destination zone.

-Setup another rule with your lab zone subnets from site A to lab subnets Site B (and vice versa) with VPN as the destination zone.. One can do these within one rule per zone (office, lab) which would look something like this...

Rule 1:

Src Zone: Office, VPN -- Src IP: <officeA IPs>,<officeB IPs> -- Dst Zone: VPN, Office -- Dst IP: <officeB IPs>,<officeA IPs> -- Allow

Rule 2:

Src Zone: LAB, VPN-- Src IP: <labA IPs>,<labB IPs> -- Dst Zone: VPN, LAB -- Dst IP: <labB IPs>,<labA IPs> -- Allow

You would configure these on both firewalls A and B. A being a data center firewall and B a remote. If you need the remote labs and offices from each of the 7 sites to speak to each other respectively through a central point you would be looking at many more subnets in your rules and vpn routes, but essentially the same concept. 

You already have office and lab in seperate zones and a no interzone traffic rule in place. Segmenting therouting tables and VPN tunnels isn't giving you any more security then you already have with the interzone security rules. There is no way anything in your lab zone will be able to communicate with your office zone (and vice versa) if you have proper security rules in place and your interfaces assigned to the correct zones.

What you have now is 'virtual' segmentation since the traffic enters and leaves the same device over the same physical links, its not truly segmented at all. So I'd say simplify it, rely on good security policy and strip off all the extra config.