IPSec Mobile VPN client cannot go to OPT1 network



  • 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



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

    1. Phase 2- local network 0.0.0.0 / 0 (instead of two phases 2 there will be only one)
    2. 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

    1. CLI- ipsec statusall (When the client is connected)
      0_1548833687108_b5b9140a-3983-4f0b-bfc4-f15e5ee127d5-image.png

    2. Check the routing table on the client
      0_1548833762915_ba6ee755-efee-4427-9439-59d7f5248186-image.png

    3. Check the firewall rules
      0_1548833841819_b2f1e35a-acb6-42c6-8a99-b9b6e1644835-image.png



  • 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:
    0_1548901343389_ipsec01.png

    OPT1 firewall rule:
    0_1548901352750_lan01.png

    LAN firewall rule:
    0_1548901358546_lan02.png

    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

    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*


  • LAYER 8 Netgate

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

    It's an extremely helpful feature. 🙄