IPSec VPN with Palo Alto with packet loss and asymetric speed

Hello Forum,

I have setup a Site to Site IPSec VPN with a PA-440 firewall and Mikrotik hAP ax2, the VPN itself it's working but I have a very strange issue that speed is not consistent on both sides of the VPN.

From the Mikrotik side (what in the attached PDF which is a network diagram + troubleshooting notes is called "Mazzini59") the traffic flows to the Palo Alto side ("PaulloHQ") at the full speed reachable by the hAP box, circa 300 mbits.

From the Palo Alto side ("PaulloHQ") to the Mikrotik side ("Mazzini59") it consistently goes slow with many packets lost and retransmissions until after some times packets lost magically stops and speed goes up to 200 mbits.

As you can see in the following picture (it's a reverse iPerf from itmil01jv0002 (PaulloHQ - Palo Alto side) running in server mode - generating traffic - to itmil02pprs01 (Mazzini59 - Mikrotik side).

There is no way to anticipate after how long it will stop dropping packets and then start running at full speed, it just happens if you wait long enough. It does not change anything running in IPv4 or IPv6, the behavior is the same.

As in front of the Palo I have a MK router I tested the connection(s) both ways and it consistently goes at 1 gigabit full speed all of the time, to overrule anything that could be done by the ISP.

The network topology is attached. Thanks to any kind soul who is willing to help,

Luca.

itmil01pm001_000126.pdf (177.4 KB)

Maybe it is related to connection-tracking?

Please, share your configuration Forum Rules / Guide Lines

I just moved the remote side of the VPN to be locally connected to the local side and the configuration works stable and at it's full speed with no retransmissions or bandwidth drops.

I guess it's a problem of the ISP then (both lines same ISP), I've contacted them and I'll let you know.
I'll sanitize the config and post it tomorrow.

Thank you,
Luca

Here's the complete device config. Connection tracking is disabled for what comes from the IPSEC tunnel.

# 2026-09-01 14:55:47 by RouterOS 7.24.1
# software id = EL9N-Q2T3
#
# model = C52iG-5HaxD2HaxD

/interface bridge
add admin-mac=D0:EA:11:5A:58:3D auto-mac=no comment=defconf name=bridge vlan-filtering=yes


/interface wifi
set [ find default-name=wifi1 ] channel.band=5ghz-ax .skip-dfs-channels=10min-cac .width=20/40/80mhz configuration.mode=ap .ssid=MikroTik-5A5841 disabled=no security.authentication-types=wpa2-psk,wpa3-psk .ft=\
    yes .ft-over-ds=yes
set [ find default-name=wifi2 ] channel.band=2ghz-ax .skip-dfs-channels=10min-cac .width=20/40mhz configuration.mode=ap .ssid=MikroTik-5A5841 disabled=no security.authentication-types=wpa2-psk,wpa3-psk .ft=yes \
    .ft-over-ds=yes


/interface ethernet
set [ find default-name=ether1 ] mac-address=D0:EA:11:59:DF:A4


/interface vlan
add interface=ether1 name=OF vlan-id=835
add comment="Backup Replica Server" interface=bridge name=bk_replica_server vlan-id=138


/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
add comment="Backup Network" name=BACKUP

/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=OF list=WAN
add interface=bk_replica_server list=BACKUP


/ip ipsec profile
add dh-group=ecp384 enc-algorithm=aes-256 hash-algorithm=sha384 lifetime=8h name=paullo_hq_phase1

/ip ipsec peer
add address=185.242.181.60/32 exchange-mode=ike2 name=paullo_hp_palo profile=paullo_hq_phase1

/ip ipsec proposal
add auth-algorithms="" enc-algorithms=aes-256-gcm lifetime=1h name=paullo_hq_phase2 pfs-group=ecp384


/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.254

/ip dhcp-server
add add-dns-entries=yes address-pool=default-dhcp interface=bridge name=defconf

/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf dns-server=192.168.88.1 gateway=192.168.88.1


/snmp community
set [ find default=yes ] authentication-protocol=SHA1 encryption-protocol=AES security=private


/disk settings
set auto-media-interface=bridge auto-media-sharing=yes auto-smb-sharing=yes


/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=wifi1
add bridge=bridge comment=defconf interface=wifi2
add bpdu-guard=yes bridge=bridge comment="Backup Replica Server" frame-types=admit-only-untagged-and-priority-tagged interface=ether5 pvid=138


/ip neighbor discovery-settings
set add-dns-entries=yes discover-interface-list=none


/interface bridge vlan
add bridge=bridge comment="Backup Replicas" untagged=ether5 vlan-ids=138


/ip address
add address=192.168.88.1/24 comment=defconf interface=bridge network=192.168.88.0
add address=10.88.38.254/24 interface=bk_replica_server network=10.88.38.0


/ip dhcp-client
add comment=defconf interface=OF name=dhcp_client_navigabene


/ip dns
set allow-remote-requests=yes servers=9.9.9.9,2620:fe::fe


/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=accept chain=input comment="Allow access from management network" src-address=10.88.17.0/25
add action=drop chain=input comment="defconf: drop all coming from WAN" in-interface-list=WAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn

/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN


/ip ipsec identity
add auth-method=digital-signature certificate=it-mil02-1p01-gw01_cavanasystems_com_combined.pem_0,issuing.pem_0 my-id=fqdn:it-mil02-1p01-gw01.cavanasystems.com peer=paullo_hp_palo remote-certificate=root.pem_0

/ip ipsec policy
add action=none comment="Do not tunnel local site" dst-address=10.88.32.0/20 src-address=10.88.32.0/20
add comment=backup_servers_net dst-address=0.0.0.0/0 peer=paullo_hp_palo proposal=paullo_hq_phase2 src-address=10.88.38.0/24 tunnel=yes
add action=none comment="Do not tunnel local site v6" dst-address=2001:67c:d68:100::/57 src-address=2001:67c:d68:100::/57
add comment=backup_servers_net_v6 peer=paullo_hp_palo proposal=paullo_hq_phase2 src-address=2001:67c:d68:100::/57 tunnel=yes


/ip service
set ftp disabled=yes
set ssh available-from=10.88.38.0/24,10.88.17.0/25,2001:67c:d68:106::/64,2001:67c:d68:81::/64
set telnet disabled=yes
set www disabled=yes
set reverse-proxy disabled=yes
set winbox available-from=10.88.38.0/24,10.88.17.0/25,2001:67c:d68:106::/64,2001:67c:d68:81::/64
set api disabled=yes
set api-ssl disabled=yes

/ip ssh
set host-key-size=4096 strong-crypto=yes


/ipv6 address
add address=2001:67c:d68:106::ffff advertise=no interface=bk_replica_server
add from-pool=NavigaBene interface=bridge


/ipv6 dhcp-client
add add-default-route=yes default-route-tables=main interface=OF pool-name=NavigaBene request=prefix


/ipv6 firewall address-list
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
add address=::1/128 comment="defconf: lo" list=bad_ipv6
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6

/ipv6 firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMPv6" protocol=icmpv6
add action=accept chain=input comment="defconf: accept UDP traceroute" dst-port=33434-33534 protocol=udp
add action=accept chain=input comment="defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=udp src-address=fe80::/10
add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 protocol=udp
add action=accept chain=input comment="defconf: accept ipsec AH" protocol=ipsec-ah
add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=ipsec-esp
add action=accept chain=input comment="defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=input comment="defconf: drop everything else coming from WAN" in-interface-list=WAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack6" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop packets with bad src ipv6" src-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" hop-limit=equal:1 protocol=icmpv6
add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=icmpv6
add action=accept chain=forward comment="defconf: accept HIP" protocol=139
add action=accept chain=forward comment="defconf: accept IKE" dst-port=500,4500 protocol=udp
add action=accept chain=forward comment="defconf: accept ipsec AH" protocol=ipsec-ah
add action=accept chain=forward comment="defconf: accept ipsec ESP" protocol=ipsec-esp
add action=accept chain=forward comment="defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=forward comment="defconf: drop everything else coming from WAN" in-interface-list=WAN

/ipv6 firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn


/ipv6 nd
# automatic dns option advertising is not started, re-apply dns config
set [ find default=yes ] advertise-dns=yes


/snmp
set enabled=yes engine-id-suffix=it-mil02-1p01-gw01 trap-version=3

/system clock
set time-zone-name=Europe/Rome

/system identity
set name=it-mil02-1p01-gw01.cavanasystems.com

/tool bandwidth-server
set enabled=no

/tool mac-server
set allowed-interface-list=none

/tool mac-server mac-winbox
set allowed-interface-list=BACKUP

/tool mac-server ping
set enabled=no

Now that I moved this device where it should belong it established again the VPN to the Palo Alto and that's the result from iPerf:

HQ to Mazzini59 (Palo Alto to MK):

Mazzini59 to HQ (MK to Palo Alto)

It went back to how it was behaving in the beginning. If I leave the iPerf running for some time, then it stops re-transmitting packets and the speeeeed goes up.
Again, if I exclude the local ISP from the loop by connecting the Mazzini59 MK to my HQ border router it goes straight to 300 mbits with no retrans.

I'm quite convinced it's the ISP fault. Does anyone have any ideas how to nail them? They refuse to cooperate.

just curious ... are there any fragmentations via ISP line - so maybe a MTU issue?

Sanitized config more. Removed SN as not needed.

I added:

/ip/firewall/raw/ add chain=prerouting fragment=yes action=log log-prefix=FRAG_RAW

Then tested iPerf on v4. No fragementation detected and none expected as both lines are IPOE with 1500 MTU.

thx for that little logging trick btw

@luca.cavana, my top 3 guesses:

  1. ISP reordering causing IPsec anti-replay drops. (see below why)
  2. Packet loss/policing on the PA -> MikroTik path.
  3. MTU/PMTUD (proabably less likely)

I’d watch /ip ipsec statistics, especially in-state-sequence-errors during the slow phase.

Try capturing the encrypted traffic at both WAN ends at the same time. That should show whether ESP packets are being lost in transit or arriving badly out of order. Just make sure the clocks at both ends are properly synced before capturing.

Since the exact same tunnel runs at full speed when bypassing the local ISP, I’d focus on the ISP path first. If possible, try another ISP at a different location or at home.

OK,

I've been trying to do that and I've noticed a thing: traffic originating from the router itself ignores IPSec policies. So my streaming server destination, which is behind the VPN, does not receive traffic as the router tries to send it via the default route.

How do I instruct the router to evaluate IPSec policies when traffic originates from itself?

I'm afraid the policies are matched for packets originating from the router itself, they just don't match the specified src-address criteria.

Try firewall logging to see for yourself.

That was easy enough to solve it myself, I was just going to write the solution is to add a route so that the subnet you want to go down the VPN have an internal interface as a gateway, like so:

/ip/route/print 
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, s - STATIC, d - DHCP
Columns: DST-ADDRESS, GATEWAY, ROUTING-TABLE, DISTANCE
#     DST-ADDRESS      GATEWAY            ROUTING-TABLE  DISTANCE
  DAd 0.0.0.0/0        100.0.0.1          main                  1
0  As 10.88.17.0/25    bk_replica_server  main                  1
  DAc 10.88.38.0/24    bk_replica_server  main                  0
  DAc 100.0.0.1/32     OF                 main                  0
  DAc 192.168.88.0/24  bridge             main                  0

Because as you say, packets are matched with policies but he still doesn't know where to route them if you don't tell him.

Now on to streaming and comparing them packets! :grin:

@Larsa I've made the following tests:

I performed a capture on both ends and compared ESP sequence numbers.
Very few packets are dropped (in the order of a few tents of UDP datagrams for every 15.000 packets) and very few packets arrived out of order (three or four, I don't remember the exact number but very fews).

On MK side I used sniffer streaming to WireShark while on PA I used it's capture facility writing to disk, then compared ESP sequence numbers using a spreadsheet.

I'm more inclined to think it's a firmware bug on some box on the path. What I've seen this morning is that as long as there is some minimal amount of traffic dripping through the VPN then an iPerf session immediately maxes out at 300mbit/s (the most one of the ARM core of the MK can handle with current AES256-CBC encryption).
If you leave the VPN essentially idle for some time then it takes a casual length of time to iPerf to go back to 300mbit/s; it stays at always the same amount around 20 mbit/s then jumps upwards.
This for the direction from HQ to Mazzini59, the reverse always always maxes out at 300mbit/s immediately.

The point is, my ISP does not own the whole path.
The fiber from both locations are handled by the Italy primary wholesale fiber provider, OpenFiber. Traffic is passed at Layer 2 at some location to my ISP which performs routing/exchange and then it is handed back to OpenFiber (as both fiber drops are handled by them).

My ISP denies any filtering and is basically unwilling to do any troubleshooting. I believe them on the filtering statement while I'm quite disappointed at the unwillingness to troubleshoot the issue; it's also possible the issue is not on the path they can see but on OpenFiber transport leg.

... any idea? I've run out.

Okay, that actually gives a few more clues.

A few tens of lost packets out of 15,000 works out to roughly 0.1–0.3% loss, which is definitely enough to seriously cripple a single TCP stream (assuming those packets are actually lost and not just missed in the captures).

The idle-dependent behavior is also interesting. If a little traffic keeps the tunnel "in a good state", but after some idle time it comes back at ~20 Mbit/s and then suddenly jumps to 300, I'd suspect some kind of stateful behavior somewhere along the path, like policing/QoS, ECMP/LAG/path selection, forwarding cache, or maybe a firmware bug in some box along the way, like a flaky switch or something similar.

A crypto/IPsec bug might look similar too, especially on the inbound/decryption side. ESP arrives as it should, but some packets disappear somewhere inside the IPsec/crypto path and cause TCP retransmits. The fact that the same box immediately does 300 Mbit/s when you bypass the ISP path argues against that though, unless something about the packet timing/bursting on the normal path triggers it.

One more thing you can check is comparing the slow and fast phases separately:

  • ESP packets sent by PA vs received by MT.
  • /ip ipsec statistics, especially in-state-protocol-errors and other in-*errors.
  • /ip ipsec installed-sa print detail and check hw-aead.
  • /tool profile cpu=all.

If possible, also capture the decrypted traffic after IPsec on the MikroTik side. If ESP arrives on WAN but the corresponding inner packets disappear, then the MikroTik IPsec/crypto path becomes a much stronger suspect.

I'd also try UDP with iperf3 at different fixed rates during the bad state, e.g. 10/20/30/50/100 Mbit/s. If loss suddenly starts above some fixed rate, that would look a lot like policing/rate limiting somewhere in the provider path.

If you were seeing the same behavior all the time regardless of ISP, I'd probably suspect a ROS bug and open a support ticket. But what you're seeing sounds more like an external problem somewhere "along the path".

That's unfortunately about all I can think of for now. Please keep us updated if you find anything else.

Good luck!

All zeroes:

/ip/ipsec/statistics/print          
                  in-errors: 0
           in-buffer-errors: 0
           in-header-errors: 0
               in-no-states: 4
   in-state-protocol-errors: 0
       in-state-mode-errors: 0
   in-state-sequence-errors: 0
           in-state-expired: 0
        in-state-mismatches: 0
           in-state-invalid: 0
     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: 0
  out-state-protocol-errors: 0
      out-state-mode-errors: 0
  out-state-sequence-errors: 0
          out-state-expired: 0
         out-policy-blocked: 0
            out-policy-dead: 0
          out-policy-errors: 0

HW AEAD is enabled for all SAs:

/ip/ipsec/installed-sa/print detail 
Flags: S - SEEN-TRAFFIC; H - HW-AEAD; E - ESP
0  SHE spi=0x7CED3F58 src-address=185.242.181.60 dst-address=185.130.88.248 state=mature enc-algorithm=aes-gcm enc-key-size=288 addtime=2026-09-03 04:41:56
       expires-in=14m42s add-lifetime=48m1s/1h2s current-bytes=3027371257 current-packets=2138205 replay=128
 
1  SHE spi=0xF905A1E6 src-address=185.130.88.248 dst-address=185.242.181.60 state=mature enc-algorithm=aes-gcm enc-key-size=288 addtime=2026-09-03 04:41:56
       expires-in=14m42s add-lifetime=48m1s/1h2s current-bytes=99439 current-packets=360 replay=128
 
2  SHE spi=0xFC227964 src-address=185.242.181.60 dst-address=185.130.88.248 state=mature enc-algorithm=aes-gcm enc-key-size=288 addtime=2026-09-03 04:42:26
       expires-in=15m19s add-lifetime=48m7s/1h9s current-bytes=539052 current-packets=4697 replay=128
 
3  SHE spi=0xDCF8C050 src-address=185.130.88.248 dst-address=185.242.181.60 state=mature enc-algorithm=aes-gcm enc-key-size=288 addtime=2026-09-03 04:42:26
       expires-in=15m19s add-lifetime=48m7s/1h9s current-bytes=24505014 current-packets=213249 replay=128

This is during a fast phase, I can't reproduce a slow phase as now it's 05:35. It looks like that in the morning is always at full speed no matter what (it's the second morning I notice this, the VPN was just established a few days ago so I'm starting to notice these patterns now).

One of four CPUs is busy processing traffic (ESP decryption and network handling) and that gives the 300 mbit/s.

/tool/profile cpu=all     
Columns: NAME, CPU, USAGE
NAME               CPU  USAGE
networking           0  28.5%
ethernet             0  7.5% 
bridging             0  5%   
console              0  0%   
ipc                  0  0%   
wireless             0  0.5% 
firewall             0  5.5% 
profiling            0  1.5% 
kernel               0  22.5%
bridge2_netfilter    0  0%   
ip6_tables           0  1%   
ip6table_mangle      0  0%   
8021q                0  1%   
esp4                 0  22.5%
cpu0                    95.5%
networking           1  0%   
ethernet             1  0%   
bridging             1  0%   
console              1  0.5% 
ipc                  1  0.5% 
wireless             1  0%   
firewall             1  0.5% 
profiling            1  0.5% 
kernel               1  0.5% 
esp4                 1  0%   
cpu1                    2.5% 
networking           2  0.5% 
interface-mgmt       2  0%   
ethernet             2  0%   
console              2  1%   
ipc                  2  0%   
wireless             2  0%   
firewall             2  0%   
profiling            2  0%   
kernel               2  0%   
8021q                2  0%   
esp4                 2  0%   
ssh                  2  0.5% 
cpu2                    2%   
networking           3  1%   

@Larsa you have been extremely kind and dedicated a lot of time in helping me with this but to me everything points to something external I can't control.
The fiber transport provider will never ever check it's path (there is also no possible way to talk to them), the ISP who is handled the traffic from the fiber transport provider is unwilling to do the same possibly because he already knows something I don't or have zero interest or resources in debugging this.
On top of that, I'm a freelancer Linux sysadmin; I'm a systems guy not a network guy. I lack the necessary finesse on this particular matter; I can grossly understand the matter but I'm afraid I'll make you lose your time in debugging what can be a technically interesting problem but one that in the end I can live with.
On the top of the top, In about two years I'll move home and the fiber transport provider on HQ will switch to a much more mature one, the Palo Alto will be substituted for OPNSense, so everything will change on the slow side.

To me network is a commodity, I would like to troubleshoot this for the sake of knowledge but in the end frustration got the best of it and somehow it's performing sufficiently for it's needs (that is, sending a replica of the backup data done on HQ to a remote location for disaster recovery purpose).

Thank you for the help so far, I wish you all the best.

Hello,

I would suggest you to change your firewall rules because they are a bit incorrect. This will affect your traffic flow, speed, stability.

LAN=Bridge
WAN=internet

/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=accept chain=input comment="Allow access from management network" src-address=10.88.17.0/25
add action=drop chain=input comment="drop all else"
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=forward comment=“internet traffic” in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment=“port forwarding” connection-nat-state=dstnat
add action=drop chain=forward comment=“drop all else”

In the input chain it makes sense as an optimization to

add action=drop chain=input comment="drop all else"

But anyway I've filtered listening services to specific networks that are behind the VPN and for those filtering is made at the other end, still, you are right.

What I don't understand is why you state the I should

add action=accept chain=forward comment=“internet traffic” in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment=“port forwarding” connection-nat-state=dstnat
add action=drop chain=forward comment=“drop all else”

The first rule is already happening as the router will forward anything to anything, the second and third rule are a more complicated and incorrect way to do what the router already does; incorrect because it will also drop the traffic I intend to flow between interfaces.
It may be correct if it's a simple home router with two interfaces "LAN" and "WAN" but that's not the case.

Mikrotik has two basic configuration principles, 1) everything is allowed and only what you define yourself is forbidden (by default). 2) everything is forbidden and only what we need is allowed. This is the recommended method.

