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

DMZ using loopback.

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.

 
 

 

11 REPLIES 11
syordanov
Staff
Staff

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

.
ChrisM
New Contributor II

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.

hbac

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, 

Toshi_Esumi
SuperUser
SuperUser

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

pminarik
Staff
Staff

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.

[ corrections always welcome ]
ChrisM
New Contributor II

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 ?

 

 


 

 

Toshi_Esumi

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

pminarik

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.

[ corrections always welcome ]
ChrisM
New Contributor II

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.

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors