I’ve got EOIP working great, but I’d be more comfortable if there were some sort of secret necessary to setup a connection. Sort of like how a radius client and server have their secrets preprogrammed on each side.
I’m envisioning that it would be currently possible for someone to sniff and start getting EOIP traffic. Learn the tunnel-ID, disrupt an endpoint with an IP address conflict or any of various temporary outage scenarios, connect to the EOIP server, and the official other endpoint would not be able to connect anymore since that tunnel-ID is in use. No other tunneling system would be so simple to disrupt. I’m thinking I should block block GRE traffic at EOIP servers except from EOIP clients until some sort of authentication is available. I’m not looking for encryption - other tunneling protocols do that, just some sort of easy authentication when establishing the tunnel to know it’s a legit tunnel setup request.
yep, running it inside of another tunnel provides the security. Now with 3.0 you can supposedly bridge l2tp tunnels with 1500 MTU, so it might make sense to get rid of EoIP and just bridge them all together. Bridge L2TP tunnel to LAN on both sides. Just a thought (for 3.0)
In RouterOS 3.0 all PPP tunnels have BCP (Bridge Control Protocol) and MP (Multilink Protocol) support - in simple terms, you can bridge any PPP interface, just need to set Bridge option in profiles on both ends of the tunnel and specify MRRU to 1500