You are using the ''default'' method, where everything is allowed, but with small errors that affect traffic flow. Unfortunately, the Mikrotik firewall is not like Fortigate, Sophos...., where the policy specifies who, where and what will be accessed and at the end the last rule is always drop=All and everything. For Mikrotik, the Input chain is a section where incoming traffic is, but the forward- section is a section where we specify all traffic that flows through the router. The recommended method is to end the rules with drop=All at the end of both these sections. Then everything will be correct and if by chance we do not get to some resources, then we define the necessary rule for the forward chain. It can be, for example, accept to Vlan10 to Vlan20 etc etc... According to the example I copied for you, I have 8 branches working in tunnel mode. The traffic flow is correct all the time, no problems have been observed. If I ever experience communication interruptions, 99.9% of the time it's the provider's fault.

Perhaps the following information is also useful: about config

I see what you mean.

I had to refine the firewall rules so I took the opportunity to basically redo it:
For IPv4 what I think I'm doing is:

On the input chain (the router itself):

  1. Allowing ping from everywhere
  2. Allowing access only via the networks in an access list "management_allow_v4" which are basically remote management subnets and the local "secured" network.

On the forward chain (the traffic the router forwards):

  1. Accepting IPSec traffic according to IPSec policlies (traffic is filtered at the remote end)
  2. Letting the "unsecured" network go to Internet thorugh WAN
  3. Accept any (eventual, not present now) port forwarding
