Video on how to configure OSPF across an IPSEC Tunnel on the Sophos XG

Thank you for you answer Scott,

I can see the same with OSPF without putting the subnets in the IPSec config.

Nope, I have only created a Point-to-Point GRE tunnel.

I made a factory reset yesterday when trying your suggestions, so my routing preference is in default order now

Just an update. I tried BGP and it didn't make any difference. I have also tried upgrading to 17.1 and that made no difference

It's actually a bug and has been assigned to NC-32269

Hi Kenneth,

Thanks for the info.  Is there is any Summary of what that bug actually is?  (Im not sure if Sophos publishes open bugs or not)  I'm assuming it effects both BGP and OSPF in certain cases, as you said you had tested both protocols without success?

-Scott

Hi Scott,

Not to my knowledge. I got the number from an employee. Yes the routing protocol doesn't make a difference

Hi Kenneth

I have the same case and actually the traffic via IPsec tunnel don't encrypted.

Description my case:

- Using OSPF via IPsec Tunnels between HO and Brach site (both of SophosXG)

- I have following the KB https://community.sophos.com/kb/en-us/131827

So I have some question about this KB and hope you can help me:

- Do you know how to set the subnet mask for GRE tunnel ?, seem the GRE tunnel using the default mask by the class

- Up to date, Have any solution to fix unencrypted via IPsec or RED tunnels is the best choice ?

- In my topology; the sophos at HO site will be using default original-information for default route to Sophos-Brach to learn ? But seem the Sophos-Brach alway prefer the defaultGW of WAN Link over OSPF, can you know how to fix it ?

Thank so much

Hi Gecko,

I had the same experience initially, but eventually got it working and saw only ESP packages until i did a reboot of the appliances, then the traffic showed up as unencrypted again.

-There's to my experience, no way to set the subnet mask for the GRE tunnel.

-OSPF over RED is working fine and GRE isn't needed since you get an interface to do the routing on. IPSec on the other hand is broken until we see the issue number from my previous post as fixed in the changelog. I hope they will fix it in one of the next releases, cause it's a serious security issue.

-I have never tried that, so you're on your own on that one. But have you looked here?

Hi Kenneth

Thank you for your respone

-There's to my experience, no way to set the subnet mask for the GRE tunnel.

=> ok, I got it

-OSPF over RED is working fine and GRE isn't needed since you get an interface to do the routing on. IPSec on the other hand is broken until we see the issue number from my previous post as fixed in the changelog. I hope they will fix it in one of the next releases, cause it's a serious security issue.

=> Ok, I got it

-I have never tried that, so you're on your own on that one. But have you looked here?

=> Yes, I mean the Sophos_Branch have learn default roue over OSPF well (the default route show in OSPF routing table) but when I try connect to Internet from PC-Branch and the traffic alway using defaultGW of WAN link instead of OSPF.

My case is all traffic will focus to HO, not go though direct from local site.

And you have set the default-information originate on your HQ site? 

It should be straight forward when looking at this article https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/47868-ospfdb9.html

Routing order in SFOS is the following:

Kernel Routing:

1. Local Connected Networks
2. Dynamic Routing Protocols

XG Routing (you can change the precedence of these three):

1. Policy Routes
2. VPN Routes
3. Static Routes

Could it be the Masquerading in your firewall rule that makes the traffic leave the local interface? I will have to play around with it next week if you need more help

I made a setup in my homelab with OSPF over RED interfaces. The OSPF route table on branch office has learned the 0.0.0.0/0 route via 172.16.10.1 but as you said the traffic still leaves the local wan interface.

I made a work around by creating a static route on the Branch office 0.0.0.0/0.0.0.0 gateway 172.16.10.1 <-- RED interface on HQ... And now the traffic leaves my HQ, we are either doing something wrong or the feature isn't working, my guess is the latter, since creating a static route defeats the purpose of dynamic routing