Not able to pass traffic on 100D v5.2

[seadave]

I have upgraded a 100D to 5.2 Everything seems to be working from a configuration standpoint, but I am not able to pass traffic. I have a general NAT rule setup without any filtering from LAN to WAN1. ALL source and ALL Services allowed. Just doing this to determine the issue. I have a host on the same subnet as the LAN interface. I can ping the LAN and WAN1. Fortinet can ping the internal (via LAN) host and Internet (via WAN1) hosts such as www.yahoo.com. I cannot get DNS or straight ICMP to work from the host through the firewall to an Internet host. Any ideas?

[Warren_Olson_FTNT]

Make sure you' ve setup a default route on the FortiGate.

[seadave]

Have done that, but thanks.

[emnoc]

diag debug flow is your friend. It should be your 1st step in troubleshooting. Search here for numnerous examples.

[seadave]

Will test this and see what I can see.

[emnoc]

If you have done the diag debug flow than you won' t have to guess and the output would tell you want the problem(s)

[Dave_Hall]

Just taking a guess (based on description of problem), recheck your address labels (e.g. ALL source really means 0.0.0.0/0.0.0.0, etc., make sure the subnet masks are correct), verify any static routing or route policies. Personal experience with upgrading between major releases (mostly going from 4.0 MR1/MR2 to later firmware) is firewall object/address labels tend to get messed up, especially if you have space or non-standard chars in the names. If you have both before/after upgrade config files, I suggest putting them through a text comparison tool just to see what has changed in the config. (The firmware patch notes does lists some " Gotchas" you need to be aware of after upgrading to 5.2)

[Sean_Toomey_FTNT]

Hi dfollis, Sorry to hear about your issue. To best address your concern please open a case with TAC. Please include: system config backup diag debug report / exe tac report traffic capture diag debug flow to do the diag debug flow please do the following: diag debug reset diag debug ena diag debug flow sh fun ena diag debug flow sh con ena diag debug flow filter <filter> diag debug flow trace start <count> (should see data here) diag debug flow trace stop diag debug dis diag debug reset I am confident they will get you working once we have the full picture of what the issue is. Right now there is not enough information to provide any meaningful help here, sorry I couldn' t do more. Hope this helps. Cheers!

[seadave]

Thanks for the great info. I had some trouble figuring out the diag debug flow filter command, but finally settled on: diag debug flow filter saddr 4.2.2.2 (I was running a test ping from a client) Showed this: id=20085 trace_id=10 func=resolve_ip_tuple_fast line=4310 msg=" vd-root received a packet(proto=1, x.x.x.x:512->4.2.2.2:8) from lan." id=20085 trace_id=10 func=init_ip_session_common line=4438 msg=" allocate a new session-00cad41e" id=20085 trace_id=10 func=vf_ip4_route_input line=1599 msg=" find a route: gw-4.2.2.2 via ssl.root" id=20085 trace_id=10 func=__iprope_tree_check line=534 msg=" use addr/intf hash, len=1" id=20085 trace_id=10 func=fw_forward_handler line=549 msg=" Denied by forward policy check" I' m thinking gw-4.2.2.2 via ssl.root??? So I looked and there was a route of last resort via ssl.root in addition to the proper one I created. I think the SSL Wizard created that, not sure. Anyway once I removed the SSL.ROOT via 0.0.0.0 route, things started working. Thanks everyone.