/ip firewall address-list
add address=10.88.17.0/25 comment="AdminHosts HQ v4" list=management_allow_v4
add address=10.88.38.0/24 comment="Backup Replicas v4" list=management_allow_v4
add address=10.88.32.0/20 comment="All Secure Networks v4" list=secured_networks_v4
add address=10.88.0.0/20 comment="HQ Net" list=hq_networks_v4
add address=10.88.16.0/20 comment="HQ DC Net" list=hq_networks_v4
/ip firewall filter
add action=accept chain=input comment="accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="drop invalid" connection-state=invalid
add action=accept chain=input comment="accept ICMP" protocol=icmp
add action=accept chain=input comment="Allow access from management network" src-address-list=management_allow_v4
add action=drop chain=input comment="drop all else"
add action=accept chain=forward comment="accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment=fasttrack connection-state=established,related
add action=accept chain=forward comment="accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="drop invalid" connection-state=invalid
add action=accept chain=forward comment="accept internet traffic from UNSECURED LAN to WAN" in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment="accept port forwarding to UNSECURED LAN" connection-nat-state=dstnat connection-state=new
add action=drop chain=forward comment="drop all else"
/ip firewall mangle
add action=change-mss chain=forward comment="clamp MSS to PMTUD" new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn
/ip firewall nat
add action=masquerade chain=srcnat comment="masquerade all" ipsec-policy=out,none out-interface-list=WAN

