HI Folks.
Help...
I am creating a new DMZ using a loopback address on fortigate 6.14.3
I have created a couple of VMs that use the IP range of the new DMZ.
From the firewall I can ping the VMs no problem, However from the VMs I cannot ping the loopback interface which would be their default gateway. Not sure what is going on here. Yes PING is enabled on the FG interface.
next
edit "DMZ2"
set vdom "root"
set ip 192.168.4.1 255.255.255.0
set allowaccess ping
set type loopback
set alias "DMZ2"
set role dmz
set snmp-index 62
I have allowed a policy so I should be able to ping from other networks connected to the fortigate physically but no response.
From the fortigate.
FW1 $ exec ping 192.168.4.11
PING 192.168.4.11 (192.168.4.11): 56 data bytes
64 bytes from 192.168.4.11: icmp_seq=0 ttl=255 time=0.0 ms
64 bytes from 192.168.4.11: icmp_seq=1 ttl=255 time=0.0 ms
64 bytes from 192.168.4.11: icmp_seq=2 ttl=255 time=0.0 ms
64 bytes from 192.168.4.11: icmp_seq=3 ttl=255 time=0.0 ms
64 bytes from 192.168.4.11: icmp_seq=4 ttl=255 time=0.0 ms
--- 192.168.4.11 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
VM networks setup fine.
However no arp entry for the 192.168.4.1 address.
any ideas !!
thanks,
Chris.
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.
Hello Chris,
I hope you are doing well.
As far as i understand you have few VMs connected to your device, to which interface they are connected to ?
What is the IP address and interface config for that interface ?
Please run the debug bellow and generate ICMP from VMs to the DMZ loopback interface :
diagnose debug reset
diagnose debug disable
diagnose debug flow trace stop
diagnose debug flow filter clear
diagnose debug flow show iprope enable
diagnose debug flow show function-name enable
diagnose debug flow filter daddr 192.168.4.1
diagnose debug console timestamp enable
diagnose debug flow trace start 10000
diagnose debug enable
Best regards,
Fortinet
Hiya,
Got the below readout.
To stop the diags I enter, "diagnose debug reset" ?
FW1 $ 2024-02-22 09:25:15 id=20085 trace_id=1 func=print_pkt_detail line=5822 msg="vd-root:0 received a packet(proto=17, 192.168.253.37:15423->192.168.4.1:5246) from port36. "
2024-02-22 09:25:15 id=20085 trace_id=1 func=init_ip_session_common line=5993 msg="allocate a new session-4b26d923"
2024-02-22 09:25:15 id=20085 trace_id=1 func=iprope_dnat_check line=5121 msg="in-[port36], out-[]"
2024-02-22 09:25:15 id=20085 trace_id=1 func=iprope_dnat_tree_check line=823 msg="len=0"
2024-02-22 09:25:15 id=20085 trace_id=1 func=iprope_dnat_check line=5134 msg="result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000"
2024-02-22 09:25:15 id=20085 trace_id=1 func=ip_route_input_slow line=2264 msg="reverse path check fail, drop"
2024-02-22 09:25:15 id=20085 trace_id=1 func=ip_session_handle_no_dst line=6077 msg="trace"
I guess the "reverse path check fail" is a problem ?
many thanks,
Chris.
Hi @ChrisM,
Yes, "reverse path check fail, drop" means traffic is dropped by Anti Spoofing. Make sure you have a route back to 192.168.253.37 via port36.
Regards,
Is the symptom still the same if you change it like below?
set ip 192.168.4.1 255.255.255.255
or
set ip 192.168.5.1 255.255.255.0
Toshi
A loopback interface cannot be a gateway to another interface's (let's say portX) subnet. ARP packets aren't routed across interfaces, so the portX clients won't be able to resolve it with ARP.
Hi @pminarik
Your colleague thinks it may be a case of inserting a route. Although I am inclinded to agree with you. Should I just use the new vlan option to create a new DMZ ?
I wouldn't use a loopback to eventually connect to actual devices. Because it requires two sets of policies, 1) get to the loopback interface from outisde, and 2) VIP/forward to devices/servers from the loopback.
If you just add a vlan on the existing DMZ interface then split them at the switch, you just need to have single set of policies and then that would be a regular/efficient way to have two DMZ interfaces/networks.
Toshi
To be frank, I am not too sure what the goal of the DMZ loopback is/was.
Can you give us a rough outline, ideally with a diagram/sketch, of what your design goal is?
If this is a simple case of "a new DMZ segment", then any interface, physical or virtual (VLAN), will suffice, as long as you properly configure policies in/out for it.
Hi Pminarik,
I am trying to create a new DMZ, preferably separate from our current one.
Since the systems within the new DMZ are going to be in a Virtual enviroment there is no need for a physical port. It will just use the trunk port back to the core switch and from there to the VM enviroment.
However I did want to use the Firewall as the link from the new DMZ to the rest of the network (rather than use ACL on the core switch and create a separate VLANs there).
Hope that makes reasonible sense.
regards,
Chris.
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 |
---|---|
1548 | |
1032 | |
749 | |
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.