Skip to main content
JoSy
New Member
July 24, 2018
Solved

IPSEC tunnel traffic issue

  • July 24, 2018
  • 3 replies
  • 4642 views

Situation:

We have a site2multi-site situation. The main site A 10.10.0.x and secundary site B 10.10.16.x .

Printer 10.10.16.230 directly connected to the firewall.

Site2site with IPSEC vpn tunnel

 

Policy:

Site A -> Site B allow any

Site B -> Site A allow any

No antivirus or anything enabled

 

Problem:

When we try to surf to a printer or switch webconfig page from A -> B the browser shows http://10.10.16.230/index.html  but it keeps loading. @Site B we can browse perfectly fine to the webconfig.

 

Noticed:

- Ping works in both ways

- RDP works from B-> A if we disable IPV4-Offload (NIC computer)

- DNS server @site A, so the client computers @siteB can surf without any issue through dns server(A)

- Other sites are not having this issue

- The printer cannot send mail from site B -> Mailserver Site A

 

Already tried:

- Remove ipsec tunnel and created a new one

- rebooted firewall @siteB

- disabled/enabled auto-asic on all policy's (A + B)

 

Does anyone have a clue what this could be? We dont know where to look

    Best answer by Toshi_Esumi

    I took your statement,

    "- Other sites are not having this issue"

    as other sites have similar printers and accessing it from site A doesn't show problems, nor printer's email server access at site A.

    I would verify no MTU issues inbetween A and B by pinging FGT-to-FGT outside the tunnel and inside with more than 1500bytes packets. Then run flow debug as emnoc suggested.

    3 replies

    emnoc
    New Member
    July 24, 2018

    The cl-cmd diag debug flow  is your best friend but it sounds like it's not the firewall. I would ensure the  proper network mask and gateway on the printer.

     

     

    Ken

    Toshi_Esumi
    SuperUser
    SuperUser
    July 24, 2018

    I took your statement,

    "- Other sites are not having this issue"

    as other sites have similar printers and accessing it from site A doesn't show problems, nor printer's email server access at site A.

    I would verify no MTU issues inbetween A and B by pinging FGT-to-FGT outside the tunnel and inside with more than 1500bytes packets. Then run flow debug as emnoc suggested.

    JoSy
    JoSyAuthor
    New Member
    July 26, 2018

    The MTU was the problem! After lowering it, the problem was solved!

    Thought Leadership Security Summit. Outpace New Threats with AI - enhanced defense. Tuesday, Septmeber 15, 8:30 AM - 2:30 PM PT. The Golf Club at Newcastle, WA.
    Fortinet Flag the Hack. Wednesday, August 26, 9:00 AM - 5:00 PM ET, COSM, Atlanta, GA.
    Virtual event | September 2026. SASE summit. The age of autonomous trust. Register here!