IPSec Mobile VPN client cannot go to OPT1 network

CheeMG

Hi All

Our IPSec Mobile VPN clients can access our LAN without problem but not OPT1 network. We added a Phase 2 entry for OPT1 just like what we did for LAN. See below. Is there anything we are missing? Do we need to add some firewall rule to allow IPSec mobile VPN to OPT1?

Thank you very much anticipation.

Mode: tunnel
Local Subnet: LAN
P2 Protocol: ESP
P2 Transforms: AES(auto),3DES
P2 Auth Methods: SHA1, SHA256

Mode: tunnel
Local Subnet: OPT1
P2 Protocol: ESP
P2 Transforms: AES(auto),3DES
P2 Auth Methods: SHA1, SHA256

Konstanti

@cheemg
Hey
Can be done so
all traffic will go through the tunnel

Phase 2- local network 0.0.0.0 / 0 (instead of two phases 2 there will be only one)
Rules for the IPSec interface
pass from IPSEC mobile client lan to LAN network
pass from IPSEC mobile client lan to OPT1 network

All other traffic will be blocked

or

To test your option
In my example 192.168.1.0/24- Lan Net, 192.168.15.0 / 24 - OPT1 net

CLI- ipsec statusall (When the client is connected)
Check the routing table on the client
Check the firewall rules

CheeMG

