I have (yet another) location where the MT device is unresponsive.
I lost Wireguard connectivity, but I can ping it. No response to telnet, ssh or mac telnet.
I understand it is not advised, and there has been a (warranted) scare of two, but how insecure is leaving port 8291 (Winbox) open to the Internet?
Is there any other way I can leave a way to get in?
Thanks.
Re: How insecure of 8791?
ZeroTier if ARM since it will try a few different path to connect, and not as exposed to configuration issues that WG would be firewall/etc.
Winbox does not use very good encryption and does not have robust DoS features is why it's not generally recommended to be open to internet. But same logic kinda apply to SSH, although you can use stronger keys.
[IP] Telnet being enabled is worse than winbox however.
Winbox does not use very good encryption and does not have robust DoS features is why it's not generally recommended to be open to internet. But same logic kinda apply to SSH, although you can use stronger keys.
[IP] Telnet being enabled is worse than winbox however.
Re: How insecure of 8791?
If you can ping it, it should be reachable.
You can also use port-knocking scheme ?
Or other VPN protocol as backup (IPSEC / SSTP / ...) ?
You can also use port-knocking scheme ?
Or other VPN protocol as backup (IPSEC / SSTP / ...) ?
Re: How insecure of 8791?
Yup, some backup VPN might be a good idea.
Beyond ZeroTier. If you have two Mikrotik, SSTP is pretty trivial to setup between them. L2TP is also pretty easy to configure if you need VPN from a desktop. Or even a container with CloudFlare ZeroTrust WARP tunnel be another option too, although way more complex to setup.
Beyond ZeroTier. If you have two Mikrotik, SSTP is pretty trivial to setup between them. L2TP is also pretty easy to configure if you need VPN from a desktop. Or even a container with CloudFlare ZeroTrust WARP tunnel be another option too, although way more complex to setup.
Re: How insecure of 8791?
If you have some central Mikrotik router, another option might be EoIP+IPSec connected from remotes to the central router. If you enable RoMON on all the routers... then you connect the central router via winbox+romon, you'd see all the remotes via the EoIP tunnels. The EoIP do NOT need to be bridged to anything, and it's "Use IPSec" option make encryption pretty trivial.
The nice option here is RoMON runs independent of firewall, and EoIP makes it look like a LAN to RoMON. And if NOT bridged, just a plain interface, it should just carry RoMON.
The nice option here is RoMON runs independent of firewall, and EoIP makes it look like a LAN to RoMON. And if NOT bridged, just a plain interface, it should just carry RoMON.
Re: How insecure of 8791?
Yup.
Well known concept to me.
I use Romon via unbridged EOIP over Wireguard quite frequently, works brilliantly for this purpose.
Well known concept to me.
I use Romon via unbridged EOIP over Wireguard quite frequently, works brilliantly for this purpose.
Re: How insecure of 8791?
Telnet is not enabled on any of my devices.
The only way to access any of my devices is by being on the LAN or connected via WG.
Many of my devices are hEX, so not ARM.
I had someone go and cycle the power, and I know it comes back up because I have a netwatch script that emails when connectivity to the upstream (provider's) router changes from up to down and from down to up.
And I can ping the device.
But the WG tunnel is down and I have no access to it. And I really don't want to make the trip there, or buy/configure/overnight a new AC3.
I do have cloud DDNS enabled, so I have the DDNS name, but that's not helping get into the device.
Anything else I can try?
Thanks.
The only way to access any of my devices is by being on the LAN or connected via WG.
Many of my devices are hEX, so not ARM.
I had someone go and cycle the power, and I know it comes back up because I have a netwatch script that emails when connectivity to the upstream (provider's) router changes from up to down and from down to up.
And I can ping the device.
But the WG tunnel is down and I have no access to it. And I really don't want to make the trip there, or buy/configure/overnight a new AC3.
I do have cloud DDNS enabled, so I have the DDNS name, but that's not helping get into the device.
Anything else I can try?
Thanks.
Re: How insecure of 8791?
So the dyndns address check out to the current WANIP of the remote device and you can ping the device but WG does not come up??
Did you make any changes to the config prior to losing connectivity as there is no clear reason I can think of that would cause loss of connectivity.
Did you make any changes to the config prior to losing connectivity as there is no clear reason I can think of that would cause loss of connectivity.
Re: How insecure of 8791?
I have been had on my to-do list to play with EoIP for a while.
Can EoIP be set up between MT devices independently of Wireguard?
I ask because the WG tunnel is not up to that device, so if EoIP relied on it, EoIP would not work.
I don’t know how to set it up.
Can EoIP be set up between MT devices independently of Wireguard?
I ask because the WG tunnel is not up to that device, so if EoIP relied on it, EoIP would not work.
I don’t know how to set it up.
Re: How insecure of 8791?
Well, I can’t be sure of the wan up address without being at the site (I believe).So the dyndns address check out to the current WANIP of the remote device and you can ping the device but WG does not come up??
Did you make any changes to the config prior to losing connectivity as there is no clear reason I can think of that would cause loss of connectivity.
Absolutely no changes were made to the MT device at that location. Internet service went down but then came back up. I had the MT device power cycled. That’s all.
Re: How insecure of 8791?
EOIP works between two IP addresses and doesn't care about how its packets move from point A to point B. So one can use any kind of connectivity to do the job. Since EOIP doesn't do any encryption, it's wise to use something that does it. IPsec is fine, wireguard is fine, etc.
Re: How insecure of 8791?
Only point was EoIP is easily encrypted with the "Use IPSec" checkbox, which uses a PSK defined on EoIP interface... which is kinda handy. Since pure IPSec is a lot of config...EOIP works between two IP addresses and doesn't care about how its packets move from point A to point B. So one can use any kind of connectivity to do the job. Since EOIP doesn't do any encryption, it's wise to use something that does it. IPsec is fine, wireguard is fine, etc.
And if you mess-up a firewall config remotely, you'd want some Layer2 VPN IMO.
Re: How insecure of 8791?
It sounds like a great.
I’m concerned (don’t know if justified) that doing this will create one large broadcast lan. I’m sure there are good ways to prevent all traffic on all eoip-connected devices from hearing each other. Something better than a firewall drop rule.
I’m concerned (don’t know if justified) that doing this will create one large broadcast lan. I’m sure there are good ways to prevent all traffic on all eoip-connected devices from hearing each other. Something better than a firewall drop rule.
Re: How insecure of 8791?
Interesting proposal I always used SSTP ( mt to mt approach ) without certificates as my preferred Mt to Mt backup to wireguard.
Re: How insecure of 8791?
Before ros7 and wireguard, sstp was also my choice for direct connection.
Re: How insecure of 8791?
Yeah but without certificate how safe is it................. As for IPIP sounded better, more secure than SSTP without certificate BUT, a big BUTT, is that it appears BOTH sides need to have publicly reachable WANIPs ( and maybe even static ones ). All the clowns at MT and youtube always show the easy EFFING lab examples of two static WANIPS. If so, then IPIP is useless........
Hence SSTP remains better as only only needs one reachable public IP.
Hence SSTP remains better as only only needs one reachable public IP.
Re: How insecure of 8791?
Yeah but without certificate how safe is it.................
The Let's Encrypt certificate obtained with /certificate/enable-ssl-certificate can be used for SSTP without problems. Everything then works with the built-in SSTP client on Windows and no site-to-site configuration is needed if we just want an emergency entry point to the router. The downside is that the certificate setting needs to be updated every 3 months, the LE auto-update feature currently only modifies the www-ssl setting, not the SSTP Server setting (beside that the LE auto-update feature should not be relied on anyway, because it requires WebFig on port 80 to be permanently exposed to the internet, and who wants that?).
Re: How insecure of 8791?
SSTP sounds very interesting.
Renewing a certificate every 3 months does like a recipe for disaster.
Any downside to using SSTP without a cert?
I like the idea of EoIP because of the advantages of layer 2 connectivity to all devices, but I am concerned about traffic or taxing the MT devices with firewall rules.
Renewing a certificate every 3 months does like a recipe for disaster.
Any downside to using SSTP without a cert?
I like the idea of EoIP because of the advantages of layer 2 connectivity to all devices, but I am concerned about traffic or taxing the MT devices with firewall rules.
Re: How insecure of 8791?
I would use EOIP or IPIP before SSTP, but both of those require two publicly reachable IP addresses at both ends, which removes about 95 of use cases, I run up against.
Re: How insecure of 8791?
The idea is EoIP just carries RoMON protocol. If EoIP is NOT bridge to anything, and each end has a unique IP address in same subnet (and subnet it NOT used by anything else), there shouldn't be much traffic since nothing route to it. I would NOT use EoIP to replace your existing WG – use that for normal traffic. The idea here is to have some "backup" management interface beyond WG (e.g. in case you misconfigured WG remotely).I like the idea of EoIP because of the advantages of layer 2 connectivity to all devices, but I am concerned about traffic or taxing the MT devices with firewall rules.
The trick is since EoIP is ethernet-like interface, it works with RoMON. And since RoMON on a local router will find more routers on other "real" ethernet lines. So if the EoIP terminated at some central router, it be able to see anything with RoMON enabled – even if it's two hops aways (e.g. hub router --(eoip)--> remote --(etherX)--> ap).
There is nothing special to configure on RoMON to use EoIP, other making sure RoMON is enabled and secrets match. You can limit the interface RoMON will use, but obviously it have to include at least the EoIP interface (under ports).
Re: How insecure of 8791?
Wouldn't this require bridge between eoip and etherX on remote device?So if the EoIP terminated at some central router, it be able to see anything with RoMON enabled – even if it's two hops aways (e.g. hub router --(eoip)--> remote --(etherX)--> ap).
Re: How insecure of 8791?
That is a great way to conceptualize the use of eoip, and a great way to make an initial (and possibly final) implementation.The idea is EoIP just carries RoMON protocol. If EoIP is NOT bridge to anything, and each end has a unique IP address in same subnet (and subnet it NOT used by anything else), there shouldn't be much traffic since nothing route to it. I would NOT use EoIP to replace your existing WG – use that for normal traffic. The idea here is to have some "backup" management interface beyond WG (e.g. in case you misconfigured WG remotely).I like the idea of EoIP because of the advantages of layer 2 connectivity to all devices, but I am concerned about traffic or taxing the MT devices with firewall rules.
The trick is since EoIP is ethernet-like interface, it works with RoMON. And since RoMON on a local router will find more routers on other "real" ethernet lines. So if the EoIP terminated at some central router, it be able to see anything with RoMON enabled – even if it's two hops aways (e.g. hub router --(eoip)--> remote --(etherX)--> ap).
There is nothing special to configure on RoMON to use EoIP, other making sure RoMON is enabled and secrets match. You can limit the interface RoMON will use, but obviously it have to include at least the EoIP interface (under ports).
It would indeed be very nice to have RoMON-access to all devices.
I've watched some videos, but I quickly get confused.
On MT-Device-212 I set up:
/interface eoip
add mac-address=02:DE:09:37:65:E0 name=eoip-tunnel-to-76 remote-address=x.dyndns.org tunnel-id=102
/ip firewall
add action=accept chain=input comment="Allow GRE for EoIP" protocol=gre
On MT-Device-76 I set up:
/interface eoip
add mac-address=02:CD:A2:6F:20:47 name=eoip-tunnel-to-212-rb5009 remote-address=xxxx.dyndns.org tunnel-id=102
/ip firewall
add action=accept chain=input comment="Allow GRE for EoIP" protocol=gre
If I connect to 76 using RoMON and check for neighbors I can see 212.
So far, so good, right?
You guys are so great!
Re: How insecure of 8791?
Dont forget to tick the ipsec security otherwise you are creating an open hole at both ends.....
Re: How insecure of 8791?
True. It's actually setting the "IPSec Secret" that enables in V7 – I'm remembering V6 I think with checkbox.Dont forget to tick the ipsec security otherwise you are creating an open hole at both ends.....
Someone suggested that EoIP with IPSec enabled, only one side needs to have a public IP. But I cannot recall the specifics. But theoretically if IPSec used IKEv2, it shouldn't need public on both sides & since it's IPSec tunnel that making the connection, it's NAT rules follow IPSec. Unencrypted EoIP (which is pure GRE) does require publics at both ends – but that's not what we want anyway. If both side have static public IP, everything is easier.
Re: How insecure of 8791?
Good thing for me that you guys pointed out the ipsec entry.
I had left it empty.
Note that when I added an ipsec key, I was forced to turn off "Allow Fast Path"
I had left it empty.
Note that when I added an ipsec key, I was forced to turn off "Allow Fast Path"
Re: How insecure of 8791?
Id be interested in your only one side needs public IP teaser. Please elaborate!!!
Re: How insecure of 8791?
Which is okay, you're really just using it for management. But all encryption has to flow through the CPU anyway.Note that when I added an ipsec key, I was forced to turn off "Allow Fast Path"
Re: How insecure of 8791?
Here was the post: viewtopic.php?t=203951&hilit=eoip+nat#p1053229Id be interested in your only one side needs public IP teaser. Please elaborate!!!
It suggests when EoIP with an "IPSec Secret" set, that Mikrotik does enable nat-traversal=yes under /ip/ipsec. The OP had statics, so didn't matter. I haven't tested it, but IPSec should be able to deal with one side being a NAT'ed – it was whether Mikrotik's EoIP+IPSec automatic IPSec config enabled it was the question....
Re: How insecure of 8791?
Just tested with Fiber+Static to LTE+CGNAT with EoIP+IPSec: It works. But still need use the CGNAT'ed remote address on the "static IP" side. But you can use the DDNS name of the CGNAT side in EoIP config (even though it says "Behind a NAT" in /ip/cloud) for that. No need to set a local address in EoIP (in fact with IPSec, it just be more confusing) & tunnel ID's need to match – but that's it. Beyond enabling RoMON.Id be interested in your only one side needs public IP teaser. Please elaborate!!!
Re: How insecure of 8791?
Y:ou have to be more clear than that sir,
I have no idea what you mean by this .....
But still need use the CGNAT'ed remote address on the "static IP" side
Take as many sentences as you need so the layperson (me) understands what you mean.
Also any reason why I should not be able to do same in IPIP which in my mind is superior having less overhead !!
I have no idea what you mean by this .....
But still need use the CGNAT'ed remote address on the "static IP" side
Take as many sentences as you need so the layperson (me) understands what you mean.
Also any reason why I should not be able to do same in IPIP which in my mind is superior having less overhead !!
Re: How insecure of 8791?
Makes perfect sense -- thanks.Which is okay, you're really just using it for management. But all encryption has to flow through the CPU anyway.Note that when I added an ipsec key, I was forced to turn off "Allow Fast Path"
Re: How insecure of 8791?
I just set things up here so the router I call 212 has an EoIP connection to a bunch of others (76, 125, 629, 371, 255, 355).
All but 255 and 355 are MT devices and work great.
255 and 355 are Ubiquiti UDM-Pro routers with hEX's behind them (essentially providing WG services; and now EoIP connectivity).
255 works great (Running status on the connecting tunnels at 212 and 255).
355 has running state at the 212 MT device, but not at the 355 hEX.
I looked at the configs for the UDM's at 255 and 355 and don't see what could be different.
I was thinking that maybe the UDM at 355 was blocking GRE packets, but I don't see anything on the 255 UDM that would explicitly allow GRE packets forwarded.
I added a firewall rule of type INTERNET-IN to allow GRE protocol; and I added port forwarding for 47 to the hEX's ip address.
Still doesn't work.
All but 255 and 355 are MT devices and work great.
255 and 355 are Ubiquiti UDM-Pro routers with hEX's behind them (essentially providing WG services; and now EoIP connectivity).
255 works great (Running status on the connecting tunnels at 212 and 255).
355 has running state at the 212 MT device, but not at the 355 hEX.
I looked at the configs for the UDM's at 255 and 355 and don't see what could be different.
I was thinking that maybe the UDM at 355 was blocking GRE packets, but I don't see anything on the 255 UDM that would explicitly allow GRE packets forwarded.
I added a firewall rule of type INTERNET-IN to allow GRE protocol; and I added port forwarding for 47 to the hEX's ip address.
Still doesn't work.
Re: How insecure of 8791?
It's actually IPSec, not GRE, that need to be allowed through Ubiquiti UDM-Pro to get to the "hidden hEX" #355. Only the MikroTik Routers be able to see the GRE, since the tunnel is encrypted to even the Ubiquiti UDM-Pro....
Possible the Ubiquiti UDM is accepting, rather than forwarding, the IPSec too.
Possible the Ubiquiti UDM is accepting, rather than forwarding, the IPSec too.
Re: How insecure of 8791?
Still working on this, but no success yet.
I even tried removing the IPsec secret on both sides of the EoIP tunnel and still could not get a Running status on the 355 side.
Does that change the analysis about the UDM not allowing IPsec through?
I don't see any differences in between the UDM at 255 and the UDM at 355.
I set up another EoIP tunnel between 355 and 371 and had the same results. So something at 355 is not working, most likely something at the UDM.
I even tried removing the IPsec secret on both sides of the EoIP tunnel and still could not get a Running status on the 355 side.
Does that change the analysis about the UDM not allowing IPsec through?
I don't see any differences in between the UDM at 255 and the UDM at 355.
I set up another EoIP tunnel between 355 and 371 and had the same results. So something at 355 is not working, most likely something at the UDM.
Re: How insecure of 8791?
More info:
On the 355 device, under IP | IPSEC | ACTIVE PEERS, both tunnels show as ESTABLISHED, with both tx and rx bytes and packets.
If I'm reading this correctly, the IPsec tunnels are established between the 355 device and the 212 (and 371) device(s) but the EoIP tunnel is not.
Any ideas?
On the 355 device, under IP | IPSEC | ACTIVE PEERS, both tunnels show as ESTABLISHED, with both tx and rx bytes and packets.
If I'm reading this correctly, the IPsec tunnels are established between the 355 device and the 212 (and 371) device(s) but the EoIP tunnel is not.
Any ideas?
Re: How insecure of 8791?
I'm an idiot.
I'm scouring the exports to compare 355 and 255 MT device's configs and I see that the GRE FW rule was set to FORWARD (instead of INPUT).
Sorry for the false alarm.
I'm scouring the exports to compare 355 and 255 MT device's configs and I see that the GRE FW rule was set to FORWARD (instead of INPUT).
Sorry for the false alarm.
Re: How insecure of 8791?
AMMO, can you test with IPIP instead or at least tell me how to do so beyond the standard settings.
aka. for client site with no static public IP --> what do I put for local address?>>
aka. for server site with public IP --> what do I put for remote address??
What additional firewall rules are required since I am not picking any particular ispec just a secret are there are any ports to open on input chain for server device.
Any funky source nat rules etc...................
aka. for client site with no static public IP --> what do I put for local address?>>
aka. for server site with public IP --> what do I put for remote address??
What additional firewall rules are required since I am not picking any particular ispec just a secret are there are any ports to open on input chain for server device.
Any funky source nat rules etc...................
Re: How insecure of 8791?
I wrote an article here explaining:AMMO, can you test with IPIP instead or at least tell me how to do so beyond the standard settings.
aka. for client site with no static public IP --> what do I put for local address?>>
aka. for server site with public IP --> what do I put for remote address??
What additional firewall rules are required since I am not picking any particular ispec just a secret are there are any ports to open on input chain for server device.
Any funky source nat rules etc...................
viewtopic.php?t=206322
For firewall, it allow GRE on input from the remote address (or address-list with DDNS name). Keep in mind default firewall allows 500 and 4500 for IPSec by default & using following masquerade rules that exempts IPSec outbound:
Code: Select all
/ip firewall address-list
add address=other-router-DDNS.sn.mynetname.net list=gre-allowed
/ip firewall filter
add action=accept chain=input comment="allow IPsec NAT" dst-port=4500 protocol=udp
add action=accept chain=input comment="allow IKE" dst-port=500 protocol=udp
# [...]
add action=accept chain=input comment="accept GRE" protocol=gre src-address-list=gre-allowed
# [...]
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
Last edited by Amm0 on Sat Mar 30, 2024 11:37 pm, edited 1 time in total.
Re: How insecure of 8791?
Nice!!! questions already asked there..
Re: How insecure of 8791?
Successful connection between one static and one dynamic IP using IPIP and ipsec secret.
I established a winbox connection over the link!
I established a winbox connection over the link!