Skip to main content
jtfinley
jtfinley
New Member
November 28, 2012
Question

Akamai sites fail in browser, can ping

  • November 28, 2012
  • 7 replies
  • 12881 views
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" .

    7 replies

    Dave_Hall
    Dave_Hall
    New Member
    November 28, 2012
    What' s the MTU value set on the two WAN ports? Any UTM policies (Web Profile/URL filter/App Control) applied to the internal Interface ->WAN(S) that could be blocking akamai related sites?
    jtfinley
    jtfinleyAuthor
    New Member
    November 28, 2012
    What' s the MTU value set on the two WAN ports? Any UTM policies (Web Profile/URL filter/App Control) applied to the internal Interface ->WAN(S) that could be blocking akamai related sites?
    No UTM policies are applied. UTM is unchecked. There' s only two FW policies, one for each WAN. MTU Size on both WAN' s are set to 1492. First thought of that issue...no difference.
    emnoc
    emnoc
    New Member
    November 28, 2012
    My thoughts are MTU issues also but why only with Akamai? So what I would do, have you tested with only one WAN connection ? What does your packet captures shows and mainly with advertsied mss ( in the SYN and SYN/ACK _) packets and do you see any reset? Also can you explain the following;
    PW Policies work (NAT) (internal->WAN1) (internal -> WAN2)
    Are you routing out both links , load balancing, or using PBR ,etc....... And finally, what model of FGT and code?
    jtfinley
    jtfinleyAuthor
    New Member
    November 28, 2012
    Hello.... Internal -> Wan1 & 2 I am working on getting another PC connected to verify. MTU was also my thought, but when the customer listed websites he couldn' t visit....I started noticing a pattern. Tried various DNS providers, Google, Open, ISP. Same result. Routing is equal cost; shut down each interface to test each link...
    Federico_Vecchiatti
    Federico_Vecchiatti
    New Member
    November 28, 2012
    Hi, can you confirm your firmware version ? After an upgrade to 4MR3 Patch 11 I' m experiencing a similar issue. Some users complain that with IE Explorer they cannot reach some URL. Same url are accessible with Firefox. Also, with IE Explorer some customer are not able to connect to SSL VPN Portal. We connect to the internet with a SDH fiber, carrier confirm the line is ok. Since the issue is not always present, I suspect something related to " session" or other dynamic configuration (ARP, MTU, etc). I' ve noticed the same behaviour with the SYN, ACK traffic. I' m monitoring the situation and evaluating if a downgrade is the solution (I' ve one of the HA node offline still with the old relase).
    jtfinley
    jtfinleyAuthor
    New Member
    November 28, 2012
    I was on MR3p10 and upgraded to mR3p11.....
    emnoc
    emnoc
    New Member
    November 30, 2012
    I was going to say your address is blacklisted, but if they used the same ip_address in the test, than that' s not the problem. So did you do; 1: get pcap of the connection 2: diag debug flow
    jtfinley
    jtfinleyAuthor
    New Member
    December 1, 2012
    Working from 10 hrs away of that location. Ill run a tracer...all indications show the syn, no ack coming back . As if a bad route.
    emnoc
    emnoc
    New Member
    December 1, 2012
    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
    jtfinleyAuthor
    New Member
    December 1, 2012
    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
    rwpatterson
    New Member
    December 2, 2012
    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.
    emnoc
    emnoc
    New Member
    December 4, 2012
    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
    jtfinleyAuthor
    New Member
    December 4, 2012
    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
    rwpatterson
    rwpatterson
    New Member
    December 4, 2012
    ORIGINAL: jtfinley ...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
    What a surprise.
    Dave_Hall
    Dave_Hall
    New Member
    December 11, 2012
    I' m thinking it could still be a MTU-related issue, not with the local ISP but somewhere on the Akamai network. Maybe the MTU value is something like 1452. Alternately (as outlined in Fortinet kb#11731) setting the tcp-mss-sender option in the firewall policy may resolve the browsing issue. Keep in mind that Akamai hosted sites are mirrored around the world, which is geographically determined via DNS. It could be a problem with the local mirror or route to the local mirror (23.60.74.100 for www.uline.com). Using various DNS servers, I was able to find other mirrors at 184.51.146.100, 173.222.186.100, 95.101.46.100.
    Terms & ConditionsAccessibility statement