Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
ejvl
New Contributor

Fortigate IPSec tunnels UDP traffic broken

Hi,

We had a problem with IPSEC tunnels.

A main location with a Fortigate 60, Firmware 6.2.5, with a application server in the network. This Fortigate has configured about 20 IPSEC tunnels to other remote locations. Some locations have a Fortigate, some locations have a SonicWall.

Tunnels are all up and running, works fine. Application use UDP traffic with port 1100. Works fine.

But sometimes, the remote application can’t connect to the server anymore and is “disconnected”.

From the server I can ping the remote application, from the remote, I can ping the server, works fine but UDP traffic port 1100 is not possible anymore.

When we disconnect the tunnel and re-connect, no difference, still problems.

The only possibility to let it work again is the following command:

 

diagnose sys session filter dport 1100

diagnose sys session clear

 

Then it works fine again without any problems.

For now, we’ve scheduled this command every couple of hours but I don’t get what is the real problem here.

In the former situation, main location has a SonicWall without any problems, now is the main location a Fortigate and we’ve kill the UDP 1100 traffic to make it work again.

 

I’ve tried to set the Auto-negotiate on or off but no difference.

 

Any idea what I can do?

 

 

8 REPLIES 8
Toshi_Esumi
Esteemed Contributor III

You didn't describe if this problem happens even Hub FGT - Remote FGT combination, not only Hub FGT - Remote SonicWall. But I assume the remote doesn't matter, then you do the clear sessions at the Hub FGT.

What I would do is compare the sessions between when it's working and after it stopped working with "show sys session list" after putting the dport filter in place. There must be some difference since it solves when you clear them.

Toshi_Esumi
Esteemed Contributor III

correction: diag sys session list

zoriax

Hi !

Do you have a solution ?  I have exactly the same problem

ede_pfau
Esteemed Contributor III

To me, it looks like the tunnel expires, and a session is built against the WAN interface (following the default route). To fix this, you would

- enable auto-negotiation in phase1 and phase2

and/or

- install a blackhole route to the remote private network with highest priority (= cost), namely 255.

 

Once the session is established to a different location, it will take 300-600 sec until it times out idling.

You can easily grab the tunnel status when the error occurs, giving you a hint that auto-negotiation is not happening.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
zoriax

Good idea to add auto-negotiation on VPN. I uses FortiManager and I think I can't add dynamic blackhole route.

zoriax

I'm sure you can help me about this behaviour.

 

I don't understand why my FortiGate's session doesn't do a rollback interface we tunnel comes up again. Without blackhole route, the session never restarts (you can try it with a continues ping).

 

So in my example, when the tunnel comes down, my ping goes to default route (ISP). I effectively can seen in session table an interface change (form vpn interface to wan). But why when my tunnel comes up again, my session stay in wan interface ?

 

Thanks for your help

ede_pfau
Esteemed Contributor III

Well, this is expected behavior. A session via an active interface is perfectly valid. If _you_ want to change the interface, the router doesn't have to. Even if the VPN is up again, and the route pointing to it is back in the routing table, this will only be relevant for new sessions. Existing sessions will have to idle out first.

 

That's why it's important or , at least, helpful to install static blackhole routes. I think that in the later FortiOS versions a bh route is created by the VPN wizard.

See my (old) post https://forum.fortinet.com/tm.aspx?m=120834 for a ready-to-use command file to install bh routes for all known private networks. As they carry the highest cost/priority, they will never be followed until only the default route remains. And RFC1918 traffic is never meant to leak into the WAN.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
zoriax

Hi !

 

Nice many thanks for your answer. It's effectively a totally normal behaviour so the BH takes lot of sense :)

 

 

 

 

Labels
Top Kudoed Authors