Extending VLAN through IPSEC + GRE

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Extending VLAN through IPSEC + GRE

L1 Bithead

I am trying to extend the VLAN from main site to branch site using a combination of GRE and IPSEC.

 

Below is a quick representation of the architecture, the objective is to enable remote communications between the main and the branch sites for all devices within VLAN-1. 

 

OELHANCHI_0-1714232289883.png

 

 

I am aware that PA does not natively provide L2 tunnels, and VXLAN would be the more appropriate solution for this kind of need, but right now just wondering if this is even possible with only 2 PA firewalls ? 

 

What i've achieved so far is a ping from 172.28.89.252 to 172.28.89.254 and vice-versa, which is a good start, but whenever i try to route towards 172.28.88.250 through the GRE or IPSEC tunnel, i either get a TTL exceeded indicating a loop somewhere, or no response at all. 

 

I'm also exploring other avenues at the same time such as redistributing static routes with OSPF or BGP over IPSEC, but to no avail so far. 

 

Any insight would definitely be greatly appreciated ! 

 

 

 

5 REPLIES 5

L1 Bithead

This is not supported with PA unfortunately. 

 

GRE is limited to L3.

L6 Presenter

@O.ELHANCHI wrote:

I am trying to extend the VLAN from main site to branch site using a combination of GRE and IPSEC.

 

Below is a quick representation of the architecture, the objective is to enable remote communications between the main and the branch sites for all devices within VLAN-1. 

 

OELHANCHI_0-1714232289883.png

 

 

I am aware that PA does not natively provide L2 tunnels, and VXLAN would be the more appropriate solution for this kind of need, but right now just wondering if this is even possible with only 2 PA firewalls ? 

 

What i've achieved so far is a ping from 172.28.89.252 to 172.28.89.254 and vice-versa, which is a good start, but whenever i try to route towards 172.28.88.250 through the GRE or IPSEC tunnel, i either get a TTL exceeded indicating a loop somewhere, or no response at all. 

 

I'm also exploring other avenues at the same time such as redistributing static routes with OSPF or BGP over IPSEC, but to no avail so far. 

 

Any insight would definitely be greatly appreciated ! 

 

 

 


To me this would really be reliant upon the 2 independent networks and how the PA would route to those networks.

 

The branch fw would have a route that points 172.28.88.0/23 to eth 2/1 and a route for 172.28.88.0/23 to eth1/1 and vice versa at the main location.  You will want ECMP on both firewalls as well.

 

At this point it would be "luck" as to the path the packet took from the firewall.  

 

I don't really think this scenario would functionally work very well, but it could get you what you wanted.


@Brandon_Wertz wrote:

 

The branch fw would have a route that points 172.28.88.0/23 to eth 2/1 and a route for 172.28.88.0/23 to eth1/1 and vice versa at the main location.  You will want ECMP on both firewalls as well.


Hi and thank you for your contribution to this topic, 

 

I assume from this sentence, that you meant directing 172.28.88.0/23 to eth1/1 on both sides, as branch fw can not directly point to remote eth2/1, except through the tunnel interface which is eth1/1 in this case. 

 

In which case yes, this is something i've already tried of couple weeks ago, i had a static route on each firewall directing subnet 172.28.88.0/23 through the tunnel interface with a metric of 1.

 

What happened in this case was that i could see the ping reaching all the way from the branch fw to the main fw, to the host natted behind the main fw.

 

I did a wireshark on 172.28.88.250 and was able to see the echo requests all the way from the branch fw, but no reply. I believe the exact reply packet showed a "No response found", if my memory serves me right. 

 

This seemed to indicate that ARP on main site wasn't capable of going through the tunnel, however what i did not try is setting up ECMP. 

 

Obviously would love to give this solution an other try, as it is from my perspective, the most simple to implement, and while it's for many many reasons not ideal to opt for most scenarios, in this particular use case, the pros outweighs the cons in a pretty substantial manner (geographic proximity < 5km, no duplicate addresses etc., simplicity, L2 traffic)

 

 

More than likely your experience here:

Brandon_Wertz_0-1715788144222.png

 

is because you didn't have ECMP enabled.  The setting is in your VR setup:

Brandon_Wertz_1-1715788237381.png

 

Hey @Brandon_Wertz , thank you again, took off some time today to try this out, as I was very curious. 

 

Here are the screenshots if you would still be interested in landing me some more insights  : 

 

Below are the results of a ping from branch fw 172.28.89.252 to a natted host behind main fw, 172.28.89.248

 

Logs from Main FW (172.28.89.254). As you can see the ping arrives well through the tunnel.

OELHANCHI_0-1715864225431.png

And below the wireshark results on the natted host 172.28.89.248, with the infamous no response found icmp packets even with ECMP enabled on both sides quite unfortunately :

OELHANCHI_1-1715864330054.png

 

For completeness sake here are the related routes left in my VR configuration on Main FW ... technically you can disregard the last 2 routes, they are remainings from previous tests, only the first one really matters in this. 

OELHANCHI_6-1715864846479.png

And VR on the branch FW looks like this: 

OELHANCHI_5-1715864683788.png

As a side note the packet wouldn't reach branch FW without the last explicit route ... Strange.

 

Both sites have ECMP enabled on their VR like so : 

OELHANCHI_3-1715864646031.png

 

Any suggestion ? 😇

 

 

 

  • 528 Views
  • 5 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!