firewall filter protocol 47 gre

PSob · Fri May 17, 2019 6:01 pm

I try the wiki rule to drop insecury GRE, and it's not work for me.
Then I test more primitive config and see that if GRE interface enabled - firewall ignored input traffic (no packets count, no log message)
Below is an example configuration and ping (ignored first rule action=drop chain=input log=yes protocol=gre)
if disable GRE interface or configure ipsec for gre than firewall work normal with rule protocol=gre (logs and count)
Is this behavior normal or bug?
(I tried the same rb750g3 and 6.42/44)

[admin@MikroTik] > export compact
# jan/02/1970 01:26:36 by RouterOS 6.43.16
# software id = YVUN-8QQX
#
# model = 2011LS
# serial number = 3D7002218EF5
/interface gre
add local-address=192.168.61.3 name=gre-tunnel1 remote-address=192.168.61.1
/ip neighbor discovery-settings
set discover-interface-list=all
/ip address
add address=192.168.88.1/24 interface=ether2 network=192.168.88.0
add address=192.168.61.3/29 interface=ether1 network=192.168.61.0
add address=192.168.101.3/24 interface=gre-tunnel1 network=192.168.101.0
/ip firewall filter
add action=drop chain=input log=yes protocol=gre
add action=accept chain=input in-interface=!ether2 log=yes
/ip route
add distance=1 gateway=gre-tunnel1
[admin@MikroTik] > ip firewall filter print stats
Flags: X - disabled, I - invalid, D - dynamic 
 #    CHAIN                                                                                       ACTION                            BYTES         PACKETS
 0    input                                                                                       drop                                  0               0
 1    input                                                                                       accept                              995              10
[admin@MikroTik] > /log print
01:24:22 system,info router rebooted 
01:24:33 interface,info ether1 link up (speed 100M, full duplex) 
01:24:34 interface,info ether2 link up (speed 1G, full duplex) 
01:24:35 interface,info gre-tunnel1 link up 
01:24:37 firewall,info input: in:gre-tunnel1 out:(unknown 0), src-mac c0:a8:3d:03:00:00, proto UDP, 0.0.0.0:5678->255.255.255.255:5678, len 147 
01:25:11 firewall,info input: in:ether1 out:(unknown 0), src-mac b8:69:f4:00:eb:cc, proto UDP, 192.168.61.1:5678->255.255.255.255:5678, len 152 
01:25:11 firewall,info input: in:gre-tunnel1 out:(unknown 0), src-mac c0:a8:3d:03:00:00, proto UDP, 0.0.0.0:5678->255.255.255.255:5678, len 147 
01:26:03 firewall,info input: in:gre-tunnel1 out:(unknown 0), src-mac c0:a8:3d:03:00:00, proto ICMP (type 8, code 0), 192.168.61.1->192.168.101.3, len 50 
01:26:04 firewall,info input: in:gre-tunnel1 out:(unknown 0), src-mac c0:a8:3d:03:00:00, proto ICMP (type 8, code 0), 192.168.61.1->192.168.101.3, len 50 
01:26:05 firewall,info input: in:gre-tunnel1 out:(unknown 0), src-mac c0:a8:3d:03:00:00, proto ICMP (type 8, code 0), 192.168.61.1->192.168.101.3, len 50 
01:26:06 firewall,info input: in:gre-tunnel1 out:(unknown 0), src-mac c0:a8:3d:03:00:00, proto ICMP (type 8, code 0), 192.168.61.1->192.168.101.3, len 50 
01:26:07 firewall,info input: in:gre-tunnel1 out:(unknown 0), src-mac c0:a8:3d:03:00:00, proto ICMP (type 8, code 0), 192.168.61.1->192.168.101.3, len 50 
01:26:11 firewall,info input: in:ether1 out:(unknown 0), src-mac b8:69:f4:00:eb:cc, proto UDP, 192.168.61.1:5678->255.255.255.255:5678, len 152 
01:26:11 firewall,info input: in:gre-tunnel1 out:(unknown 0), src-mac c0:a8:3d:03:00:00, proto UDP, 0.0.0.0:5678->255.255.255.255:5678, len 147 
01:26:14 system,info,account user admin logged in from 68:05:CA:5A:3F:CC via winbox 
01:26:20 system,info,account user admin logged in via local

