@kex666 Как видите всё работает на стенде, да и код GRE протокола в Linux ядре давно никто не трогал уже, включая connection tracking часть, по крайней мере я такого не припомню.

@kex666 Если замечания или предложения по изменению конфигурации RouterOS для теста, то пишите.

у меня нет разрешающих  правил, только дроп инвалидных

established,related>accept - этого нет

может быть, такой способ использования неверен?

Отключил оба правила, разрешающие выше, перезагрузил маршртуизатор для чистоты эксперимента.

[admin@MikroTik] /ip firewall filter> print detail
Flags: X - disabled, I - invalid, D - dynamic
0 X  chain=forward action=fasttrack-connection connection-state=established,related

1 X  chain=forward action=accept connection-state=established,related,untracked

2    chain=forward action=drop connection-state=invalid

[admin@MikroTik] /ip firewall connection> print detail
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying, F - fasttrack, s - srcnat, d - dstnat
0  SAC     protocol=gre src-address=10.0.0.6 dst-address=10.0.0.2 reply-src-address=10.0.0.2 reply-dst-address=10.0.0.6 gre-key=0 timeout=2m34s orig-packets=5 orig-bytes=620 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=5 repl-bytes=620 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps

Router#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/10/35 ms

Знаете чего не хватает этому девайсу? Кольца для того чтобы носить его на связке ключей.

А что за девайс?

GBPeR ?

MQS

а по русски

Точно! Если уж забывать где-то ключи, то в ящике под потолком на объекте в 50км от дома и без доступа по ночам

@kex666 технически в RouterOS default policy accept для всех цепочек в таблице filter, поэтому правило разрешающие accept с конкретным connection-state нужно для случая, когда после drop invalid идут ещё правила, которые могут блокировать например new соединения для WAN и тд. На работу самого connection tracking они не влияют, если он смог создать соединение, то invalid state для GRE пакетов может быть только не правильно сформированный заголовок пакета, других причин я не вижу, когда бы он мог посчитать новый GRE пакет invalid, учитывая, что state у GRE нет, как у протокола.

Посмотрел бегло https://github.com/torvalds/linux/blob/master/net/netfilter/nf_conntrack_proto_gre.c и не вижу там даже на намёка на то, что может привести к попаданию GRE в invalid, но я не программист и тем более не системный, поэтому возможно на мой не проффесиональный взгляд я пропустил где-то в коде место, где он обращается к фукнции которая возможно приведёт к другому файлу в исходных кодах ядра, где будет видно, при каких условиях GRE может попасть в invalid.

Чет я не въеду, ну подкину я к ней PowerBank 5V и она через POE запитает мне 24V SXT?

Именно. Только на выходе будет не 24v, а 12v(которые SXTsq по Passive PoE прекрасно переваривает - проверено)

Понял, круто, надо будет заказать поиграться

а в ip-firewall-serviceport  включен pptp?

без хелпера он не будет отлавливать gre, по идее

Жаль в ней нет COM порта, для настройки свитчей консолью. Ибо я себе подобное слепил с платы RB411