Akamai sites fail in browser, can ping

[jtfinley]

I have a strange issue. New customer with (2) DSL connections on WAN1 & WAN2. WAN 1 = /28 block of IP' s WAN 2 = /29 block of IP' s All websites function fine, however, any site that' s hosted on Akamai web site just spins. pb.com, staples.com, officemax.com, microsoft.com Customer made us aware as this is a new installation. Remote control of a PC at the location shows this, however when running a packet sniff, many trans-it exceeded errors during trace routes from the PC. PW Policies work (NAT) (internal->WAN1) (internal -> WAN2) Routes are EQLB Pings & Trace-routes to said sites reply and finish.... Called ISP asking if they were experiencing peering issues.... Perplexed..... customer thinks it' s the firewall since its " new" .

[emnoc]

So if it was bad route, would it not exist when the 2 tech came out and tested from their dslmodem? I highly doubt it' s a bad route btw. If your not getting the SYN-ACK back, it might be that some mitigation gear/process is blocking your initial SYN request.

[jtfinley]

I am only speculating about routing. ...if the ISP was doing something on their end in regards to the 2 dsl modems. I may get some time tonight to remote into a machine there.

[rwpatterson]

This may be more deep in FGT world than meets the eye. When using 2 WAN links from 2 ISPs, try using 2 separate DNS servers. I had an installation with dual WANs where one was Verizon and the second was Cablevision. When using the Verizon DNS servers, the WAN traffic going through the Cablevision link wouldn' t flow due to VZ DNS. And the opposite held with the CV traffic and VZ DNS. I switched to third party DNS and all worked as designed. (4.2.2.1, etc...) Also when using 2 WAN links, the FGT ' load balances' by sending odd IP addresses out WAN 1 and even IP addresses out WAN2. Not quite 100% accurate as far as traffic flow, but that' s what you seem to get. What I did was to put WAN1 and WAN2 in a zone called Internet, and just set up one instance of outgoing policies. This way, I couldn' t care less which link was up or down or what the source IP was. It just flowed. Not sure if the load was balanced evenly because I was using fail over mode.

[jtfinley]

The dual link is same ISP. When I shipped the Fortigare wifi60c, I placed both wans in a zone called Internet exactly as you describe. When we were notified of the issue, I removed the zone. UPDATED info....Packet Tracer: From a PC connected behind the Fortigate. Using Chrome or any browser, www.uline.com ; output below. FWF60C3G11011929 # diagnose debug flow filter saddr 10.212.161.77 FWF60C3G11011929 # diagnose debug flow filter dport 80 FWF60C3G11011929 # diagnose debug flow show console enable FWF60C3G11011929 # diagnose debug flow trace start 20 FWF60C3G11011929 # id=36870 trace_id=2 msg=" vd-root received a packet(proto=6, 10.212.161.77:4382->23.60.74.100:80) from internal." id=36870 trace_id=2 msg=" Find an existing session, id-00000ad6, original direction" id=36870 trace_id=2 msg=" SNAT 10.212.161.77->50.122.92.211:24978" id=36870 trace_id=3 msg=" vd-root received a packet(proto=6, 10.212.161.77:4384->23.60.74.100:80) from internal." id=36870 trace_id=3 msg=" allocate a new session-00000af3" id=36870 trace_id=3 msg=" find a route: gw-50.122.92.209 via wan2" id=36870 trace_id=3 msg=" find SNAT: IP-50.122.92.211, port-60844" id=36870 trace_id=3 msg=" Allowed by Policy-2: SNAT" id=36870 trace_id=3 msg=" SNAT 10.212.161.77->50.122.92.211:60844" id=36870 trace_id=4 msg=" vd-root received a packet(proto=6, 10.212.161.77:4384->23.60.74.100:80) from internal." id=36870 trace_id=4 msg=" Find an existing session, id-00000af3, original direction" id=36870 trace_id=4 msg=" SNAT 10.212.161.77->50.122.92.211:60844" id=36870 trace_id=5 msg=" vd-root received a packet(proto=6, 10.212.161.77:4384->23.60.74.100:80) from internal." id=36870 trace_id=5 msg=" Find an existing session, id-00000af3, original direction" id=36870 trace_id=5 msg=" SNAT 10.212.161.77->50.122.92.211:60844" id=36870 trace_id=6 msg=" vd-root received a packet(proto=6, 10.212.161.77:4382->23.60.74.100:80) from internal." id=36870 trace_id=6 msg=" find a route: gw-50.122.92.209 via wan2" FWF60C3G11011929 # diagnose snifferid=36870 trace_id=7 msg=" vd-root received a packet(proto=6, 10.212.161.77:4382->23.60.74.100:80) from internal." id=36870 trace_id=7 msg=" find a route: gw-50.122.92.209 via wan2"

[rwpatterson]

Have you tried creating a wide open policy for a single work station and seeing if that worked?

[jtfinley]

Logged into Fortigate, created (2) policies above Internal:LAN -> WAN1:all & WAN2:All (enable NAT) Internal:PC -> WAN1:All (enable NAT) Internal:PC -> WAN2:All (enable NAT) www.msn.com www.cnn.com ... Browser works. www.staples.com www.pb.com www.officemax.com www.uline.com Browser spins - times out after 10 mins. No difference

[rwpatterson]

...and you' re certain that the unit is using that policy? (It' s at or near the top of the policy list)

[jtfinley]

Certain. There' s only (4) policies including the (2) just added. This is a NEW install. One PC is behind the firewall for testing the ISP DSL connections. They don' t want to switch over until we resolve this situation. I opened a ticket w/ Fortinet - waiting on a response.

[emnoc]

I know what your problem is :) It' s dns related and resolving the link to the CNAME. I bet you a whole dollar that' s the issue and it has nothing to do with the fwpolicy. Can you shed light into what is the client dns-server? Also if you change dns-servers and not use the fortigate or assigned dns-servers via DHCP, does the problem exists? For starters, I would run nslookup in debug or use dig watch the requests and if the recursive is set ( +norecurse ). But the problem is most likely dns and related to your dns-servers for the client.

[jtfinley]

On phone w/ TAC now. Don' t think that' s it... Used different DNS providers (Google & OpenDNS) including ISP, same result. Appears to be Akamai related only. Same result from two different PC' s, different OS behind firewall. TAC is bringing in senior TAC to assist. Working in progress.... ISP went onsite and did the typical....works for us...must be the firewall and left. ---UPDATE--- Had the customer plug a PC directly into the DSL modem w/ configured IP from routable block and showed same symptoms. This means the ISP lied. Sigh