Community discussions

MikroTik App
 
Ramirocuei
just joined
Topic Author
Posts: 12
Joined: Sat Jan 25, 2020 10:08 pm

IPSec issue

Tue Nov 08, 2022 6:08 pm

Hello everyone!

I have established IPsec Xauth tunnel btw Fortigate and Mikrotik Hex (v6.48.6) over an Internet connection.
I haved noticed that there is 4 - 10% packet loss (with default 56 bytes packet size, with bigger packets like 1000bytes, it is even worse) when I ping any host through the tunnel, in any direction.
There's no packet loss outside the tunnel (0% packet loss when i ping remote public IP).
I do not see any cpu issue, its always around 0-3%.

Topology:

Local LAN ---> Mikrotik ---- Internet ---- Fortigate <--- RemoteLAN

My config on mikrotik side:

/ip ipsec peer
add address=201.xxx.xxx.2/32 exchange-mode=aggressive name=mypeer
/ip ipsec profile
set [ find default=yes ] dh-group=modp1024 dpd-interval=disable-dpd enc-algorithm=aes-128 lifetime=8h
/ip ipsec proposal
set [ find default=yes ] enc-algorithms=aes-128-cbc
/ip ipsec identity
add auth-method=pre-shared-key-xauth generate-policy=no mode-config=request-only my-id=key-id:vpn-xxx password=mypass peer=mypeer remote-id=ignore secret=mysecret username=myusername
/ip ipsec policy
add dst-address=192.168.37.5/32 peer=mypeersrc-address=192.168.150.0/24 tunnel=yes
add dst-address=10.0.3.20/32 peer=mypeer src-address=192.168.150.0/24 tunnel=yes
add dst-address=192.168.35.0/24 peer=mypeer src-address=192.168.150.0/24 tunnel=yes

ip firewall filter
0 D ;;; special dummy rule to show fasttrack counters
chain=forward action=passthrough

1 chain=input action=accept src-address=201.XXX.XXX.2 in-interface=ether2 - fibertel log=no log-prefix="" comment="remote ipsec peer"

2 chain=input action=accept protocol=tcp src-address=200.XXX.XXX.100/24 in-interface=ether2 dst-port=8291 log=no log-prefix="" comment="access winbox from internet"

3 chain=input action=accept protocol=tcp src-address=192.168.35.0/24 in-interface=ether2 dst-port=8291 log=no log-prefix="" comment="allow winbox management from remote lan"

4 chain=input action=accept protocol=tcp src-address=192.168.35.0/24 in-interface=ether2 dst-port=22 log=no log-prefix="" comment="allow ssh management from remote lan"

5 chain=forward action=accept src-address-list=vpn-ipsec log=no log-prefix=""

6 chain=forward action=accept dst-address-list=vpn-ipsec log=no log-prefix=""

7 ;;; defconf: accept in ipsec policy
chain=forward action=accept ipsec-policy=in,ipsec

8 ;;; defconf: accept out ipsec policy
chain=forward action=accept ipsec-policy=out,ipsec


Please tell me if i can share with you any test or configuration to solve this issue.

Thank you.
Ramiro.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IPSec issue

Tue Nov 08, 2022 7:47 pm

What does /ip ipsec statistics print show?
 
Ramirocuei
just joined
Topic Author
Posts: 12
Joined: Sat Jan 25, 2020 10:08 pm

Re: IPSec issue

Tue Nov 08, 2022 8:20 pm

What does /ip ipsec statistics print show?
Hello, thank you for your reply. the output is:

in-errors: 0
in-buffer-errors: 0
in-header-errors: 0
in-no-states: 0
in-state-protocol-errors: 0
in-state-mode-errors: 0
in-state-sequence-errors: 15
in-state-expired: 0
in-state-mismatches: 0
in-state-invalid: 2
in-template-mismatches: 0
in-no-policies: 0
in-policy-blocked: 0
in-policy-errors: 0
out-errors: 0
out-bundle-errors: 0
out-bundle-check-errors: 0
out-no-states: 10
out-state-protocol-errors: 17
out-state-mode-errors: 88
out-state-sequence-errors: 0
out-state-expired: 17
out-policy-blocked: 0
out-policy-dead: 0
out-policy-errors: 0

