Thread Info
  • State Not Answered
  • Replies 6 replies
  • Subscribers 5 subscribers
  • Views 2968 views
  • Users 0 members are here
Options
Suggested

Brainstorming for multi-site LAN (local), WAN (w/IPsec VPN), LAN (Metro Ethernet) setup

Paul Warriner

Hello,

Sorry if this is a bit broad, but just need a nudge in the right direction.

Struggling with how to utilize Metro Ethernet as an SD-WAN path for RO WAN/LAN traffic through HO, and if it is even possible.

Also, similar issue, how to approach using IPsec failover for local LAN traffic in the event Metro Ethernet is down.

Goals are:

  1. To provide failover for LAN and WAN traffic at remotes using IPsec to HO (currently LAN->MetroE, WAN->CableModem)
  2. To provide load balancing for LAN traffic at ROs to HO using the MetroE & IPsec paths

Current schema:

  1. Network LAN traffic is passing over Metro Ethernet to Head Office fine, with OSPF configured and working for 13 RO subnets.
  2. Local internet traffic is passing over local internet interfaces.

 

Remote Offices XG125/135/210 v18-EAP3.

Port 1 – LAN (local networks) 192.168.n.x/24

Port 2 – WAN (internet and testing IPsec VPN to HO) using local cable modem

Port 4 – LAN (Metro Ethernet handoff) 172.30.255.x

 

Head Office XG230 v18-EAP3.

Port 1 – LAN (local networks) 192.168.x.x/16

Port 2 – WAN (HO internet, and planned backup internet for ROs) 

Port 3 – DMZ

Port 4 – LAN (Metro Ethernet handoff) 172.30.255.x

Port 5 – WAN (testing IPsec VPN to ROs)

Port 6 - HA

 

Thanks,

Paul

Parents
  • 0

    It will be much easier with EAP3 Refresh1, because the VTI (Route based VPN) is coming.

    In this concept, you can actually build an IPsec with a Interface and route the traffic with SD-WAN / Static routing.

    In that case, you do not have to figure out, which Precedence comes first. Instead both exists and uses the same "page". 

     

    Another approach would be: Use RED Site to Site.

    Same setup like VTI. You have an Interface for the VPN, so you can actually SD-WAN Route everything. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Well, I am back on this topic, if anyone is interested. I set up RED P2Ps, and I am trying to get  OSPF sorted out, if possible.

    I brought a RED circuit up, and configured 2 LAN gateways:

    1. Port 1 LAN - 192.168.10.1
    2. Port 4 LAN - 172.30.255.10 (gateway 172.30.255.20)
    3. red1 LAN - 172.40.255.10 (gateway 172.40.255.20)

    OSPF Network

    1. 172.30.255.0/24 - Area 0.0.0.0
    2. 172.40.255.0/24 - Area 0.0.0.0 (showing off my naïveté)
    3. 192.16.10.0/24 - Area 10.10.1.1

    OSPF Area

    1. 0.0.0.0
    2. 10.10.1.1

    Everything failed over to RED as needed when I added an 172.40.255.0/24 to area 0 to the below layout (don't know if that is even kosher), but SIP became unreachable a short while later.

  • 0 in reply to Paul Warriner

    Did you check the route precedence?

    https://community.sophos.com/kb/en-us/123610

     

     /  Maybe somebody could take a look at this one?

     

    Another approach: Does your Configuration work with static routes instead of OSPF?

     

    There are two KBAs for this:

    https://community.sophos.com/kb/en-us/132264

    https://community.sophos.com/kb/en-us/125003

     

    In the second one:

    Note: 

    The default OSPF route is shown in its routing table so it is restricted to be added to the kernel routing table. If admin wants to add the default OSPF route to the kernel, he has to manually enable it from the CLI using the following custom commands.

    __________________________________________________________________________________________________________________

Reply Children
Unfiltered HTML