VPN Clients cannot see internal network after 2.6 to 2.7 upgrade

stephenw10

Hmm, well I wouldn't expect that to make much difference. I also don't expect to see three gateways in the same subnet though.
https://docs.netgate.com/pfsense/en/latest/vpn/l2tp/configuration.html#ip-addressing

What does the routing table at the client look like after it connects?

NZ

The client end shows PFsense v2.7:

Network Destination        Netmask          Gateway       Interface  Metric
    192.168.1.0    255.255.255.0      192.168.1.247    192.168.1.248     26
    192.168.1.248  255.255.255.255         On-link     192.168.1.248    281

Even if we choose a completely different network for the VPN.
eg 10.10.10.1
Same thing.

So were out of ideas. Don't understand why it works fine like this in v2.6 but not in v2.7
As mentioned, the difference we found was in the way the gateways are structured.

Another thing I should add, is that we also have site-to-site IPSEC VPN tunnels setup between locations, and they can route to each other without any issue.
Infact, we can even ping the LAN on the remote IPSEC VPN from the client. But that same client cannot ping anything on the LAN it's initially VPN'd to.

So the issue seems to be with the Mobile VPN, since site-to-site is fine.
It's very odd. Doesn't make much sense.

stephenw10

Hmm, both ends of the L2TP are pfSense? I has assumed this was a remote access setup?

NZ

For L2TP were connecting with Windows built-in L2TP client.
So Windows connects to the PFsense L2TP via PFsense Mobile IPsec.

Basically we setup the PFsense L2TP server.
And the PFsense IPsec Mobile Client.
Then remotely connect with Windows to PFsense.

stephenw10

Ok, that's what I had assumed originally.

So is there a difference at the client routing table between 2.6 and 2.7?

NZ

We also checked that during our tests.
Routing table on client is same regardless 2.6 or 2.7
The only routing entries Windows gets from PFsense are the ones I listed above.

Also a tracert looks like this.
in v2.6:
Tracing route to 192.168.1.45 over a maximum of 30 hops
1 14 ms 13 ms 15 ms 192.168.1.247
2 17 ms 15 ms 16 ms 192.168.1.45

in 2.7:
Tracing route to 192.168.1.45 over a maximum of 30 hops
1 11 ms 4 ms 5 ms 192.168.1.247
2 * * * Request timed out.

.247 being the PFsense L2TP server IP.

This is why I think the the Gateway Link# assignments may have something to do with it. That's the only difference we've noticed so far.

NZ

@stephenw10

Any suggestions on what settings we can try?
Using Mobile IPSEC that is.
We don't want to use OpenVpn.

Unless this is a bug in the system that needs to be worked out?

stephenw10

You're able to use mobile IPSec dircetly? Without L2TP?

NZ

Only way to do that is ipsec to ipsec endpoints.
(eg Pfsense to Pfsense)
And yes that works fine.

We use Windows clients.
They need some kind of tunnel initiator like PPTP or L2TP.
I don't know of any way to IPSEC from Windows without that.

But you may be on to something, the L2TP server in Pfsense.
That's what creates those gateways in the route table.
But again it works fine in v2.6
So there must be an issue in v2.7 with L2TP server.

stephenw10

You can use IKEv2 mobile IPSec on Windows directly. It's just not as straight forward:
https://docs.netgate.com/pfsense/en/latest/recipes/ipsec-mobile-ikev2-client-windows.html

NZ

I will have to test it out.

But what do we do about the l2TP server issue?
Only other option is downgrading to v2.6

stephenw10

The only thing I can think of that might possibly be affected is the filtering change. Try setting 'IPsec Filter Mode' to assigned interfaces in the IPSec advanced settings.

However if that was the issue I'd expect to see blocked traffic in the firewall logs. Unless you have custom block rules without logging maybe?