(these counters do not increase while I see lost packets)

Another wierd thing i'm seeing (i'm not sure if it has something to do with the issue or not)

from local LAN (behind mikrotik) I ping remote LAN with df-bit set and the biggest packet that pass is 1438 bytes size
from remote lan (behind fortigate) to local LAN biggest packet that passes is 1384.


[admin@mikrotik] > ping size=1438 10.0.3.20 do-not-fragment src-address=192.168.150.254
SEQ HOST SIZE TTL TIME STATUS
0 10.0.3.20 timeout
1 10.0.3.20 timeout
2 10.0.3.20 timeout
3 10.0.3.20 timeout
4 10.0.3.20 timeout
5 10.0.3.20 timeout
6 10.0.3.20 1438 127 25ms
7 10.0.3.20 1438 127 26ms
8 10.0.3.20 timeout
9 10.0.3.20 timeout
10 10.0.3.20 1438 127 21ms
sent=11 received=3 packet-loss=72% min-rtt=21ms avg-rtt=24ms max-rtt=26ms

[admin@mikrotik] > ping size=1439 10.0.3.20 do-not-fragment src-address=192.168.150.254
SEQ HOST SIZE TTL TIME STATUS
0 packet too large and cannot be fragmented
1 packet too large and cannot be fragmented
2 packet too large and cannot be fragmented
sent=3 received=0 packet-loss=100%


-----------------------------------------

C:\Users\pc01\Downloads>ping -f -l 1384 192.168.150.10 -t

Haciendo ping a 192.168.150.10 con 1384 bytes de datos:
Respuesta desde 192.168.150.10: bytes=1384 tiempo=21ms TTL=61
Respuesta desde 192.168.150.10: bytes=1384 tiempo=31ms TTL=61

