Skip to main content
levicki
levicki
New Member
March 1, 2021
Question

[SOLVED] IPsec L2TP VPN routing broken

  • March 1, 2021
  • 2 replies
  • 17477 views

I have an IPsec L2TP VPN configured on Fortigate FG-60F at our office.

 

When a VPN client connects from their home PC using Windows built in VPN client, then their home public IP (let's use 10.20.30.40 as an example) becomes totally inaccessible from any PC in the corporate LAN.

 

After some digging, I discovered that establishing a VPN connection adds a static route for the VPN client's public IP which despite higher distance (15 .vs. 10) compared to default 0.0.0.0/0 route is more specific (10.20.30.40/32 via OFFICE_VPN) and as such it takes precedence for all traffic originating from corporate LAN to 10.20.30.40, including the traffic not initiated by the VPN client itself, which in my humble opinion does not make any sense whatsoever.

 

I have a ticket open with support, but apart from suggesting that I add "set add-route disable" to phase1-interface which makes it impossible to connect to VPN at all they haven't provided any acceptable solution. What is worse, they are arguing that this is expected behavior.

 

Over the past 12 years I have worked extensively with Cisco ISR, Cisco ASA, Mikrotik, OpenWRT, pfSense, Vyatta, iptables/StrongSWAN and so far I have never encountered such behavior. Based on that I am claiming it is a bug in FortiOS unless there is some obscure setting somewhere that can resolve this which I have yet to discover but even then, this behavior is totally non-standard.

 

Can anyone here offer any suggestions?

    2 replies

    emnoc
    emnoc
    New Member
    March 1, 2021

    Not a bug it's just how a L2TP vpn works.

     

    You need to modify the local route table or use a L2TP-vpn client that allows print-local-resources.

     

    Or 

     

    Don't use L2TP , but use ipsec or sslvpn imho

     

     

    Ken Felix

     

    levicki
    levickiAuthor
    New Member
    March 1, 2021

    emnoc wrote:
    Not a bug it's just how a L2TP vpn works.

     

    Hi Ken and thanks for responding.

     

    I don't agree that this is how L2TP works because I used numerous other implementations and they didn't have such limitations. Please also see the update I posted.

    emnoc
    emnoc
    New Member
    March 1, 2021

    Do a google search and you will see numerous issues with the exact same thing with sonicwall , fortigate ,cisco,etc....

     

    Again change the vpn client and you probably will have better success. Here's a macos 10.15.4, notice how the .112 .113 are using en0 ( my lan adapter )

     

           

    supports-MacBook-Pro:~ ken$ netstat -rn -f inet

    Routing tables

     

    Internet:

    Destination        Gateway            Flags        Netif Expire

    default            192.168.1.99       UGSc           en0       

    default            link#13            UCSI          ppp0       

    10                 ppp0               USc           ppp0       

    10.19.19.1         10.19.19.2         UH            ppp0       

    127                127.0.0.1          UCS            lo0       

    127.0.0.1          127.0.0.1          UH             lo0       

    169.254            link#4             UCS            en0      !

    192.168.1          link#4             UCS            en0      !

    192.168.1.99/32    link#4             UCS            en0      !

    192.168.1.99       0:ff:b2:6b:4a:37   UHLWIir        en0   1196

    192.168.1.111/32   link#4             UCS            en0      !

    192.168.1.112      78:80:38:9a:8e:c1  UHLWIi         en0   1180

    192.168.1.113      4:ed:33:7:4:31     UHLWI          en0   1184

    192.168.1.255      ff:ff:ff:ff:ff:ff  UHLWbI         en0      !

    20x.xxx.112.52      link#13            UHW3I         ppp0   2352

    20x.xxx.112.53      link#13            UHW3I         ppp0   2349

    2xxx.xxx.200.2      192.168.1.99       UGHS           en0       

    224.0.0/4          link#4             UmCS           en0      !

    224.0.0/4          link#13            UmCSI         ppp0       

    224.0.0.251        1:0:5e:0:0:fb      UHmLWI         en0       

    239.255.255.250    1:0:5e:7f:ff:fa    UHmLWI         en0       

    239.255.255.250    link#13            UHmW3I        ppp0   2348

    255.255.255.255/32 link#4             UCS            en0      !

    255.255.255.255/32 link#13            UCSI      

     

    And it can reach it's local resources ( printers and other devices on lan )

    examples

     

    64 bytes from 192.168.1.112: icmp_seq=0 ttl=64 time=80.532 ms64 bytes from 192.168.1.113: icmp_seq=0 ttl=128 time=4.465 ms64 bytes from 192.168.1.99: icmp_seq=0 ttl=255 time=2.331 ms Again your problem is not fortios it's your OS and your vpn-adapter.BTW my windows10 does the same thing.  

     

     

    =========================================================================== Interface List 11...00 50 b6 a8 e1 29 ......Intel(R) I210 Gigabit Network Connection 46...........................l2tp 17...04 ed 33 07 04 32 ......Microsoft Wi-Fi Direct Virtual Adapter 3...06 ed 33 07 04 31 ......Microsoft Wi-Fi Direct Virtual Adapter #2 9...04 ed 33 07 04 31 ......Intel(R) Wireless-AC 9560 160MHz 23...04 ed 33 07 04 35 ......Bluetooth Device (Personal Area Network) 1...........................Software Loopback Interface 1 ===========================================================================

    IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.1.99 192.168.1.113 4260 0.0.0.0 0.0.0.0 On-link 10.19.19.2 26 10.19.19.2 255.255.255.255 On-link 10.19.19.2 281 127.0.0.0 255.0.0.0 On-link 127.0.0.1 4556 127.0.0.1 255.255.255.255 On-link 127.0.0.1 4556 127.255.255.255 255.255.255.255 On-link 127.0.0.1 4556 192.168.1.0 255.255.255.0 On-link 192.168.1.113 4516 192.168.1.113 255.255.255.255 On-link 192.168.1.113 4516 192.168.1.255 255.255.255.255 On-link 192.168.1.113 4516 xxxxx200.2 255.255.255.255 192.168.1.99 192.168.1.113 4261 224.0.0.0 240.0.0.0 On-link 127.0.0.1 4556 224.0.0.0 240.0.0.0 On-link 192.168.1.113 4516 224.0.0.0 240.0.0.0 On-link 10.19.19.2 26 255.255.255.255 255.255.255.255 On-link 127.0.0.1 4556 255.255.255.255 255.255.255.255 On-link 192.168.1.113 4516 255.255.255.255 255.255.255.255 On-link 10.19.19.2 281 =========================================================================== Persistent Routes:

    Ken Felix

     

    levicki
    levickiAuthor
    New Member
    March 1, 2021

    By checking IKE logs I have discovered that NATOA-i reported by the client (local LAN address) gets replaced not by L2TP assigned remote client IP address but with client's public IP address.

     

    This means that not only is client's public IP inaccessilbe from the network behind Fortigate, it also means you cannot connect from two different devices (say phone and home PC) behind the same public IP to the Fortigate.

     

    Actually you can connect, but since it cannot add two routes for the same public IP address/mask then when you disconnect either device the tunnel on the other device is also broken because the single route used by both tunnels is removed.

     

    Now I am 100% sure this is a bug.

    Terms & ConditionsAccessibility statement