Private (RFC 1918) networks encrypted en routed via VPN

[Johan_Klasson]

Hi,

I have a problem with a Remote Access setup via IPsec where I can't manage to get the VPN Domain setup sane (I think).

Server:
R80.20 VS Instance running on 23900 cluster.
VPN blades: IPsec VPN
Office Mode: Enabled

Client:
E83.20 on Windows 10 behind NAT

Problem:
Client connects just fine and get an IP via DHCP according to config.
But, no traffic get routed and encrypted via the tunnel.
If I disable Split Tunneling, and enable  "Encrypt all traffic and route to gateway" on client,
all non-RFC 1918 networks get routed via the tunnel.
I can also see broadcast traffic and tunnel_test from the VPN network in the FW logs.
Also, when I do "route print" on the client, a huge amount of routes have been added.

Question:
Any pointers how to resolve this?

Best Regards,
Johan Klasson

[PhoneBoy]

What is your precise Encryption Domain set to?
You can set a different one for Remote Access than for site-to-site VPN.

”Route all traffic” literally routes all traffic from the VPN client through the encryption domain which means you’ll see routes for all RFC1918 addresses on the client as well.

[Johan_Klasson]

Thanks PhoneBoy for taking the time.

The Encryption Domain is set to the VPN network.
I tried setting it specifically for Remote Access, but with the same result -> fail.
Also, I really want no Split Routing so it's strange that only external "public" IP ranges get through the tunnel but not private?
For example the 10/8 network is not visible in the routing table on the client, hence it should utilize the "default" routes 0/1 and 128/1 but it seems traffic to these network hitting a blackhole.
The log indicates outbound traffic from the firewall does in fact reach the FW and get encrypted, the problem seems to be on the client side?

[_Val_]

By VPN networks, what do you mean? The internal networks behind VPN GW? Or something else?

[Johan_Klasson]

Sorry, should have been more clear.
VPN network in this context is the network given to the client side and used to connect to LAN/WAN via the tunnel.
Maybe Office Mode Network is a better term?

It may also be worth mention the Remote Access community i also used by another GW running R77.30.
I just noticed the "Credentials are needed for a secondary tunnel connection" where the GW is this other GW:
Can the problem be it using this GW instead of the intended one?

[PhoneBoy]

I'm having trouble understanding what your actual configuration is.
Let's focus on the Remote Access encryption domain should be.
This should include all the networks behind your gateway that you wish for your client to be able to access.
There will also have to be relevant Access Policy rules to allow this in addition.
If there are networks available that you wish for your clients to access that are available from a Site-to-Site VPN peer, those networks must also be included in the Remote Access encryption domain.
Further, the remote end will need to include your Office Mode IP address range as part of the encryption domain on their end.
Your network should also know to route the Office Mode address range to the relevant gateway.

It's going to be difficult to troubleshoot this without posting private information on the community.
Therefore, your best bet is to engage with the TAC.

[Johan_Klasson · Accepted solution]

It has been solved.

After much trial-and-error from TAC, they asked me to download and test an earlier version of the client.
And behold, it actually started working 🙂

E81.40 worked but NOT the newer E83.20.

Regarding the encrypt domain (VPN Domain): When using E83.20 it didn't matter. With E81.40 it does.