New Member

Solved

FG 30E not passing traffic that is masquerade'd on linux box.

Forum|Forum|3 years ago
November 2, 2022
4 replies
2410 views

Hi,

I got a Linux box setup on a DMZ with the IP 192.168.30.2 connected to my FG 30E DMZ port. The Linux box is setup with iptables to forward all traffic from eth0 to wlan0 using these parameters:

# Forward LAN packets to the WAN.
iptables -A FORWARD -i eth0 -o wlan0 -j ACCEPT# Forward WAN packets to the LAN if the LAN initiated the connection.
iptables -A FORWARD -i wlan0 -o eth0 -m conntrack \
 — ctstate ESTABLISHED,RELATED -j ACCEPT# NAT traffic going out the WAN interface.
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

From my PC on the LAN I can ping the DMZ Linux box. ( Ive got a rule on the FG30E allowing everything between LAN and DMZ and back again).

From my PC I cant ping the "other device" (192.168.4.1) which is on the other subnet (192.168.4.0/24) which the Linux box is forwarding all traffic to.

Linux box can ping the "other device" (192.168.4.1) no problems.

FG20E console can also ping 192.168.4.1

I have a static route setup in the FG30E:

Any ideas why I can reach 192.168.4.1 from my PC? Does it have something to do with the way the traffic is forwarded on my Linux box the the 191.16.4.0/24 subnet?

Thanks,

FortiGate

Best answer by Gypsy_Dave

Right found the fault guys. I needed to add the 192.168.4.0/24 subnet to the ID 7. I had it on the other end but not this one. All working. Many thanks for your help everyone!!

damianhlozano

Explorer II

Hello!!

I dont know anything about linux boxes, but it seems to me, this is a problem with the linux box, not with the fortigate unit.

You could try to run a traceroute in your computer to know which is the path.

Also you could take a debug in fortigate while your PC is running a ping to 192.168.4.1:

diagnose debug flow filter clear
diagnose debug flow filter proto 1
diagnose debug flow filter addr YourPcAddress
diagnose debug flow filter addr 192.168.4.1
diagnose debug enable
diagnose debug flow trace start 3

Regards,

Damián

Gypsy_DaveAuthor

New Member

Thanks Damian,

I see its the implicit deny policy 0 which is blocking it. hmmmm

FG-HOME # id=20085 trace_id=1 func=print_pkt_detail line=5607 msg="vd-root:0 received a packet(proto=1, 192.168.1.8:42772->192.168.4.1:2048) from lan. type=8, code=0, id=42772, seq=0."

id=20085 trace_id=1 func=init_ip_session_common line=5777 msg="allocate a new session-04113c98"

id=20085 trace_id=1 func=vf_ip_route_input_common line=2595 msg="find a route: flag=04000000 gw-192.168.30.2 via lan2"

id=20085 trace_id=1 func=fw_forward_handler line=630 msg="Denied by forward policy check (policy 0)"

So I have these IPv4 policies set for the DMZ to LAN and Visaversa:

I see the implicit deny policy cant be edited by the GUI? In Rule ID 13 I'm allowing everything from the 192.168.30.0/24 subnet to the lan so it should get through right?

Gypsy_DaveAuthorAnswer

New Member

Right found the fault guys. I needed to add the 192.168.4.0/24 subnet to the ID 7. I had it on the other end but not this one. All working. Many thanks for your help everyone!!

gfleming

Staff

Also you could try a tcpdump (filter for ICMP and the src/dst hosts) on the linux box when pinging from your PC on the LAN to the 192.168.4.0/24 subnet. Do you see the pings coming back from the 192.168.4.0 network?

Can you also show your FW Policy for the LAN-DMZ traffic?

From what you've said it seems like it should work. Problem is likely on linux box. Perhaps SNAT isn't working properly and return traffic is trying to reach LAN PC directly resulting in failed state lookup.

Sign up

Login with SSO

Login to the community

Login with SSO