Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
AlexGera
New Contributor

static route to L2TP client host ip

Hello.
I use Fortigate as L2TP server.

L2TP client from ip 83.Y.Y.75 connects to my FG 87.X.X.35

Everything works, even bgp over l2tp.

But, from fortigate i can't ping client public ip.

The route information shows that the route to the external address goes through a tunnel, but should go through the default route.

How can I fix this?

 

get router info routing-table details 83.Y.Y.75

Routing table for VRF=0
Routing entry for 83.Y.Y.75/32
Known via "static", distance 15, metric 0, best
* via l2tp-icom tunnel 83.Y.Y.75 vrf 0, tun_id

 

for example, a neighboring address that does not connect via l2tp

 

get router info routing-table details 83.Y.Y.74

Routing table for VRF=0
Routing entry for 0.0.0.0/0
  Known via "static", distance 1, metric 0, best
  * vrf 0 87.X.X.33, via wan1

 

 

 

Debug:

diagnose vpn tunnel list name l2tp-icom_0

list ipsec tunnel by names in vd 1
------------------------------------------------------
name=l2tp-icom_0 ver=1 serial=251 87.X.X.35:0->83.Y.Y.75:0 tun_id=83.Y.Y.75 tun_id6=::10.0.2.24 dst_mtu=1500 dpd-link=on weight=1
bound_if=47 lgwy=static/1 tun=intf mode=dial_inst/3 encap=none/74408 options[122a8]=npu rgwy-chg frag-rfc  run_state=0 role=sync-primary accept_traffic=1 overlay_id=0

parent=l2tp-icom index=0
proxyid_num=1 child_num=0 refcnt=6 ilast=0 olast=0 ad=/0
stat: rxp=1751 txp=1533 rxb=392815 txb=487115
dpd: mode=on-idle on=1 idle=60000ms retry=3 count=0 seqno=1
natt: mode=none draft=0 interval=0 remote_port=0
fec: egress=0 ingress=0
proxyid=l2tp-icom proto=17 sa=1 ref=3 serial=1 transport-mode add-route
  src: 17:87.X.X.35-87.X.X.35:1701
  dst: 17:83.Y.Y.75-83.Y.Y.75:0
  SA:  ref=3 options=1a6 type=00 soft=0 mtu=1454 expire=1361/0B replaywin=2048
       seqno=5fe esn=0 replaywin_lastseq=000006d7 qat=0 rekey=0 hash_search_len=1
  life: type=01 bytes=0/0 timeout=1791/1800
  dec: spi=8ada5de8 esp=aes key=24 56759d5c9835dcd18032a8f4cf59b052b16a1f3b089228eb
       ah=sha1 key=20 8d5bfbb791037c0b8513ca5c0c28af6abb95f54a
  enc: spi=0a77e29c esp=aes key=24 082413878920fea3a4ecf3a45cb0bb9c17c15a6279f7155c
       ah=sha1 key=20 c6e67e476d85be86b3fc2746a9450ac9d68f7be1
  dec:pkts/bytes=3502/785630, enc:pkts/bytes=3066/1043459
  npu_flag=00 npu_rgwy=83.Y.Y.75 npu_lgwy=87.X.X.35 npu_selid=249 dec_npuid=0 enc_npuid=0


diagnose vpn ike gateway list name l2tp-icom_0

vd: dc1/1
name: l2tp-icom_0
version: 1
interface: wan1 47
addr: 87.X.X.35:500 -> 83.Y.Y.75:500
tun_id: 83.Y.Y.75/::10.0.2.24
remote_location: 0.0.0.0
network-id: 0
created: 537s ago
peer-id: 83.Y.Y.75
peer-id-auth: no
IKE SA: created 1/1  established 1/1  time 80/80/80 ms
IPsec SA: created 1/1  established 1/1  time 30/30/30 ms

  id/spi: 1830 93045eb2caa4e10a/07c5d9e5f872ba9a
  direction: responder
  status: established 537-537s ago = 80ms
  proposal: 3des-sha1
  key: 9136ecf1a700dc05-0d97fb5604bb887a-933c44ed88c346ba
  lifetime/rekey: 86400/85592
  DPD sent/recv: 00000000/0000058c
  peer-id: 83.Y.Y.75

 


