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

[TheChosenOne]

Hi Forum,

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

My Setup:

172.16.10.11/32 Customer sNAT. All traffic from my customer has this source.

192.168.110.0/24 Loopback Interface as VPN NAT-Network

192.168.55.0/24 VLAN-Interface for internal Services

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

My first try was a VIP with Portforwarding like this: 192.168.110.3:53(UDP) => 192.168.55.2:53(UDP)

Of cause I added a policy for this:

source interface: IPsec Customer

destination interface: Internal Services

source: 172.16.10.11

destination: VIP 192.168.110.3

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!

[Iescudero]

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

Thanks!

[TheChosenOne]

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 (192.168.184.0/21) that comes trough a VPN to the Fortigate.

My test setup

VIP's:

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

Firewall:

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, 192.168.185.207:42465->192.168.110.3:53) 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-192.168.55.2:53, outdev-unkown" 2018-06-25 09:24:18 id=20085 trace_id=5 func=__ip_session_run_tuple line=3240 msg="DNAT 192.168.110.3:53->192.168.55.2:53" 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-192.168.55.2 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

[emnoc]

I bold this { msg="VIP-192.168.55.2:53, 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   }?

[TheChosenOne]

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

[TheChosenOne]

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 192.168.110.0/24

C 192.168.110.0/24 is directly connected, VPN-Loopback                               is directly connected, VPN-Loopback                               is directly connected, VPN-Loopback

Could this be a reason for my problem?

Thanks!

[rwpatterson]

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

[TheChosenOne]

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.

[rwpatterson]

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

[TheChosenOne]

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.

Thanks!