Advisory: Support Portal Maintenance. Login is currently unavailable, more info available here.
I made a video on how to configure OSPF across an IPSEC Tunnel using the Sophos XG. Hope you find it useful. I'm also open to video suggestions if you have any :)
Amazing job David, I am listing it on the TOP of the list for other's to reference whenever required.
Sachin Gurung Team Lead | Sophos Technical Support Knowledge Base | @SophosSupport | Video tutorials Remember to like a post. If a post (on a question thread) solves your question use the 'This helped me' link.
Thanks sachingurung I've always appreciated your speed to respond also :) You're doing a great job on the community :)
I have tried following this KB, but it doesn't seem like the traffic is being encrypted. I can see http traffic (in my test) going between the sites when using wireshark on a pc connected to a mirror port where the source is the port connected to WAN interface on one of my XG firewalls.
I have tried the following:-Using the Public IPs as local and remote networks in my ipsec config, just like in the KB-Using the GRE IPs as local and remote networks in ipsec.
Using IPSec with policy-based routing encrypts the traffic
click on the image to make it larger
Sophos UTM 9.3 Certified EngineerSophos UTM 9.3 Certified ArchitectSophos XG v.15 Certified EngineerSophos XG v.17 Certified EngineerSophos XG v.17 Certified Architect
I finally got it fixed. My issue was routing priority.
By default XG (17.0.8MR8) is using the following routing precedence:
I went into the CLI used option 4 to get to the console and then changed the precedence with:
console> system route_precedence set vpn policyroute static
I'm now seeing ESP traffic in wireshark and no HTTP traffic when accessing the webserver from my client
I give up.. the traffic was unencrypted again after a reboot of the XG appliances.... RED tunnels seems like the only option
Here's what we did (although we're using iBGP instead of OSPF)
-Using the Public IPs as local and remote networks in the ipsec config(just like in the KB), use the GRE IPs as local and remote networks in ipsec and finally use the subnets at each site in the ipsec config. You need all three(or more if you have more than one local subnet on each side.)
So at the end of the day you'll have at least three definitions for local and remote sides(wan ip's, GRE endpoints, and finally each sites subnets you want to talk back and forth)
Good one David.
I will give it a try today :-) But are you sure the routing is carried over iBGP in your example and not because of you adding the networks in the IPSec config? The reason i wanted to use a dynamic routing protocol in the first place was because of the benefits of dynamic routing and not having to configure all the networks in the IPSec config
I made a factory reset of both XG Appliances (testing environment) and then followed the KB again. But this time i added both WAN and GRE ip in the IPSec local trusted network and remote trusted network and the wireshark pc is now showing ESP packages instead of the ICMP and HTTP traffic i use for testing. BUT rebooting the appliances makes the traffic unencrypted again. It seems like the GRE is coming up before the IPSec tunnel and then the traffic goes over that instead of IPSec
Adding the local and remote networks as well to IPSec didn't make any difference
Just saw the messages. Are you particularly looking to use iBGP or any dynamic routing protocol?
OSPF is my preferred protocol in this test. But I'm willing to test iBGP if that works
"But are you sure the routing is carried over iBGP in your example and not because of you adding the networks in the IPSec config?"
Yeah, routing is carried over iGBP, I can see all the BGP routes populate in the information tab under BGP screen after it gets it routing table pushed to it(takes a couple minutes). In my case the other side of the connection is a Cisco router.
You didn't create any GRE routes by chance ? We don't have any GRE routes in place in our setup on the Sophos. We also didn't change the routing order preference either.