FortiGate Firmware v7.2.8 build1639

 

8 REPLIES 8
dbhavsar
Staff
Staff

Hi @AlexGera ,

- Can you please share following output:
show full router static

DNB
AlexGera

@dbhavsar 

i'm use sdwan for outside access & vdom "dc1"

config router static
    edit 1
        set status enable
        set dst 0.0.0.0 0.0.0.0
        set distance 1
        set comment ''
        set sdwan-zone "sdwan-wan"
        set tag 0
    next
    edit 2
        set status enable
        set dst 10.202.54.0 255.255.255.0
        set distance 10
        set weight 0
        set priority 1
        set device "l2t.dc1"
        set comment "L2TP tunnels"
        set blackhole disable
        set dynamic-gateway disable
        set link-monitor-exempt disable
        set tag 0
        set bfd disable
    next
    edit 3
        set status enable
        set dst 10.0.0.0 255.0.0.0
        set distance 250
        set weight 0
        set priority 1
        set comment ''
        set blackhole enable
        set link-monitor-exempt disable
        set tag 0
        set vrf 0
    next
    edit 4
        set status enable
        set dst 172.16.0.0 255.240.0.0
        set distance 250
        set weight 0
        set priority 1
        set comment ''
        set blackhole enable
        set link-monitor-exempt disable
        set tag 0
        set vrf 0
    next
    edit 5
        set status enable
        set dst 192.168.0.0 255.255.0.0
        set distance 250
        set weight 0
        set priority 1
        set comment ''
        set blackhole enable
        set link-monitor-exempt disable
        set tag 0
        set vrf 0
    next
end

 

PaulRoberts
New Contributor III

I've noticed this as well.  It's definitely incorrect and makes me worry a bit what might happen should someone connect from behind another Fortigate that has a VPN tunnel already, so I'm pretty interested in finding out if there's a solution for this.  I didn't bother to contact support about it because this happens when using the wizard to create tunnels (so it's not like I could have accidentally swapped some addresses around) and I was unable to find any settings to change the behaviour after the fact even using the CLI.

AlexGera

I don't use the wizard.

PaulRoberts
New Contributor III

Well, now you can be even more sure it wasn't something you did that caused the misconfiguration.

hbac
Staff
Staff

Hi @AlexGera

 

Do you see the same route when L2TP tunnel is down? 

 

Regards,

AlexGera
New Contributor

No, when I turn off the tunnel, there is no route, and the ping goes to a remote ip address.

PaulRoberts
New Contributor III

Just to illustrate... pulling the routes from the console with the VPN up, this is what shows up...

(some addresses have been changed to protect the guilty)

 

Fortigate # get router info routing-table details 71.b.c.d

Routing table for VRF=0
Routing entry for 71.b.c.d/32
Known via "static", distance 15, metric 0, best
* via ODVPN tunnel 71.b.c.d vrf 0, tun_id

 

...which is pretty obviously sending the traffic meant for the external remote endpoint into the tunnel, instead of, well, leaving it alone.  The only thing that needs to go into the tunnel would be the traffic meant for the newly-assigned address on the remote end...

 

Fortigate # get router info routing-table details 10.B.C.D

Routing table for VRF=0
Routing entry for 10.B.C.D/24
Known via "static", distance 10, metric 0, best
* directly connected, l2t.root

 

 

Now, that's a little weird because I would have expected it to be pointing at the ODVPN interface, but I can't say that it's wrong.  The first entry directing traffic for the remote ODVPN client endpoint into the ODVPN tunnel is definitely wrong tho'.

...and when the tunnel is not active the route to the 71.b.c.d address just points to the gateways for the various upstream connections like everything else on the internet.

Labels
Top Kudoed Authors