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).

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

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

Shouldn't the "Tunnel Access *" section (GUI) provide this, as I have the 192.168.20.0/24 network listed?

I had tried a /16 and went back to just keeping the testing focused to one additional location.

I have another question, if the Client is actually seeing the traffic by the SSLVPN Client and you are talking about "Routing" (OSPF), is there a route for the other devices to use the IP Segment of SSLVPN? 

Could you check the OSPF Settings, if your 10. SSLVPN Configuration is actually published to other devices? 

Maybe the route back to XG is missing, hence the destination server gets the ping, but does not know how to answer. 

All the remotes have the following:

LuCar,

I think you nailed it.

This is from .20 side (I'm sure somebody is getting my packets).

Any idea how I get them back?

Paul

LuCar,

All it took was getting a new range for the remote VPN network, and adding to the OSPF table. 

I think my initial problems were firewall or sd-wan rule related, so I reverted, and found I didn't need, the "Example: console> system route_precedence set static sdwan_policyroute vpn". Just in case I am missing something related to this, please nudge me back to your suggestion.

Thank you maestro, for your time and patience.

Paul