Thank you Konstanti for the very helpful reply.
We already had the firewall rule to allow traffic from the IPSec mobile client LAN to OPT1 network in both the LAN and OPT1 rules. We never had to allow from IPSec mobile client LAN to LAN network but the client can access LAN anyway.
We tried using 0.0.0.0/0 in P2 instead of having two P2's but it is still not working.
Checked route print on the client machine and there is no route for the OPT1 network! There is a route only for the LAN network (and that's why client can access LAN).
Do you know what could have caused the no route to OPT1 network?

Also, we setup the same IPSec mobile VPN to access our other office networks (connected using site-to-site IPSec) and the IPSec Mobile client can access to all our offices (route print shows routes to all the office LAN's). The only problem we have is the client cannot access OPT1.

Thank you once again

Active Routes:
Network Destination Netmask Gateway Interface Metric

  10.205.0.1  255.255.255.255         On-link        10.205.0.1    291

10.255.255.255 255.255.255.255 On-link 10.205.0.1 291

(Strange! why is it 10.255.255.255 and not 10.205.0.255 ? In PFSense Mobile, the setting is 10.205.0.0 / 24 )

 192.168.5.0    255.255.255.0         On-link        10.205.0.1     36
192.168.5.255  255.255.255.255         On-link        10.205.0.1    291

IPSec firewall rule:

OPT1 firewall rule:

LAN firewall rule:

Some of the ipsec statusall results:
10.205.0.0/24 is the IPsec mobile VPN LAN.
192.168.5.0/24 is the office LAN
192.168.6.0/24 is the office OPT1 (DMZ)

192.168.3.0, 192.168.4.0 = other office LAN and DMZ
192.168.9.0, 192.168.9.0 = other office LAN and DMZ

con-mobile{472}: AES_CBC_256/HMAC_SHA1_96, 69499 bytes_i (470 pkts, 23s ago), 56880 bytes_o (312 pkts, 22s ago), rekeying in 18 minutes
con-mobile{472}: 0.0.0.0/0|/0 === 10.205.0.1/32|/0

con-mobile{472}: INSTALLED, TUNNEL, reqid 41, ESP in UDP SPIs: c2e3abf0_i 9774a938_o
con-mobile{472}: AES_CBC_256/HMAC_SHA1_96, 92046 bytes_i (630 pkts, 18s ago), 78864 bytes_o (436 pkts, 13s ago), rekeying in 10 minutes
con-mobile{472}: 0.0.0.0/0|/0 === 10.205.0.1/32|/0

con4000{224}:  AES_CBC_256/HMAC_SHA2_256_128/MODP_2048, 0 bytes_i (0 pkts, 1s ago), 0 bytes_o, rekeying disabled
 con4000{224}:   10.205.0.0/24|/0 192.168.5.0/24|/0 192.168.6.0/24|/0 === 192.168.3.0/24|/0 192.168.4.0/24|/0

con4000{226}: AES_CBC_256/HMAC_SHA2_256_128/MODP_2048, 629723604 bytes_i (2369982 pkts, 1s ago), 4208056872 bytes_o (3650146 pkts, 1s ago), rekeying disabled
con4000{226}: 10.205.0.0/24|/0 192.168.5.0/24|/0 192.168.6.0/24|/0 === 192.168.3.0/24|/0 192.168.4.0/24|/0

con5000{163}: AES_CBC_256/HMAC_SHA2_256_128, 320 bytes_i (2 pkts, 12s ago), 0 bytes_o, rekeying disabled
con5000{163}: 10.205.0.0/24|/0 192.168.5.0/24|/0 192.168.6.0/24|/0 === 192.168.21.0/24|/0 192.168.22.0/24|/0

con2000{188}: AES_GCM_16_128, 2734076964 bytes_i (11199757 pkts, 0s ago), 24669898024 bytes_o (17879882 pkts, 0s ago), rekeying disabled
con2000{188}: 10.205.0.0/24|/0 192.168.5.0/24|/0 192.168.6.0/24|/0 === 192.168.9.0/24|/0 192.168.10.0/24|/0

ipconfig on client
Connection-specific DNS Suffix . :
IPv4 Address. . . . . . . . . . . : 10.205.0.1
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . :

CheeMG

@cheemg

Found the problem. We forgot we had to manually add routes on the client to make IPSec Mobile VPN work (not really sure the reason*). So we have to add the route for the OPT1 network 192.168.6.0/24.

Add-VpnConnection -Name "fxpa_allvpn" -ServerAddress xxx.yyy.com -TunnelType "Ikev2"
Set-VPNConnection -Name "fxpa_allvpn" -SplitTunneling $True -AuthenticationMethod "Eap" -EncryptionLevel "Required"
Add-VpnConnectionRoute -ConnectionName "fxpa_allvpn" -DestinationPrefix "192.168.5.0/24" -PassThru
Add-VpnConnectionRoute -ConnectionName "fxpa_allvpn" -DestinationPrefix "192.168.3.0/24" -PassThru
Add-VpnConnectionRoute -ConnectionName "fxpa_allvpn" -DestinationPrefix "192.168.9.0/24" -PassThru
Add-VpnConnectionRoute -ConnectionName "fxpa_allvpn" -DestinationPrefix "192.168.6.0/24" -PassThru

*[https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling](link url)

*The Windows 7 client will always allow access to the host's LAN. So to access, for instance, a local printer nothing special
has to be done. Since the client always proposes 0.0.0.0/0 as remote TS, the gateway is free to narrow it to a subset. But to
make split-tunneling actually work on the client the Use default gateway on remote network option in the Advanced TCP/IP settings of
the VPN connection has to be disabled. Also, because a classful route is installed the virtual IP address has to belong to the
remote subnet, otherwise, the Disable class based route addition option has to be enabled and routes have to be installed
manually.

Windows 10 has split tunneling enabled by default, but with the same limitations seen since Windows 7, i.e. the virtual IP has to be
from the remote subnet, or routes have to be added manually, for instance, via Add-VpnConnectionRoute PowerShell command.
To tunnel all traffic via VPN instead, split tunneling has to be disabled explicitly, either by enabling the Use default gateway on remote network
setting described above or by using the following PowerShell command: Set-VpnConnection "<Connection Name>" -SplitTunneling 0*

Derelict

Yup. Windows 10 requires manual manipulation of the client routes in powershell.

It's an extremely helpful feature.