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

using virtual IP to forward DNS traffic from IPsec VPN to a private subnet

Hi Forum,


i have trouble granting access to my DNS-Server to a customer who is connected via IPsec.


My Setup: Customer sNAT. All traffic from my customer has this source. Loopback Interface as VPN NAT-Network VLAN-Interface for internal Services


We have a working VPN Connection with these Phase2 entrys: <=>


My first try was a VIP with Portforwarding like this: =>


Of cause I added a policy for this:

source interface: IPsec Customer

destination interface: Internal Services


destination: VIP

service: DNS

NAT: disabled


But this doesn't work. Next try was a virtual server. Also not working... Is it "wrong" to use a Transfer-Network on a loopback device?


If you need more information please ask. Thank you and best regards!

Contributor II

Hi there!

Can you do a diag flow and paste the output?


diagnose debug flow show console enable

diagnose debug flow filter dport 53

diagnose debug flow trace start 50

diagnose debug enable

diagnose debug console timestamp enable

diagnose debug sniffer packet any "udp port 53" 4





Hi lescudero,


I can't debug this together with the customer, but i setup something that's quite similar. It seems my Fortigate hasn't the "diagnose debug flow show console enable", but it worked anyway. It turns out I hit the default deny rule. But why? I have allowed traffic to the VIP from my Office-Subnet ( that comes trough a VPN to the Fortigate.


My test setup



edit "VPN-DNS1-UDP" set uuid ead8eb9e-77dc-51e8-93d9-d1bf2eff9354 set extip set extintf "any" set portforward enable set mappedip "" set protocol udp set extport 53 set mappedport 53 next edit "VPN-DNS1-TCP" set uuid 28da868e-7844-51e8-a9e2-0c38fa007772 set extip set extintf "any" set portforward enable set mappedip "" set extport 53 set mappedport 53 next



edit 121 set name "TMP-TEST-RULE" set uuid 490a40a2-7844-51e8-9d90-f015ef002d2a set srcintf "Office" set dstintf "ESX_VM" set srcaddr "OfficeLAN" set dstaddr "VPN-DNS1-TCP" "VPN-DNS1-UDP" set action accept set schedule "always" set service "DNS" next


Debug Output:

trace_id=5 func=print_pkt_detail line=5320 msg="vd-root:0 received a packet(proto=17,> from Office. " 2018-06-25 09:24:18 id=20085 trace_id=5 func=init_ip_session_common line=5480 msg="allocate a new session-02b79113" 2018-06-25 09:24:18 id=20085 trace_id=5 func=fw_pre_route_handler line=182 msg="VIP-, outdev-unkown" 2018-06-25 09:24:18 id=20085 trace_id=5 func=__ip_session_run_tuple line=3240 msg="DNAT>" 2018-06-25 09:24:18 id=20085 trace_id=5 func=vf_ip_route_input_common line=2590 msg="find a route: flag=04000000 gw- via ESX_VM" 2018-06-25 09:24:18 id=20085 trace_id=5 func=fw_forward_handler line=597 msg="Denied by forward policy check (policy 0)"


Thank you so much for your help!

Best regards

Esteemed Contributor III

I bold this { msg="VIP-, outdev-unkown"  }  9 out of 10 times that means the local route is NOT present


( exec a cli cmd )

   get router infor routing all


Do you see any route for { net 192.168.55   }?




New Contributor II

Hi Emnoc, thanks for answering!   Yes there is something in the routing table: C is directly connected, ESX_VM   Thanks!

What I just recognized: The routing table has multiple entry's for the Loopback-Interface I use for the nating, but only the first one has the subnet


C is directly connected, VPN-Loopback                               is directly connected, VPN-Loopback                               is directly connected, VPN-Loopback


Could this be a reason for my problem?


Valued Contributor III

For a test, remove that, or change the IP to a different subnet.

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at:


I have a ticket for this at fortinet and got the answer to chose the "IPsec Customer" Interface as Interface for the VIP instead of any. It works now, but this approach means I need a VIP for every Interface that should access the service. I don't think this is a good solution and I'm waiting for a second answer from fortinet. Hopefully there is another possibility to get this working.

Valued Contributor III

The other issue is that you cannot create a second port forwarding VIP to that same sever on that same port.

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at:


Exact. This will lead to chaos and confusion when managing the firewall. It's not a nice solution. I'm hoping for a better one. And by the way, I'm asking myself if this is expected behavior. I would think "any" is ok. Maybe this should be treated as bug.



Top Kudoed Authors