IPsec VPN Multi VDOM - Remote Access From Windows Native VPN

[Andrew_C]

I am new in FortiGate firewall (60F) and I am trying to create a remote access from Windows native VPN using an IPSec VPN settings on FortiGate. Below are the current settings on 60F.

- 3 VDOM (root, A & B)

- root VDOM has 2 wan interface and has SDWAN setup for failover

- A & B must through root VDOM to have internet access

- Both A & B has VDOM link to connect to root VDOM

How to setup an IPSec VPN remote access on 60C so that users can use Windows native VPN client to remote access servers in VDOM A ? Please assist me on how to get this work, Thanks.

[Andrew_C]

Dear Toshi,

From debug flow console in vdom A, it shows below. I guess ipsec packets can pass through root vdom and reach A but can't return back. Is it correct ? Thanks.

vd-A:0 received a packet(proto=17, 119.237.203.124:1011->10.0.0.2:500) tun_id=0.0.0.0 from root--A1.
allocate a new session-000020fc, tun_id=0.0.0.0
in-[root--A1], out-[]
len=0
result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000
find a route: flag=80000000 gw-10.0.0.2 via A
in-[root--A1], out-[], skb_flags-02000000, vid-0
gnum-100017, check-ffffffbffc02c044
after check: ret-no-match, act-accept, flag-00000000, flag2-00000000
in-[root--A1], out-[], skb_flags-02000000, vid-0
gnum-100011, check-ffffffbffc02d0c0
after check: ret-no-match, act-drop, flag-00000000, flag2-00000000
gnum-100001, check-ffffffbffc02c044
after check: ret-no-match, act-accept, flag-00000000, flag2-00000000
gnum-10000e, check-ffffffbffc02c044
checked gnum-10000e policy-4294967295, ret-no-match, act-accept
checked gnum-10000e policy-4294967295, ret-no-match, act-accept
checked gnum-10000e policy-4294967295, ret-no-match, act-accept
checked gnum-10000e policy-4294967295, ret-matched, act-accept
policy-4294967295 is matched, act-accept
gnum-10000e check result: ret-matched, act-accept, flag-00000000, flag2-00000000
after check: ret-matched, act-accept, flag-00000000, flag2-00000000

vd-A:0 received a packet(proto=17, 10.0.0.2:500->119.237.203.124:1011) tun_id=0.0.0.0 from local.
Find an existing session, id-000020fc, reply direction

vd-A:0 received a packet(proto=17, 119.237.203.124:1011->10.0.0.2:500) tun_id=0.0.0.0 from root--A1.
Find an existing session, id-000020fc, original direction

vd-A:0 received a packet(proto=17, 10.0.0.2:500->119.237.203.124:1011) tun_id=0.0.0.0 from local.
Find an existing session, id-000020fc, reply direction

[Toshi_Esumi]

I think it's normal. The return packet is following the session created by the initial incoming IKE packet.

"vd-A:0 received a packet(proto=17, 10.0.0.2:500->119.237.203.124:1011) tun_id=0.0.0.0 from local.
Find an existing session, id-000020fc, reply direction"

Now you need to run IKE debugging.
https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-IPSEC-Tunnel-debugging-IKE/ta-p/1900...

Toshi

[Andrew_C]

Dear Toshi,

Both P1 & P2 are up but still can't establish the connection. Is something I missed like policy / static route in vdom A and root vdom ? I feel desperate :(

[Toshi_Esumi]

I recommend you open a ticket at TAC. It doesn't seem to be as easy as I thought.

I tried to set up a similar environment with a box I have here (70F). It works fine with the default config (IPSec Wizard) when I set it up at root vdom. But once it's moved to another VDOM then connected through (VIPed) root vdom, Windows side doesn't seem to accept the last quick-mode message the FGT sends to it. And it keeps trying again and again until times out. Maybe because the IP (SA) terminating the IPSec is different from the IP the client is trying to connect to.

Toshi