[SOLVED] IPsec L2TP VPN routing broken

[levicki]

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?

[emnoc]

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]

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]

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 inetRouting tables Internet:Destination        Gateway            Flags        Netif Expiredefault            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   1196192.168.1.111/32   link#4             UCS            en0      !192.168.1.112      78:80:38:9a:8e:c1  UHLWIi         en0   1180192.168.1.113      4:ed:33:7:4:31     UHLWI          en0   1184192.168.1.255      ff:ff:ff:ff:ff:ff  UHLWbI         en0      !20x.xxx.112.52      link#13            UHW3I         ppp0   235220x.xxx.112.53      link#13            UHW3I         ppp0   23492xxx.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   2348255.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]

Ken,

The problem is not wih the VPN client and its own routing, but with the Fortigate L2TP VPN server.

I have attached a diagram, real IP addresses have been replaced with examples.

1. Home server has a service port-forwarded to home public IP 1.1.1.1:8443.

2. Home PC establishes a VPN connection using Windows 10 built-in client to Fortigate FG-60F at public IP 2.2.2.2.

3. Home PC can access all work LAN resources and it can access internet through the local gateway (Use default gateway on remote network is unchecked in VPN connection settings).

4. When home PC connects to the Fortigate, a static route is added on the Fortigate itself which says "1.1.1.1/32 via 1.1.1.1 [15/0] on OFFICE_VPN".

5. When work laptop attempts to connect to 1.1.1.1:8443 the packets are sent into the existing VPN tunnel because of the route and forward policy rightfully drops the packets since they are not part of interesting traffic for that VPN tunnel.

Let me also show you the relevant part of the IKE log:

...
ike 0:OFFICE_VPN_0:4323:2227: received NATOA-i 192.168.0.4
ike 0:OFFICE_VPN_0:4323:2227: received NATOA-r 2.2.2.2
...
ike 0:OFFICE_VPN_0:4323:2227: sending NATOA-i 1.1.1.1
ike 0:OFFICE_VPN_0:4323:2227: sending NATOA-r 2.2.2.2
...
ike 0:OFFICE_VPN:2227: add route 1.1.1.1/255.255.255.255 gw 1.1.1.1 oif OFFICE_VPN(24) metric 15 priority 0
...

Let's say that my home PC gets an IP address 10.0.0.192 from Fortigate L2TP server when it connects to the VPN.

Shouldn't the IKE log then read:

ike 0:OFFICE_VPN_0:4323:2227: sending NATOA-i 10.0.0.192

...

ike 0:OFFICE_VPN:2227: add route 10.0.0.192/255.255.255.255 gw 1.1.1.1 oif OFFICE_VPN(24) metric 15 priority 0

That would mean that traffic to/from 10.0.0.192/32 and 172.16.0.0/24 would flow through the tunnel and the traffic for 1.1.1.1/32 would go through 0.0.0.0/0 via wan interface.

IMO, this behavior is broken, plain and simple.

But wait, there is more.

Current implementation with public IP in NATOA-i field means that only one device from behind the same public IP can connect to Fortigate. Lete's add a phone (say an iPhone on 192.168.0.10) to my home network in that diagram.

When the phone connects to VPN, Fortigate will attempt to create another route entry for 1.1.1.1/32 and fail. Connection will still be established and both home PC and phone will be able to send and receive data. However, since there is only one route entry on the Fortigate for both devices, the first one that disconnects will kill the connection for both because that single route entry will be deleted.

So no, that's definitely not how any of this should work.

[levicki]

If anyone else comes looking for a solution to this problem, the solution is as follows:

Do not use route-based VPN but instead use policy based VPN configuration.

That means you should not create VPN tunnel using:

config vpn ipsec phase1-interface

config vpn ipsec phase2-interface

But instead just:

config vpn ipsec phase1

config vpn ipsec phase2

Instead of needing two firewall rules for inbound and outbound traffic you will also have to create just one.

It took me a few days of back and forth with Fortinet support to figure this out. I'd also like to point out that before even attempting to configure VPN I did read a detailed comparison of route-based .vs. policy based VPN config in the FortiOS documentation, but this important difference (i.e. the inability to access public IP of the VPN client when using route-based config) was not documented anywhere.

[levicki]

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.