Ambiguity in manual for SD-WAN policy destination

Does the online help answer your question? 

https://docs.sophos.com/nsg/sophos-firewall/18.0/Help/en-us/webhelp/onlinehelp/nsg/sfos/concepts/PolicyRouting.html

Just wondering: Because there is a lot of information and i am assuming, this should be enough to fix this issue. 

Thanks LuCar, but I've been combing that stuff for a day, and at the moment the brain has turned to mush.

I have a migrated VPN setup that works as expected at another location, but this location is new v18 and more reliant on the SD-WAN.

The WAN traffic for the VPN SLL client is working fine, but all LAN traffic is dropped (nothing in capture).

Thanks LuCar, but I've been combing that stuff for a day, and at the moment the brain has turned to mush.

I have a migrated VPN setup that works as expected at another location, but this location is new v18 and more reliant on the SD-WAN.

The WAN traffic for the VPN SLL client is working fine, but all LAN traffic is dropped (nothing in capture).

Use this command, should work fine afterwards.

Example: console> system route_precedence set static sdwan_policyroute vpn

I had tried that, but I'll give it another go.

No luck. Still cannot get any traffic passing from SSLVPN to LAN, only WAN.

I have tried many variations, but I keep coming back to this, but again only WAN traffic passes from client to XG.

Firewall:

NAT:

SD-WAN

Your OpenVPN Config has your LAN Networks in Permitted Networks? 

With the above, I am now getting to one local LAN subnet, where the VPN connection is made, but not across to anything else in the OSPF range.

I currently have just one other subnet (192.168.20.x) in the allowed resource list of "Permitted network resources", which is back to the head office, but this is not accessible.

The OpenVPN config is listing:

remote x.x.x.x 8443 (public interface)
remote 192.168.10.1 8443 (local lan)
remote 172.30.255.10 8443 (ospf p2p)
remote 10.10.1.1 8443 (local ospf area)

The firewall rule is allowing the remote subnet.

A packet capture shows it forwarding the request:

Just no return.

Oh, so close. :)

Actually, why does the client even send a Packet to 192.168.20.30? This Network is not in the routing table of your split network, isnt it? 

Ah, now the challenge comes to light. Can I make OSPF available to the client?

Yes, it is part of the network, but through OSPF. So, it should be accessible to this client.

OpenVPN is limited to "It needs a Permitted Network". 

If you select Tunnel All, this would not be needed.

If you select Split Tunneling, you need to specify all Permitted Networks within your Network. You could work with /8 Networks