sindy · Fri May 17, 2019 10:41 pm

Sorry, I don't get what you want to achieve and what doesn't work, nor which of the methods from the wiki you have used.

If the idea is to accept an incoming GRE packet only if it came encrypted using IPsec and drop it otherwise, the drop rule in your export must say chain=input action=drop protocol=gre ipsec-policy=in,none

PSob · Mon May 20, 2019 9:34 am

these rules must count and log any packet and drop gre?
/ip firewall filter
add action=drop chain=input log=yes protocol=gre
add action=accept chain=input in-interface=!ether2 log=yes

if /interface gre set gre-tunnel1 disable=yes - input proto 47 logged
01:40:08 firewall,info input: in:ether1 out:(unknown 0), src-mac b8:69:f4:00:eb:cc, proto 47, 192.168.61.1->192.168.61.3,
01:40:09 firewall,info input: in:ether1 out:(unknown 0), src-mac b8:69:f4:00:eb:cc, proto 47, 192.168.61.1->192.168.61.3,
01:40:19 firewall,info input: in:ether1 out:(unknown 0), src-mac b8:69:f4:00:eb:cc, proto 47, 192.168.61.1->192.168.61.3,

if /interface gre set gre-tunnel1 disable=no - input proto 47 not logged and not dropped
01:41:25 system,info device changed by admin
01:41:35 interface,info gre-tunnel1 link up
01:41:45 firewall,info input: in:gre-tunnel1 out:(unknown 0), src-mac c0:a8:3d:03:00:00, proto ICMP (type 8, code 0), 192.168.61.1->192.168.101.3, len 50
01:41:46 firewall,info input: in:gre-tunnel1 out:(unknown 0), src-mac c0:a8:3d:03:00:00, proto ICMP (type 8, code 0), 192.168.61.1->192.168.101.3, len 50
01:41:47 firewall,info input: in:gre-tunnel1 out:(unknown 0), src-mac c0:a8:3d:03:00:00, proto ICMP (type 8, code 0), 192.168.61.1->192.168.101.3, len 50

when i use bad ipsec conf and chain=input action=drop protocol=gre ipsec-policy=in,none
this rule not count any packet and gre works without encryption

sindy · Mon May 20, 2019 9:56 am

these rules must count and log any packet and drop gre?
/ip firewall filter
add action=drop chain=input log=yes protocol=gre
add action=accept chain=input in-interface=!ether2 log=yes

If these are the only two rules in chain=input of /ip firewall filter of the machine on which the /interface gre is created, the first one should indeed log and drop any received gre packet, regardless whether it came in plaintext or encrypted and whether the /interface gre is disabled or enabled. The second rule is only there to log whatever comes in via other interface than ether2, but everything else which didn't match any of these two rules is silently accepted because the default behaviour of Mikrotik's /ip firewall filter is "accept".

So what your log suggests is that there is a rule chain=input action=accept connection-state=established before the chain=input action=drop log=yes protocol=gre one in your /ip firewall filter. If so (and it would mean that you have redacted the output of the export before posting it), the gre packets sent by the Mikrotik create a tracked connection, so the incoming gre packets match that tracked connection and thus match any rule which has the connection-state=established matcher in it.

PSob · Mon May 20, 2019 10:19 am

no any established rule. I encountered a problem while changing the configuration on rb750g3 and tested with clean config on rb2011LS (config in first post)

[admin@MikroTik] > /ip firewall filter print all  
Flags: X - disabled, I - invalid, D - dynamic 
 0    chain=input action=drop protocol=gre log=yes log-prefix="" 

 1    chain=input action=accept in-interface=!ether2 log=yes log-prefix="" 
