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!
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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!
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
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 }?
PCNSE
NSE
StrongSwan
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!
For a test, remove that, or change the IP to a different subnet.
Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com
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.
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: http://fortigate.camerabob.com
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!
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1645 | |
1070 | |
751 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.