The question is about multiple gre between 2 sites.
Supouse the following scenario without IPsec:
1 VPN between Site1 Wan1 and Site2 Wan1
1 VPN between Site1 Wan2 and Site2 Wan2
In Site1 create a route to reach Site2-Wan1 through Site1-Wan1 DG (And the same for the other GRE and the same in the other site)
In Site1 create a filter rule to drop everything with gre protocol, going to Site2-Wan1 through Wan2 (And considering all the cases)
I think I dont need to copy the settings, because that was working fine.
Some months ago, I added IPsec in GRE VPNs (Just writting a password in the “IPsec Secret” field of the GRE properties, in both sides)
GREs are working but I just realliced that if I go to “ip → firewall → connections”, in winbox, and I filter to see only gre protocol, the connections for the tunnel are not there.
I realliced that there are connections for UDP 500 and protocol 50 (ESP), the same connections, but I can not see some GRE+IPsec there, I see the most GRE VPNs but in some cases, some GRE VPNs are not there, so I have the following 2 questions:
Why some few GRE+IPsec connections are missing?
How should I change in the 3rd point? Just changing GRE protocol by ESP protocol is enough?
Would you mind sending supout.rif from the machine where the GRE tunnels run but aren’t visible in /ip firewall connection print where protocol~“gre” to support@mikrotik.com? I have a ticket open on the same issue ([SUP-329]) but I am unable to get the same state in the lab, and I cannot send supout.rif from production machines where it happens.
Thanks Sindy,
I did not know about the supout.rif file, just got the file on an affected router and sent this to support.
I also just realliced that the GRE not showing in /ip firewall connection are those which does not have IPsec secret, but neither appears as gre.
If I filter the “remote address” of the gre, to see all connections to this IP or from this IP (as source or destination address), nothing shows up
Will wait for the answer and let you know.
Regards,
Damián
Hello,
It is because of the disabled PPTP helper under the firewall service-port section. If you will enable it back, GRE connections should appear in the connection tracking table.
Best regards,
Artūrs C.
This was the response, and it is true, I just enabled the pptp service under “Firewall - Service Ports” through gui, and the gre connections are still there.
I’m not sure I get this support answer. Permitting PPTP helper makes GRE tunnels negotiated using PPTP’s TCP control connection be dynamically permitted in the firewall, but this should have nothing to do with GRE connections created using static configuration being tracked or not. Do you use PPTP or not?
I am not using PPTP, just GRE VPNs, PPTP server is disabled in all my routers.
But I could check many times that when I enable the PPTP helper, the GRE connections appears, and when I disable this, the GRE connections disappears.
That’s insane. I’ve done this at a machine where I have 8 locally terminated GRE connections, 6 locally terminated EoIP connections, and 6 transit GRE connections, and all of them popped up in the connection list which was empty before (in terms of protocol=gre of course). So I’m going to ask for a clarification whether what Arturs suggests is an intentional workaround or an undocumented intentional behaviour of the firewall.
Leaving aside that all the GRE connections are tracked as a single one whereas all the EoIP ones are tracked as two independent unidirectional ones.
Anyway, I’m going to comment on this in my own ticket which I haven’t updated yet with the link to yours.
Sindy, thanks to you!!! I only told you what Arturs said. (And you helped me a lot of times)
So you have 6 GRE and there is just 1 GRE connections? Weird
All GRE have the same src-address and dst-address?
I have 1 connection for every GRE, if I have 6 GRE, I have 6 connections (ip → Firewall → Connections)
Bad wording in my post - each GRE is represented by a single bi-directional connection, each EoIP is represented by two unidirectional ones. In the update of my support ticket I was more precise