[admin@MikroTik] > /ip firewall mangle print all 
Flags: X - disabled, I - invalid, D - dynamic 
[admin@MikroTik] > /ip firewall nat print all    
Flags: X - disabled, I - invalid, D - dynamic 
[admin@MikroTik] > /ip firewall raw print all   
Flags: X - disabled, I - invalid, D - dynamic 
[admin@MikroTik] > /ip firewall filter print stats
Flags: X - disabled, I - invalid, D - dynamic 
 #    CHAIN                                              ACTION                            BYTES         PACKETS
 0    input                                              drop                                  0               0
 1    input                                              accept                              450               9

sindy · Mon May 20, 2019 10:47 am

That would mean that RouterOS bypasses firewall in some cases for GRE, which would be really bad.

What does /ip firewall connection print where protocol~"gre" show while the gre tunnel is up?

PSob · Mon May 20, 2019 11:20 am

[admin@MikroTik] > /ip firewall connection print where protocol~"gre"
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying, F - fasttrack, s - srcnat, d - dstnat 
 #          PR.. SRC-ADDRESS           DST-ADDRESS           TCP-STATE   TIMEOUT     ORIG-RATE REPL-RATE ORIG-PACKETS REPL-PACKETS
 0    C     gre  192.168.61.3          192.168.61.1                      29s            592bps      0bps           36            0

PSob · Mon May 20, 2019 11:28 am

tested with ipsec - proto 47 logged

03:54:07 firewall,info input: in:ether1 out:(unknown 0), src-mac b8:69:f4:00:eb:cc, proto 50, 192.168.61.1->192.168.61.3, len 124 
03:54:07 firewall,info input: in:ether1 out:(unknown 0), proto 47, 192.168.61.1->192.168.61.3, len 74 
03:54:07 firewall,info input: in:gre-tunnel1 out:(unknown 0), proto ICMP (type 8, code 0), 192.168.61.101->192.168.101.3, len 50

sindy · Mon May 20, 2019 11:58 am

OK. So I've set this up here, and yes, at least in 6.44.3 even the mangle rules in firewall do not see the GRE packets when the tunnel is established and IPsec is not, although /tool sniffer shows the GRE packets to come. I'd say it's worth opening a ticket with support@mikrotik.com.

tdw · Mon May 20, 2019 12:14 pm

Does disabling the PPTP helper service make any difference? (As helpers are tied up with conntrack, which gets the packets before mangle, packet flow may be interfered with)

sindy · Mon May 20, 2019 12:47 pm

Does disabling the PPTP helper service make any difference?

It doesn't.

anav · Mon May 20, 2019 8:12 pm

Hi Sindy can you state in plane ingleesh, what the issue is here.
It seems that the router cannot see into encrypted traffic and how is this bad???

sindy · Mon May 20, 2019 8:22 pm

No. What is bad here is that under some circumstances the GRE packets (carrying tunnel payload) bypass the firewall, which e.g. prevents them from being dropped if they come "naked" rather than encrypted in IPsec transport packets. So if you set up an IPsec-protected GRE tunnel and the IPsec part fails to establish for some reason, the GRE tunnel will work anyway but with no encryption and you have no possibility to prevent that (at least in receive direction, maybe it can be done in transmit direction where it would even make more sense, I have to check once I get back home).

PSob · Thu May 23, 2019 3:54 pm

received a response from support: disable fast-path
/interface gre set 0 allow-fast-path=no
after this firewall see all packets

Thank You

firewall filter protocol 47 gre

firewall filter protocol 47 gre

Re: firewall filter protocol 47 gre

Re: firewall filter protocol 47 gre

Re: firewall filter protocol 47 gre

Re: firewall filter protocol 47 gre

Re: firewall filter protocol 47 gre

Re: firewall filter protocol 47 gre

Re: firewall filter protocol 47 gre

Re: firewall filter protocol 47 gre

Re: firewall filter protocol 47 gre

Re: firewall filter protocol 47 gre

Re: firewall filter protocol 47 gre

Re: firewall filter protocol 47 gre

Re: firewall filter protocol 47 gre