For IPv6 what I think I'm doing is:

On the input chain (the router itself):

  1. Allowing ping/traceroute from everywhere
  2. Allowing DHCPv6 PD so the local ISP can give an address to the unsecured lan (since the daemon is in the RouterOS software itself)
  3. Allowing access only via the networks in an access list "management_allow_v6" which are basically remote management subnets and the local "secured" network.

On the forward chain (the traffic the router forwards):

  1. Accepting IPSec traffic according to IPSec policlies (traffic is filtered at the remote end)
  2. Since IPv6 addresses on the "secured" network are globally routable and should go out the VPN tunnel and never on the public internet, add a rule to make sure of that. Normally IPSec policies take care of that but here I'm making a security policy decision, not a routing one.
  3. Letting the "unsecured" network go to Internet thorugh WAN
/ipv6 firewall address-list
add address=::/128 comment="unspecified address" list=bad_ipv6
add address=::1/128 comment=lo list=bad_ipv6
add address=fec0::/10 comment=site-local list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment=ipv4-mapped list=bad_ipv6
add address=::/96 comment="ipv4 compat" list=bad_ipv6
add address=100::/64 comment="discard only " list=bad_ipv6
add address=2001:db8::/32 comment=documentation list=bad_ipv6
add address=2001:10::/28 comment=ORCHID list=bad_ipv6
add address=3ffe::/16 comment=6bone list=bad_ipv6
add address=2001:67c:d68:81::/64 comment=AdminHosts-Core_v6 list=management_allow_v6
add address=2001:67c:d68:83::9/128 comment="Zabbix Server" list=management_allow_v6
add address=2001:67c:d68:106::/64 comment="Backup Replicas v4" list=management_allow_v6
add address=2001:67c:d68:100::/57 comment="All Secure Networks v6" list=secured_networks_v6
add address=2001:67c:d68::/57 comment="HQ Net" list=hq_networks_v6
add address=2001:67c:d68:80::/57 comment="HQ DC Net" list=hq_networks_v6
/ipv6 firewall filter
add action=accept chain=input comment="accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="drop invalid" connection-state=invalid
add action=accept chain=input comment="accept ICMPv6" protocol=icmpv6
add action=accept chain=input comment="accept UDP traceroute" dst-port=33434-33534 protocol=udp
add action=accept chain=input comment="accept DHCPv6-Client prefix delegation." dst-port=546 protocol=udp src-address=fe80::/10
add action=accept chain=input comment="allow access from management network" src-address-list=management_allow_v6
add action=drop chain=input comment="drop all else"
add action=accept chain=forward comment="accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment=fasttrack6 connection-state=established,related
add action=accept chain=forward comment="accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="drop invalid" connection-state=invalid
add action=drop chain=forward comment="drop packets with bad src ipv6" src-address-list=bad_ipv6
add action=drop chain=forward comment="drop packets with bad dst ipv6" dst-address-list=bad_ipv6
add action=drop chain=forward comment="rfc4890 drop hop-limit=1" hop-limit=equal:1 protocol=icmpv6
add action=accept chain=forward comment="accept ICMPv6" protocol=icmpv6
add action=drop chain=forward comment="drop all traffic to HQ (in case VPN is unavailable)" dst-address-list=hq_networks_v6 src-address-list=secured_networks_v6
add action=accept chain=forward comment="accept internet traffic from UNSECURED LAN to WAN" in-interface-list=LAN out-interface-list=WAN
add action=drop chain=forward comment="drop all else"
/ipv6 firewall mangle
add action=change-mss chain=forward comment="clamp MSS to PMTUD" new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn

