Enhanced Security Measures in Place:   To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.

"LAN" Interface Failover configuration - Primary: dedicated Line, Secondary: VPN

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

"LAN" Interface Failover configuration - Primary: dedicated Line, Secondary: VPN

L2 Linker

Hi there,

 

maybe it's not that complicated but I didn't find a post for this scenario:

 

The LAN of our Clients are in Location1

(~ 200 km)

The LAN of our Servers are in Location2

 

Location1 and 2 are using the same firewall which is stored in Location 2 because Location 1 has a dedicated line to Location 2.

The Primary connection between Location1 and 2 is via a direct connection through the backbone from our ISP - with private IPv4 Addresses. The Firewall is not involved in the LAN traffic between the locations, just for the internet access.

Everything in this case is fine, but

the secondary connection between Location1 and 2 is via a LTE Router. I've established a Site2Site VPN between the LTE Router and our PaloAlto Firewall incl a tunnel monitor to make sure the connection is always online. In this case the Firewall is involved in the "LAN" and internet traffic.

 

I do not know how to configure a failover for the case that the primary connection is broken and everything is going through the LTE Site2Site VPN connection.

I´ve tested the basic functionallity of the LTE connection with routes with a lower metric than the primary but that was only to make sure that the LTE is basically working -> has nothing to to with autmatic failover.

 

My Problem is that the environment is already productive and I only have a 60 minutes maintenance window per week and that's not that easy to find the perfect solution in this short time ( it's a PA-500 😉 could take a looot of time to commit)

 

Cheers,

Stephan

 

 

1 accepted solution

Accepted Solutions

Mission impossible....I do not get it up and running with STUN....and after ~ 8 hours testing I will delay it to maybe end of the year....=/

 

View solution in original post

8 REPLIES 8

Cyber Elite
Cyber Elite

can the LTE perform source NAT ? that could fix your issue easily

 

alternatively you could try setting up policy based forwarding with symmetric return path to have packets put into the VPN if they came out of it

 

2016-04-22_11-17-18.png

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

Hi reaper, thanks for your answer.

 

I do not have access to the LTE router but I can ask our ISP to do it but I am not sure if get your point.

You mean that clients in the LTE Site2site got a different IP address than in the normal network and then I can configure different routes for that IP, right? I think that's not thaaaat easy because we have different networks in Location 1

Management, DHCP, VoiP, dedicated customer network and the DHCP Server (dhcp relay configuration) for those networks is stored in Location 2.

 

I think I like your second solution more 🙂

If I understand you right I need the following setup

For Primary:

Like before, just entries in my routing table

 

For secondary:

PBF Rule1 for LAN:

Source: Tunnel from LTE

Destination: LAN on Location2

Forwarding: Egress Interface = LAN Interface of the Firewall, Next Hop Address List = IP of the source Tunnel from LTE

 

PBF Rule2 for Internet:

Source: Tunnel from LTE

Destination: Everything

Forwarding: Egress Interface = External Interface of the Firewall, Next Hop Address List = IP of the source Tunnel from LTE

 

 

if the LTE performs source nat, the PaloAlto will see a whole different IP range when the backup is used, making routing as simple as adding a static route

the source nat would simply contain a state table with a mapping to the different networks, it could be a many to one, or a many to one equally sized continuous subnet, or some other implementation... the LTE would be responsible for maintaining a state table and the amount of source networks should not matter

 

but indeed, this is either a quick and dirty fix OR will require some thought and might be a little complex if you want to do it properly

 

...

 

yes, those rules will make sure that IF something comes out of the tunnel, returning traffic is then not matched/processed by routing but pbf stuffs it all back into the tunnel as part of the symmetric return

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

okay, I will try it with the PBF rules next week and update this post.

 

Thanks,

Stephan

Hi there,

 

i've tried the configuration, but looks like tunnel interfaces or zones can not be used for symmetric return. Any other idea? If you think it's useful I can post the screnshots of my configuration

 

vsys1
Error: pbf rule 'LTE-LAN': Source cannot be zone if nexthop list is specified.
Error: pbf rule 'LTE-LAN': Fail to parse symmetric return.
Error: Failed to parse pbf policy
(Module: device)
Commit failed

Warnings

Error: pbf rule 'LTE-inet': Source interface cannot be tunnel interface when nexthop address list is configured.
Error: pbf rule 'LTE-inet': Fail to parse symmetric return.
Error: Failed to parse pbf policy
(Module: device)
Commit failed

hm, sorry about that, was not aware this doesn't work on tunnel interfaces

 

The other way you could achieve this is by reversing the routing/pbf part: set up PBF rules for all traffic from and to the regular WAN link with symmetric return, then have a static route as fallback to the LTE VPN tunnel 

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

I solved the problem in that way:

I've merged the primary routing configuration into PBF (withouth symmetric return) with zones as source addresses incl interface monitoring. My secondary connections - LTE - is managed via routing.

All my traffic will be sent via the PBF policy and in case that the next hop is not reachable the PBF rule will be disabled and my static routing will send the traffic through the VPN tunnel.

but:

I still have problems with our IP telephones because they are not working when I switch the configuration to PBF like described above. I tested the basic network functionallity with a host in the telephone network and everythings is fine so it must be related to the SIP application etc. ALG is already disabled. The configuration and routing is nearly the same as for the dhcp network.

 

Any Idea why the network is working but the IP telephones not?

Mission impossible....I do not get it up and running with STUN....and after ~ 8 hours testing I will delay it to maybe end of the year....=/

 

  • 1 accepted solution
  • 5229 Views
  • 8 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!