If I try to kill it, it comes right back.
If I try to drop everything form those IPs via filter or raw, and then kill the connection, it still comes right back.
Anyone have any insights what this source could be and why can’t it be dropped by firewall?
P.S.
all routers have default firewall rules as a minimum and are allways patched to the latest bugfix the day of release internally via Dude (currently on 6.44.6)
some have L2TP/IPsec servers running, some dont even respond to ping, and none of them have ever had exposed or configured.
Hmm…it seems that this is looking bad…
You might have some internal issue…
Perhaps connections are established from some internal infected host ?
You don’t have UPNP active ?
The E symbol in the ESAC means “expected”, which means that the firewall permits those GRE connections thanks to the pptp helper which tracks the PPTP control connections (TCP port 1723) and treats GRE connections between the endpoint IP addresses of the PPTP control ones as connection-state=related. If you remove the tracked connection, the packets don’t stop coming as the traffic continues and as the firewall keeps accepting them as they are “related”, so they immediately re-appear. Don’t ask me why the connection-state atribute, to which the firewall rules refer, is called “related” whereas the attribute used when displaying the connection is called “expected”, it means the same thing.
So if you /ip firewall service-port set pptp disable=yes, these GRE connections will stop appearing, but you may disappoint some PPTP VPN users. Or not, because these may not be actual PPTP connections, just some scanning attempts. I don’t know at what phase of the PPTP connection establishment the PPTP helper starts treating the GRE packets matching the PPTP control connection’s IP addresses as “related”.
UPDATE: it’s the latter case, scans, as the abusedb item referred to by @jvanhambelgium eventually loaded and it indicates PPTP-targeted scans in particular.
That’s exactly it, Sindy, thank you! E did point me to the connection being enabled by some internal service but couldn’t find which one.
Interestingly, Mikrotik documentation on PPTP server states that 1723/TCP and GRE have to be allowed through firewall, not that it helps itself with GRE automaticaly.
I guess there’s some firewall patching to do.
@vodokotlić, while I do experience some interesting issues with GRE handling in the firewall after the related CVE has been patched, the PPTP helper in particular does what it should do: if you don’t want to permit GRE in general, you can enable the PPTP helper and only control the complete PPTP suite by controlling access to local TCP port 1723, and the GRE follows.
What bothers me in your case is this latter point - I believe the GRE should not become “expected” until the “triggering” TCP session to TCP port 1723 has been at least accepted at TCP level (if not until the authentication has been successful at PPTP control level). Do you have /interface pptp-server server enabled, and incoming connections to TCP port 1723 permitted on the router where you observed these “expected” GRE connections? Or the address you’ve blanked out doesn’t belong to that router but to some other machine in your network whose traffic is only forwarded by this “affected” router?
Well, yes, mistakes were made and both pptp server and 1723/TCP wound up left on/open. Honestly the whole lot will probably end up burned down with netinstall.
This whole thing got noticed by chance, mainly because GRE sort of stands out in connections list, especially when you don’t expect it there. Which brings me to…
Having only a passing familiarity with PPTP (being an obsolete protocol and all), I expected a GRE connection only after passing authentication. Authentication which (I would hope) couldn’t even be brute-forced, as some of them (not meant to host a VPN server) weren’t setup with even a single user in /ppp secret
While its function and usefulness is obvious in retrospect, I don’t understand why its existance is not at least mentioned in the Manual.