... does it looks correct?

One incomprehensible thing- add action=accept chain=forward comment="accept internet traffic from UNSECURED LAN to WAN" in-interface-list=LAN out-interface-list=WAN What ''unsecured'' ?

This is your local LAN (either VLAN2,3..10 etc.) This is what is accepted :slight_smile:

The Forward section contains everything that concerns the routing of your internal traffic. There we indicate everything that will go to the WAN (outside) for example..Vlan10,Vlan20,Vlan30->to internet. Here we indicate all internal traffic and permissions... allow from MGMT->to Vlan10,20...etc. Either Vlan30->to Vlan10=drop. Nothing complicated.

If you corrected the firewall rules and added the necessary permissions to->to, then so far it will be okay. Looking at your address-list, I would advise you to use VLAN. It is more correct and also simpler from the management side.

If we look at the IPsec section, I'll try to tell you what I use.

Your config:

/ip ipsec profile add dh-group=ecp384 enc-algorithm=aes-256 hash-algorithm=sha384 lifetime=8h name=paullo_hq_phase1 /ip ipsec peer add address=185.242.181.60/32 exchange-mode=ike2 name=paullo_hp_palo profile=paullo_hq_phase1 /ip ipsec proposal add auth-algorithms="" enc-algorithms=aes-256-gcm lifetime=1h name=paullo_hq_phase2 pfs-group=ecp384

The configuration I use:

/ip ipsec profile add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha254 lifetime=8h name=my_phase1

/ip ipsec peer add address=X.X.X.X/32 exchange-mode=ike2 name=my-name profile=my-name_phase1

/ip ipsec proposal add auth-algorithms="" enc-algorithms=aes-256-gcm lifetime=1h name=pfs-group=modp2048

Yes, you describe that you use IPv6. Okay, I didn't mention anything about it, but if we look at the configuration, then it is by default. Of course, you can use it, everything is okay, but here again the question is - do you need IPv6? Does your provider support the IPv6 protocol? For example, I don't need it and I have disabled IPv6 in the router... In the section - IPv6-settings- Disable IPv6. But that's my setup, maybe you need it, I don't know.