Estadísticas de ping para 192.168.150.10:
Paquetes: enviados = 2, recibidos = 2, perdidos = 0
(0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
Mínimo = 21ms, Máximo = 31ms, Media = 26ms
Control-C
^C
C:\Users\pc01\Downloads>ping -f -l 1385 192.168.150.10 -t

Haciendo ping a 192.168.150.10 con 1385 bytes de datos:
Respuesta desde 192.168.30.254: Es necesario fragmentar el paquete pero se especificó DF.
Es necesario fragmentar el paquete pero se especificó DF.

Estadísticas de ping para 192.168.150.10:
Paquetes: enviados = 2, recibidos = 1, perdidos = 1
(50% perdidos),
Control-C
^C
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IPSec issue

Tue Nov 08, 2022 9:02 pm

The packets may get lost on encryption, in transport, and on decryption, in the Mikrotik -> Fortigate direction or in the opposite one.

So if you can prevent any other traffic but the pings from running through the tunnel, you may sniff on the WAN interface while pinging to see whether the ESP packets carrying the ping requests arrive from the Fortigate with the same periodicity like the ping requests, and whether ESP packets in the opposite direction leave with that periodicity.

If you cannot prevent other traffic from being sent, it may help to ping using some size like 700 bytes which is rarely seen in regular traffic (too large for most UDP flows, too small for most TCP flows).

This should tell you whether the loss happens at the Fortigate side or at the Mikrotik side.
 
Ramirocuei
just joined
Topic Author
Posts: 12
Joined: Sat Jan 25, 2020 10:08 pm

Re: IPSec issue

Tue Nov 08, 2022 9:42 pm

The packets may get lost on encryption, in transport, and on decryption, in the Mikrotik -> Fortigate direction or in the opposite one.

So if you can prevent any other traffic but the pings from running through the tunnel, you may sniff on the WAN interface while pinging to see whether the ESP packets carrying the ping requests arrive from the Fortigate with the same periodicity like the ping requests, and whether ESP packets in the opposite direction leave with that periodicity.

If you cannot prevent other traffic from being sent, it may help to ping using some size like 700 bytes which is rarely seen in regular traffic (too large for most UDP flows, too small for most TCP flows).

This should tell you whether the loss happens at the Fortigate side or at the Mikrotik side.
Thank you Sindy, that's a good test. I have just done it and apparently some echo requests are not reaching the fortigate for some reason.. :S
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IPSec issue

Tue Nov 08, 2022 10:20 pm

apparently some echo requests are not reaching the fortigate for some reason..
By sniffing at Mikrotik you can only say whether the encrypted requests leave Mikrotik or not - you cannot see whether they reach Fortigate. So do you see exactly that, no ESP packet being sent by Mikrotik when you send a ping request from Mikrotik's LAN towards Fortigate's one?
 
Ramirocuei
just joined
Topic Author
Posts: 12
Joined: Sat Jan 25, 2020 10:08 pm

Re: IPSec issue

Wed Nov 09, 2022 1:28 am

apparently some echo requests are not reaching the fortigate for some reason..
By sniffing at Mikrotik you can only say whether the encrypted requests leave Mikrotik or not - you cannot see whether they reach Fortigate. So do you see exactly that, no ESP packet being sent by Mikrotik when you send a ping request from Mikrotik's LAN towards Fortigate's one?
I sniffed on mikrotik wan and i see icmp requests entering the tunnel but then I sniffed on fortigate lan port (for some reason i do not see esp traffic on fortigate's wan interface comming from the mikrotik ip address) and i see some icmp requests missing (i can get that looking at sequence numbers). Anyway i will repeat tests tomorrow with more time and get back to you with the results.

Thank you!
Best regards.

Ramiro
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IPSec issue

Wed Nov 09, 2022 9:30 am

I sniffed on mikrotik wan and i see icmp requests entering the tunnel but then I sniffed on fortigate lan port and i see some icmp requests missing (i can get that looking at sequence numbers).
OK, so you can see gaps in ICMP sequence numbers, but that doesn't explain whether the issue is in encryption at Mikrotik side, in transit, or in decryption at Fortigate side. My idea was to see the IPsec transport packets; they have sequence numbers as well but if the payload packet is dropped at source instead of getting encrypted, there will be no gap in ESP sequence numbers.

for some reason i do not see esp traffic on fortigate's wan interface comming from the mikrotik ip address
Is there NAT at either end, or does the configuration force NAT traversal mode to IPsec, i.e. could it be that ESP is sent encapsulated into UDP? But if so, you should not see ESP towards the Fortigate address also at the Mikrotik WAN.


Another point, run /tool sniffer quick ip-protocol=icmp,ipsec-esp at the Mikrotik, i.e. not specifying any interface. That way, you should see the payload traffic (ICMP) and the transport traffic (ESP) in the same file. This won't work with UDP-encapsulated ESP because the specification of port prevents ICMP packets from being sniffed, but you could use ip-address=ip.of.lan.host,ip.of.forti.gate instead.
 
Ramirocuei
just joined
Topic Author
Posts: 12
Joined: Sat Jan 25, 2020 10:08 pm

Re: IPSec issue

Wed Nov 09, 2022 4:44 pm

I sniffed on mikrotik wan and i see icmp requests entering the tunnel but then I sniffed on fortigate lan port and i see some icmp requests missing (i can get that looking at sequence numbers).
OK, so you can see gaps in ICMP sequence numbers, but that doesn't explain whether the issue is in encryption at Mikrotik side, in transit, or in decryption at Fortigate side. My idea was to see the IPsec transport packets; they have sequence numbers as well but if the payload packet is dropped at source instead of getting encrypted, there will be no gap in ESP sequence numbers.

Hello Sindy!
Exactly, at the fortigates LAN I see that some ICMP request do not get there when i ping from mikroitk's LAN.
If i Ping from fortigate's LAN to mikrotik's LAN, I see that in some cases ICMP echo requests arrive but are not replied.

for some reason i do not see esp traffic on fortigate's wan interface comming from the mikrotik ip address
Is there NAT at either end, or does the configuration force NAT traversal mode to IPsec, i.e. could it be that ESP is sent encapsulated into UDP? But if so, you should not see ESP towards the Fortigate address also at the Mikrotik WAN.

It is wierd, I try to sniff on fortigate's port towards internet but i do not see any traffic coming from the mikrotik's public IP. Fortigates wont let me sniff on the vpn-to_mikrotik interface.
There is not NAT, both ipsec terminators havea public IP address, NAT-T option was enabled on both sides, i disabled it but theres no change.


Another point, run /tool sniffer quick ip-protocol=icmp,ipsec-esp at the Mikrotik, i.e. not specifying any interface. That way, you should see the payload traffic (ICMP) and the transport traffic (ESP) in the same file. This won't work with UDP-encapsulated ESP because the specification of port prevents ICMP packets from being sniffed, but you could use ip-address=ip.of.lan.host,ip.of.forti.gate instead.

I did this test while pinging from mikrotik's lan IP to a fortigate's LAn host, and i have this output, i guess the one that has timout is not being encapsulated into ESP by the fortigate (?):


[admin@mikrotik] > ping 10.0.3.20 src-address=192.168.150.254 size=700 count=5
SEQ HOST SIZE TTL TIME STATUS
0 10.0.3.20 700 127 21ms
1 10.0.3.20 700 127 39ms
2 10.0.3.20 700 127 23ms
3 10.0.3.20 timeout
4 10.0.3.20 700 127 21ms
sent=5 received=4 packet-loss=20% min-rtt=21ms avg-rtt=26ms max-rtt=39ms

[admin@mikrotik] > tool sniffer quick ip-protocol=icmp,ipsec-esp
INTERFACE TIME NUM DI SRC-MAC DST-MAC VLAN SRC-ADDRESS
ether2 ... 3.121 1 -> 18:FD:74:38:8E:75 2C:0B:E9:15:74:19 200.XXX.XXX.16
ether2 ... 3.142 2 <- 2C:0B:E9:15:74:19 18:FD:74:38:8E:75 201.XXX.XXX.2
ether2 ... 3.143 3 <- 2C:0B:E9:15:74:19 18:FD:74:38:8E:75 10.0.3.20
ether2 ... 4.126 4 -> 18:FD:74:38:8E:75 2C:0B:E9:15:74:19 200.XXX.XXX.16
ether2 ... 4.165 5 <- 2C:0B:E9:15:74:19 18:FD:74:38:8E:75 201.XXX.XXX.2
ether2 ... 4.165 6 <- 2C:0B:E9:15:74:19 18:FD:74:38:8E:75 10.0.3.20
ether2 ... 5.12 7 -> 18:FD:74:38:8E:75 2C:0B:E9:15:74:19 200.XXX.XXX.16
ether2 ... 5.144 8 <- 2C:0B:E9:15:74:19 18:FD:74:38:8E:75 201.XXX.XXX.2
ether2 ... 5.144 9 <- 2C:0B:E9:15:74:19 18:FD:74:38:8E:75 10.0.3.20
ether2 ... 6.127 10 -> 18:FD:74:38:8E:75 2C:0B:E9:15:74:19 200.XXX.XXX.16
ether2 ... 7.129 11 -> 18:FD:74:38:8E:75 2C:0B:E9:15:74:19 200.XXX.XXX.16
ether2 ... 7.151 12 <- 2C:0B:E9:15:74:19 18:FD:74:38:8E:75 201.XXX.XXX.2
ether2 ... 7.151 13 <- 2C:0B:E9:15:74:19 18:FD:74:38:8E:75 10.0.3.20

Thank you again for you help.
Ramiro.
 
Ramirocuei
just joined
Topic Author
Posts: 12
Joined: Sat Jan 25, 2020 10:08 pm

Re: IPSec issue

Wed Nov 09, 2022 7:14 pm



OK, so you can see gaps in ICMP sequence numbers, but that doesn't explain whether the issue is in encryption at Mikrotik side, in transit, or in decryption at Fortigate side. My idea was to see the IPsec transport packets; they have sequence numbers as well but if the payload packet is dropped at source instead of getting encrypted, there will be no gap in ESP sequence numbers.

Hello Sindy!
Exactly, at the fortigates LAN I see that some ICMP request do not get there when i ping from mikroitk's LAN.
If i Ping from fortigate's LAN to mikrotik's LAN, I see that in some cases ICMP echo requests arrive but are not replied.




Is there NAT at either end, or does the configuration force NAT traversal mode to IPsec, i.e. could it be that ESP is sent encapsulated into UDP? But if so, you should not see ESP towards the Fortigate address also at the Mikrotik WAN.

It is wierd, I try to sniff on fortigate's port towards internet but i do not see any traffic coming from the mikrotik's public IP. Fortigates wont let me sniff on the vpn-to_mikrotik interface.
There is not NAT, both ipsec terminators havea public IP address, NAT-T option was enabled on both sides, i disabled it but theres no change.


Another point, run /tool sniffer quick ip-protocol=icmp,ipsec-esp at the Mikrotik, i.e. not specifying any interface. That way, you should see the payload traffic (ICMP) and the transport traffic (ESP) in the same file. This won't work with UDP-encapsulated ESP because the specification of port prevents ICMP packets from being sniffed, but you could use ip-address=ip.of.lan.host,ip.of.forti.gate instead.

I did this test while pinging from mikrotik's lan IP to a fortigate's LAn host, and i have this output, i guess the one that has timout is not being encapsulated into ESP by the fortigate (?):


[admin@mikrotik] > ping 10.0.3.20 src-address=192.168.150.254 size=700 count=5
SEQ HOST SIZE TTL TIME STATUS
0 10.0.3.20 700 127 21ms
1 10.0.3.20 700 127 39ms
2 10.0.3.20 700 127 23ms
3 10.0.3.20 timeout
4 10.0.3.20 700 127 21ms
sent=5 received=4 packet-loss=20% min-rtt=21ms avg-rtt=26ms max-rtt=39ms

[admin@mikrotik] > tool sniffer quick ip-protocol=icmp,ipsec-esp
INTERFACE TIME NUM DI SRC-MAC DST-MAC VLAN SRC-ADDRESS
ether2 ... 3.121 1 -> 18:FD:74:38:8E:75 2C:0B:E9:15:74:19 200.XXX.XXX.16
ether2 ... 3.142 2 <- 2C:0B:E9:15:74:19 18:FD:74:38:8E:75 201.XXX.XXX.2
ether2 ... 3.143 3 <- 2C:0B:E9:15:74:19 18:FD:74:38:8E:75 10.0.3.20
ether2 ... 4.126 4 -> 18:FD:74:38:8E:75 2C:0B:E9:15:74:19 200.XXX.XXX.16
ether2 ... 4.165 5 <- 2C:0B:E9:15:74:19 18:FD:74:38:8E:75 201.XXX.XXX.2
ether2 ... 4.165 6 <- 2C:0B:E9:15:74:19 18:FD:74:38:8E:75 10.0.3.20
ether2 ... 5.12 7 -> 18:FD:74:38:8E:75 2C:0B:E9:15:74:19 200.XXX.XXX.16
ether2 ... 5.144 8 <- 2C:0B:E9:15:74:19 18:FD:74:38:8E:75 201.XXX.XXX.2
ether2 ... 5.144 9 <- 2C:0B:E9:15:74:19 18:FD:74:38:8E:75 10.0.3.20
ether2 ... 6.127 10 -> 18:FD:74:38:8E:75 2C:0B:E9:15:74:19 200.XXX.XXX.16
ether2 ... 7.129 11 -> 18:FD:74:38:8E:75 2C:0B:E9:15:74:19 200.XXX.XXX.16
ether2 ... 7.151 12 <- 2C:0B:E9:15:74:19 18:FD:74:38:8E:75 201.XXX.XXX.2
ether2 ... 7.151 13 <- 2C:0B:E9:15:74:19 18:FD:74:38:8E:75 10.0.3.20

Thank you again for you help.
Ramiro.
Here another test, with just 1 icmp packet being sent from mikrtotik's lan IP to foritagate's lan host:

------ OK ------

[admin@mikrotik] > ping 10.0.3.20 src-address=192.168.150.254 size=700 count=1
SEQ HOST SIZE TTL TIME STATUS
0 10.0.3.20 700 127 21ms
sent=1 received=1 packet-loss=0% min-rtt=21ms avg-rtt=21ms max-rtt=21ms

[admin@mikrotik] > tool sniffer quick ip-protocol=icmp,ipsec-esp
INTERFACE TIME NUM DIR SRC-MAC DST-MAC VLAN SRC-ADDRESS DST-ADDRESS PROTOCOL SIZE CPU FP
ether2 0.995 1 -> 18:FD:74:38:8E:75 2C:0B:E9:15:74:19 200.XXX.XXX.16 201.XXX.XXX.2 ip:ipse... 774 0 no
ether2 1.015 2 <- 2C:0B:E9:15:74:19 18:FD:74:38:8E:75 201.XXX.XXX.2 200.XXX.XXX.16 ip:ipse... 774 1 no
ether2 1.015 3 <- 2C:0B:E9:15:74:19 18:FD:74:38:8E:75 10.0.3.20 192.168.150.254 ip:icmp 714 0 no

------------


----- Fail ------

[admin@mikrotik] > ping 10.0.3.20 src-address=192.168.150.254 size=700 count=1
SEQ HOST SIZE TTL TIME STATUS
0 10.0.3.20 timeout
sent=1 received=0 packet-loss=100%

[admin@mikrotik] > tool sniffer quick ip-protocol=icmp,ipsec-esp
INTERFACE TIME NUM DIR SRC-MAC DST-MAC VLAN SRC-ADDRESS DST-ADDRESS PROTOCOL SIZE CPU FP
ether2 1.868 1 -> 18:FD:74:38:8E:75 2C:0B:E9:15:74:19 200.XXX.XXX.16 201.XXX.XXX.2 ip:ipse... 774 0 no
ether2 3.889 2 <- 2C:0B:E9:15:74:19 18:FD:74:38:8E:75 201.XXX.XXX.2 200.XXX.XXX.16 ip:ipse... 150 1 no
ether2 3.908 3 -> 18:FD:74:38:8E:75 2C:0B:E9:15:74:19 200.XXX.XXX.16 201.XXX.XXX.2 ip:ipse... 166 0 no

------------
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IPSec issue

Wed Nov 09, 2022 9:33 pm

OK, so the last test clearly shows that the ESP packet leaves towards the FG but the FG either never receives it or it just doesn't understand it.

What sounds really strange to me is that the FG has a public IP directly on itself but you cannot see any packets to/from the public IP of the Tik on the FG's WAN - did I get this part correct?
 
Ramirocuei
just joined
Topic Author
Posts: 12
Joined: Sat Jan 25, 2020 10:08 pm

Re: IPSec issue

Wed Nov 09, 2022 9:54 pm

OK, so the last test clearly shows that the ESP packet leaves towards the FG but the FG either never receives it or it just doesn't understand it.

What sounds really strange to me is that the FG has a public IP directly on itself but you cannot see any packets to/from the public IP of the Tik on the FG's WAN - did I get this part correct?
Yes you did, i will recheck tomorrow and get back to you with results.

Other wierd thing that happens is that i can't manage the mikrotik from inside the tunnel, i log into winbox and it's like its frozen, after a few seconds i get disconnected. It does not happen with ssh tho. I can manage it with no issue from the public ip.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IPSec issue

Wed Nov 09, 2022 10:20 pm

How far is the Tik from the FG in terms of countries? I can imagine multipath routing between the sites, and some route blocking ESP... But that would only explain the issue of lost packets, not the issue of the Mikrotik IP not being seen at the FG although bare ESP (i.e. not UDP-encapsulated one) is running between them.
 
Ramirocuei
just joined
Topic Author
Posts: 12
Joined: Sat Jan 25, 2020 10:08 pm

Re: IPSec issue

Thu Nov 10, 2022 4:32 pm

How far is the Tik from the FG in terms of countries? I can imagine multipath routing between the sites, and some route blocking ESP... But that would only explain the issue of lost packets, not the issue of the Mikrotik IP not being seen at the FG although bare ESP (i.e. not UDP-encapsulated one) is running between them.
Hello Sindy! they are in Argentina (mikrotik, the only host i have there) and Uruguay (FG, with many roadwarrios that work ok, connecting from uruguay mostly but there are a few in Arg too).

you're theory of ecmp and one path blocking esp is a posibility. I just configured another ipsec tunnel btw the same mikrotik and other mikrotik here in Uruguay (same isp as fortigate) and the traffic flows through this tunnel ok, no packet loss... Even tho traceroute from mikrotik to both fg and mikrotik in UY isnt exactly the same. I guess its probly some trouble with the foritgate-mikrotik config.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IPSec issue

Thu Nov 10, 2022 4:57 pm

you're theory of ecmp and one path blocking esp is a posibility
To check this, if Fortigate supports NAT traversal, you can force NAT into the connection by setting the local-address of the peer representing the Fortigate at the Mikrotik side to one of LAN IPs of the Mikrotik, setting up a dst-nat rule to redirect connections coming to UDP ports 500 and 4500 via WAN to this LAN IP, and removing any existing tracked connections to/from the Fortigate address. This way, the IPsec stack at both peers will start encapsulating ESP into UDP.
 
Ramirocuei
just joined
Topic Author
Posts: 12
Joined: Sat Jan 25, 2020 10:08 pm

Re: IPSec issue

Thu Nov 10, 2022 8:45 pm

you're theory of ecmp and one path blocking esp is a posibility
To check this, if Fortigate supports NAT traversal, you can force NAT into the connection by setting the local-address of the peer representing the Fortigate at the Mikrotik side to one of LAN IPs of the Mikrotik, setting up a dst-nat rule to redirect connections coming to UDP ports 500 and 4500 via WAN to this LAN IP, and removing any existing tracked connections to/from the Fortigate address. This way, the IPsec stack at both peers will start encapsulating ESP into UDP.
I have rechecked and I see that if i ping mikrotiks public IP from fortigates public IP, i have the same packet loss. I have sniffed traffic and i see that some of the echo icmp request do not arrive to the FG. It's really wierd, this FG has many public IP addresses, i can ping the mikrotik public address using any other as source with no loss, but when i ping with this source i have 4-10% loss..

I have tried:
ping from core router (FG's gateway) with the same IP block as origin and i have no loss!
ping from core router with the same IP block as origin to other public addresses on same ipv4 block than mikrotik, with no loss!

I can conclude that problem isnt the tunnel.. i don't know where the issue could be tho..
Thank you again for your help.

Ramiro.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IPSec issue

Thu Nov 10, 2022 9:44 pm

That sounds like some network card dropping packets containing certain bit patterns. I used to think that these were just urban legends but I have seen at least one case like this here on the forum, where a particular packet could not pass through a particular switch.

Who is online

Users browsing this forum: Bing [Bot], ItchyAnkle, menyarito and 100 guests