Re: [MT-AU Public] Mikrotik and Starlink
On Sun, 2023-10-15 at 14:55 +0000, Andrew Oakeley wrote:
I'd be inclined to set your allowed-address for the peers to 0.0.0.0/0
On Mon, 2023-10-16 at 09:10 +1100, Roger Plant wrote:
On the Server, You need to add 192.168.16.3 to the allowed addresses in the Client peer entry.
On the Client, You need to add 192.168.16.1 (or maybe .16.0/24 if there will be other peers attached to server in future) to the allowed addresses in the Server peer entry.
I had already tried what Roger suggested, and had added ",192.168.16.0/24" to the allowed-address on each end. It changed the error, but only on the client end, from the error 126 to a timeout. So I just now tried what Andrew suggested, and FMS it then worked; I could ping each Wireguard interface address from its "opposing" address on the link. But WHY?!? Why was it not enough to add just the Wireguard link subnet to each end's allowed-address list? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160
Not sure, Perhaps it isn't choosing the wireguard interface's ip address for pinging for some reason. If very keen, you could do a packet sniff on the wireguard interface. Regards Roger From: Karl Auer <kauer@nullarbor.com.au> To: MikroTik Public <public@talk.mikrotik.com.au> Date sent: Mon, 16 Oct 2023 09:39:29 +1100 Organization: Nullarbor Consulting pty Ltd Subject: Re: [MT-AU Public] Mikrotik and Starlink Send reply to: kauer@nullarbor.com.au, MikroTik Australia Public List <public@talk.mikrotik.com.au> [ Double-click this line for list subscription options ] On Sun, 2023-10-15 at 14:55 +0000, Andrew Oakeley wrote:
I'd be inclined to set your allowed-address for the peers to 0.0.0.0/0
On Mon, 2023-10-16 at 09:10 +1100, Roger Plant wrote:
On the Server, You need to add 192.168.16.3 to the allowed addresses in the Client peer entry.
On the Client, You need to add 192.168.16.1 (or maybe .16.0/24 if there will be other peers attached to server in future) to the allowed addresses in the Server peer entry.
I had already tried what Roger suggested, and had added ",192.168.16.0/24" to the allowed-address on each end. It changed the error, but only on the client end, from the error 126 to a timeout. So I just now tried what Andrew suggested, and FMS it then worked; I could ping each Wireguard interface address from its "opposing" address on the link. But WHY?!? Why was it not enough to add just the Wireguard link subnet to each end's allowed-address list? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au---------------------------- Roger Plant
Replying very late in the game to general Starlink stuff. 1. Don’t trust that your IPv6 prefix will stay the same. I’ve had them change on a service, and last time I looked they don’t really mention IPv6 at all, so all bets are off. 2. Put the Starlink “router” in bridge mode. They are extraordinarily limited in the number of devices they allow behind them. It will all look good for you until too many people connect to the inbuilt wifi and suddenly your router drops (it seems to be a limit of the MAC addresses it allows at once). I’ve seen this where someone put a switch and started adding WAPs. All good until they got to about the third or fourth one and the first people connected started complaining that they had no internet anymore. 3. Starlink does (did?) their IPv4 DHCP renewal as layer 3 from a different source to the original layer 2 broadcast. This means that you may need to allow UDP port 68 in your firewall since your router may now get DHCP responses from a different source. The symptoms of this is that it connects and works, getting an IP via layer 2 DHCP broadcasts. At some point the DHCP renewal will fail because it’s coming from a source different address than the original broadcast. Everything stops until the router throws everything away and starts again sending a new broadcast and getting a new address. As a side note, I’d love to know a better way than to just wildly open UDP port 68! I think that’s pretty much it from a config point of view. The other things to consider: Starlink does slow down and can drop in rain. APNIC found they have increased latency just from cloud cover but I doubt many people would be significantly affected. Dropouts seem to need heavy rain but for farmers this sucks since that is exactly when they are inside trying to catch up on business online. Their latency figures appear often are complete nonsense. Check what the real latency is for you between your sites and decide whether it’s going to make some things unusable or at least unpleasant. Their advertising for pricing is bulls**t and I’m sure violates Australian law. Saying limited time offer reduced from $924, and then as soon at the offer is over the real price is actually only $599 should be investigated by the ACCC and have big consequences. They really do need installing properly as you’ve already noticed. Good cabling installers also tend to hate them, or at least charge more due to the extra work involved. Again their advertising of no installation necessary, or self installable, is bulls**t. Their roof mount kit is junk. In our part of the world (FNQ) where we get cyclones every unit installed this way will almost certainly need to be replaced when it has ripped straight of the roof in even a mild cyclone. Good installers generally use slightly modified (angle grinder cuts) standard satellite dish mounts. Much cheaper and appropriately rated for your area. Everything in our area needs to be cyclone rated so I wonder if this also breaks laws? Experiences in the US indicate that download speeds will drop off as user levels increase. Whether that happens here is hard to know as our population and existing infrastructure is different. Also newer generations of satellites may alleviate this. Personally I don’t want Ellon Musk in control of that much essential global infrastructure. I’m a *very* happy Tesla owner but I personally don’t trust him or his promises. Lastly, as negative as I sound about them, they are amazing technology. They completely change the world for remote areas. The fact that they can do what they do is astounding, and probably only someone like Elon Musk could’ve made it happen. I really hope the mad scramble by Europe and some private companies to produce a competitor works. Once we have more than one option the world will genuinely change. Cheers, Andrew
On 16 Oct 2023, at 9:37 am, Roger Plant <rplant@melbpc.org.au> wrote:
Not sure,
Perhaps it isn't choosing the wireguard interface's ip address for pinging for some reason. If very keen, you could do a packet sniff on the wireguard interface.
Regards Roger
From: Karl Auer <kauer@nullarbor.com.au> To: MikroTik Public <public@talk.mikrotik.com.au> Date sent: Mon, 16 Oct 2023 09:39:29 +1100 Organization: Nullarbor Consulting pty Ltd Subject: Re: [MT-AU Public] Mikrotik and Starlink Send reply to: kauer@nullarbor.com.au, MikroTik Australia Public List <public@talk.mikrotik.com.au>
[ Double-click this line for list subscription options ]
On Sun, 2023-10-15 at 14:55 +0000, Andrew Oakeley wrote:
I'd be inclined to set your allowed-address for the peers to 0.0.0.0/0
On Mon, 2023-10-16 at 09:10 +1100, Roger Plant wrote:
On the Server, You need to add 192.168.16.3 to the allowed addresses in the Client peer entry.
On the Client, You need to add 192.168.16.1 (or maybe .16.0/24 if there will be other peers attached to server in future) to the allowed addresses in the Server peer entry.
I had already tried what Roger suggested, and had added ",192.168.16.0/24" to the allowed-address on each end. It changed the error, but only on the client end, from the error 126 to a timeout.
So I just now tried what Andrew suggested, and FMS it then worked; I could ping each Wireguard interface address from its "opposing" address on the link. But WHY?!? Why was it not enough to add just the Wireguard link subnet to each end's allowed-address list?
Regards, K.
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au---------------------------- Roger Plant
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
On Mon, 2023-10-16 at 10:55 +1000, Andrew Radke wrote:
Replying very late in the game to general Starlink stuff.
But thanks - all very good to know.
2. Put the Starlink “router” in bridge mode.
There will only be three devices on it, so we should be good. I'm keeping bridge mode in reserve. This system is sort of borrowed from the owner so I'm trying to touch the actual Starlink stuff as little as possible. They will probably end up on NBN fixed wireless eventually.
you may need to allow UDP port 68 in your firewall
Good to know! Or will be if we do end up having to go to bridge mode.
more due to the extra work involved. Again their advertising of no installation necessary, or self installable, is bulls**t.
Well, to be fair this system was practically just thrown at the ground and it's working, so...
we get cyclones
We don't :-)
I really hope the mad scramble by Europe and some private companies to produce a competitor works. Once we have more than one option the world will genuinely change.
IMHO the world has to stop depending on satellites for things that can be done with glass. Orbital pollution is already close to out of hand. "It's expensive" is not the same as "it can't be done". Oh, and stop depending on "the market" to provide essential services. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160
On 16 Oct 2023, at 11:16 am, Karl Auer <kauer@nullarbor.com.au> wrote:
On Mon, 2023-10-16 at 10:55 +1000, Andrew Radke wrote:
more due to the extra work involved. Again their advertising of no installation necessary, or self installable, is bulls**t.
Well, to be fair this system was practically just thrown at the ground and it's working, so...
That’s kinda the problem. People get them and then just throw them on the ground because what else do you do. Then they order the roof mount kit...
we get cyclones
We don't :-)
If you get the chance have a look at the roof mount kit. It *might* be okay on a tiled roof, but it does not spread the load suitably for corrugated iron. It also only uses two screws and a very very small footprint for a significantly larger dish. Southern parts of Australia also get some absolutely wild storms and often with very short notice. At least with a cyclone we all know to bring everything inside. Of course the Internet is kind of essential in a situation like that so you get left with bringing the dish in or not, if you even remember the thing.
I really hope the mad scramble by Europe and some private companies to produce a competitor works. Once we have more than one option the world will genuinely change.
IMHO the world has to stop depending on satellites for things that can be done with glass. Orbital pollution is already close to out of hand. "It's expensive" is not the same as "it can't be done". Oh, and stop depending on "the market" to provide essential services.
Absolutely!!! Rural and remote areas though are a real challenge. Maybe the government should stop and think about how the NBN actually works with fixed wireless and start spending money on getting comms into these areas via other means (full disclaimer, we own a small rural WISP for exactly that purpose, and we have to report each year how much we owe for the rural broadband scheme but we don’t get anything back. Luckily the value owed is $0, but still…) Cheers, Andrew
On Mon, 2023-10-16 at 12:16 +1100, Karl Auer wrote:
On Mon, 2023-10-16 at 10:55 +1000, Andrew Radke wrote:
we get cyclones We don't :-)
Well, I take it all back and maintain the opposite. We had really high winds today and some nitwit^H^H^H^H^Hice person (not me!) put the dish out, perched on its four little feet on top of a 6- foot high stone wall. It blew off and landed face down on the previously mentioned coarse gravel. Only superficial damage done, but lessons were learned :-) There was no point putting it back on the wall in that wind, so I put the thing right way up on the ground right beside the wall, with another wall made of large utes and trucks no more than four feet from it. In that position, it worked flawlessly. I was impressed. In Wireguard news, the link from the Mikrotik in one office out via Starlink to the Mikrotik in the other office is now working. It did not work until I disabled a second peer on the remote router. After re- enabling that peer I tried changing its allowed-addresses from "0.0.0.0/0" to just the link interface addresses and the LAN on the other end of that link, and that worked too. No idea why; it was a total hunch. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160
On Mon, 2023-10-16 at 09:39 +1100, Karl Auer wrote:
I had already tried what Roger suggested, and had added ",192.168.16.0/24" to the allowed-address on each end.
So I just now tried what Andrew suggested, and FMS it then worked [...] but WHY?!?
Argh. I just tried restricting each end's allowed-address list to the other end's subnet plus ",192.168.16.0/24", and this time, it worked. So while I am happy it does work as advertised, I am also very puzzled as to why it works now. I don't have a scrollback buffer showing the previous configuration, and I did not export the defective configuration, so I am unable to double-check my work. I guess I have to assume I mistyped something. Many MANY thanks for your help. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160
On Mon, 2023-10-16 at 11:00 +1100, Karl Auer wrote:
it worked.
I spoke too soon. I can ping addresses in each connected LAN from the router at the other end of the wireguard link. But I cannot ping LAN-to-LAN (or make other connections LAN-to-LAN). Sniffing shows the pings from a LAN-connected device are arriving at the local router interface (e.g. wlan1 or ether3), but getting no response. Sniffing the wireguard interface shows those pings are not arriving there, i.e. they are not getting from the ingress interface to wg0. For pings sent from the router itself, sniffing shows those pings do arrive at the wireguard interface. Experimentally I allowed all traffic on the input, output and forward chains on both ends; this made no difference. I'm stumped. Server end: /interface wireguard add comment="wireguard interface" listen-port=14149 mtu=1420 name=wg0 /interface wireguard peers add allowed-address=192.168.103.0/24,192.168.16.0/24 comment="X" \ interface=wg0 persistent-keepalive=30s public-key=\ "KpVHU/XirostgcJMFXXXXXXXXXXsVJi58VBkueYLW24=" Routes: DAd 0.0.0.0/0 99.85.36.1 1 DAc 99.85.36.0/22 e1-uplink 0 0 As 192.168.1.0/24 192.168.16.3 1 DAc 192.168.16.0/24 wg0 0 DIcH 192.168.88.0/24 e5-management 0 DAc 192.168.102.0/24 bridge-local 0 1 As 192.168.103.0/24 192.168.16.2 1 Addresses (LAN is 102): 0 192.168.88.1/24 192.168.88.0 e5-management 1 192.168.102.1/24 192.168.102.0 e2-master 2 D 99.85.38.31/22 99.85.36.0 e1-uplink 3 192.168.16.1/24 192.168.16.0 wg0 Client (Starlink) end: /interface wireguard add comment="wireguard interface" listen-port=27547 mtu=1420 name=wg0 /interface wireguard peers add allowed-address=192.168.102.0/24,192.168.16.0/24 comment="Y" \ endpoint-address=99.85.38.31 endpoint-port=14149 interface=wg0 \ persistent-keepalive=30s public-key=\ "ZWxg5TXKRJ3zaHS7oXXXXXXXXXXpJmCdNxLirHwQsHM=" Routes: DAd 0.0.0.0/0 192.168.1.1 1 DAc 192.168.1.0/24 e1-uplink 0 DAc 192.168.16.0/24 wg0 0 DIcH 192.168.88.0/24 e5-management 0 0 As 192.168.102.0/24 192.168.16.1 1 DAc 192.168.103.0/24 bridge-local 0 Addresses (LAN is 103.0/24): 0 192.168.88.1/24 192.168.88.0 e5-management 1 192.168.103.1/24 192.168.103.0 e2-master 2 192.168.16.2/24 192.168.16.0 wg0 3 D 192.168.1.21/24 192.168.1.0 e1-uplink Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160
Hi, It all looks pretty well ok I think. My new guess is that there may still be some ipsec policies and settings configured. Requiring traffic from X to Y be tunnelled with ipsec. Hopefully :) Regards Roger From: Karl Auer <kauer@nullarbor.com.au> To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Date sent: Wed, 18 Oct 2023 14:15:08 +1100 Organization: Nullarbor Consulting pty Ltd Subject: Re: [MT-AU Public] Mikrotik and Starlink Send reply to: kauer@nullarbor.com.au, MikroTik Australia Public List <public@talk.mikrotik.com.au> [ Double-click this line for list subscription options ] On Mon, 2023-10-16 at 11:00 +1100, Karl Auer wrote:
it worked.
I spoke too soon. I can ping addresses in each connected LAN from the router at the other end of the wireguard link. But I cannot ping LAN-to-LAN (or make other connections LAN-to-LAN). Sniffing shows the pings from a LAN-connected device are arriving at the local router interface (e.g. wlan1 or ether3), but getting no response. Sniffing the wireguard interface shows those pings are not arriving there, i.e. they are not getting from the ingress interface to wg0. For pings sent from the router itself, sniffing shows those pings do arrive at the wireguard interface. Experimentally I allowed all traffic on the input, output and forward chains on both ends; this made no difference. I'm stumped. Server end: /interface wireguard add comment="wireguard interface" listen-port=14149 mtu=1420 name=wg0 /interface wireguard peers add allowed-address=192.168.103.0/24,192.168.16.0/24 comment="X" \ interface=wg0 persistent-keepalive=30s public-key=\ "KpVHU/XirostgcJMFXXXXXXXXXXsVJi58VBkueYLW24=" Routes: DAd 0.0.0.0/0 99.85.36.1 1 DAc 99.85.36.0/22 e1-uplink 0 0 As 192.168.1.0/24 192.168.16.3 1 DAc 192.168.16.0/24 wg0 0 DIcH 192.168.88.0/24 e5-management 0 DAc 192.168.102.0/24 bridge-local 0 1 As 192.168.103.0/24 192.168.16.2 1 Addresses (LAN is 102): 0 192.168.88.1/24 192.168.88.0 e5-management 1 192.168.102.1/24 192.168.102.0 e2-master 2 D 99.85.38.31/22 99.85.36.0 e1-uplink 3 192.168.16.1/24 192.168.16.0 wg0 Client (Starlink) end: /interface wireguard add comment="wireguard interface" listen-port=27547 mtu=1420 name=wg0 /interface wireguard peers add allowed-address=192.168.102.0/24,192.168.16.0/24 comment="Y" \ endpoint-address=99.85.38.31 endpoint-port=14149 interface=wg0 \ persistent-keepalive=30s public-key=\ "ZWxg5TXKRJ3zaHS7oXXXXXXXXXXpJmCdNxLirHwQsHM=" Routes: DAd 0.0.0.0/0 192.168.1.1 1 DAc 192.168.1.0/24 e1-uplink 0 DAc 192.168.16.0/24 wg0 0 DIcH 192.168.88.0/24 e5-management 0 0 As 192.168.102.0/24 192.168.16.1 1 DAc 192.168.103.0/24 bridge-local 0 Addresses (LAN is 103.0/24): 0 192.168.88.1/24 192.168.88.0 e5-management 1 192.168.103.1/24 192.168.103.0 e2-master 2 192.168.16.2/24 192.168.16.0 wg0 3 D 192.168.1.21/24 192.168.1.0 e1-uplink Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au---------------------------- Roger Plant
On Wed, 2023-10-18 at 19:23 +1100, Roger Plant wrote:
It all looks pretty well ok I think.
Yeah, I agree :-)
My new guess is that there may still be some ipsec policies and settings configured. Requiring traffic from X to Y be tunnelled with ipsec.
I disabled the ipsec peers, but did not actually remove the configurations. What I'm doing now is configuring up a minimal replacement router with none of the cruft of the existing one. And I will remove the ipsec configuration from the other end. Fingers crossed that when I drop this in place tomorrow, it will Just Work. This is all complexificated by the fact that I cannot access the Starlink end remotely (yet). Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160
This is all complexificated by the fact that I cannot access the Starlink end remotely (yet). Simple PPTP/L2TP/OVPN/Whatever VPN out from the starlink end to your office is a useful way of having a backdoor into the remote end. Then you can play with the site-to-site VPN's to your hearts content without risking getting yourself locked out
-----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Karl Auer Sent: Wednesday, October 18, 2023 5:22 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Mikrotik and Starlink On Wed, 2023-10-18 at 19:23 +1100, Roger Plant wrote:
It all looks pretty well ok I think.
Yeah, I agree :-)
My new guess is that there may still be some ipsec policies and settings configured. Requiring traffic from X to Y be tunnelled with ipsec.
I disabled the ipsec peers, but did not actually remove the configurations. What I'm doing now is configuring up a minimal replacement router with none of the cruft of the existing one. And I will remove the ipsec configuration from the other end. Fingers crossed that when I drop this in place tomorrow, it will Just Work. This is all complexificated by the fact that I cannot access the Starlink end remotely (yet). Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
This is all complexificated by the fact that I cannot access the Starlink end remotely (yet).
Teamviewer or similar to a (spare) desktop or server is often quite handy here. Can you ping 192.168.16.2, maybe connect to it from your end (laptop) From: Karl Auer <kauer@nullarbor.com.au> To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Date sent: Wed, 18 Oct 2023 20:21:33 +1100 Organization: Nullarbor Consulting pty Ltd Subject: Re: [MT-AU Public] Mikrotik and Starlink Send reply to: kauer@nullarbor.com.au, MikroTik Australia Public List <public@talk.mikrotik.com.au> [ Double-click this line for list subscription options ] On Wed, 2023-10-18 at 19:23 +1100, Roger Plant wrote:
It all looks pretty well ok I think.
Yeah, I agree :-)
My new guess is that there may still be some ipsec policies and settings configured. Requiring traffic from X to Y be tunnelled with ipsec.
I disabled the ipsec peers, but did not actually remove the configurations. What I'm doing now is configuring up a minimal replacement router with none of the cruft of the existing one. And I will remove the ipsec configuration from the other end. Fingers crossed that when I drop this in place tomorrow, it will Just Work. This is all complexificated by the fact that I cannot access the Starlink end remotely (yet). Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au---------------------------- Roger Plant
On Wed, 2023-10-18 at 20:21 +1100, Karl Auer wrote:
What I'm doing now is configuring up a minimal replacement router with none of the cruft of the existing one. And I will remove the ipsec configuration from the other end.
On Wed, 2023-10-18 at 19:23 +1100, Roger Plant wrote:
My new guess is that there may still be some ipsec policies and settings configured. Requiring traffic from X to Y be tunnelled with ipsec.
It was indeed the ipsec configuration. My minimal config had *exactly* the same symptoms as the current production router. Until I removed the ipsec config from the remote router. In hindsight, with 20/20 vision, it is blindingly obvious that I should have disabled the policies, not the peers. Elation and annoyance in equal parts... Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160
Yay, Well done. As noted earlier, it has been quite entertaining, probably less so if I was under stress sitting in front of a broken link. Cool Regards Roger From: Karl Auer <kauer@nullarbor.com.au> To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Date sent: Wed, 18 Oct 2023 21:37:18 +1100 Organization: Nullarbor Consulting pty Ltd Subject: Re: [MT-AU Public] Mikrotik and Starlink Send reply to: kauer@nullarbor.com.au, MikroTik Australia Public List <public@talk.mikrotik.com.au> [ Double-click this line for list subscription options ] On Wed, 2023-10-18 at 20:21 +1100, Karl Auer wrote:
What I'm doing now is configuring up a minimal replacement router with none of the cruft of the existing one. And I will remove the ipsec configuration from the other end.
Roger Plant
participants (4)
-
Andrew Oakeley -
Andrew Radke -
Karl Auer -
Roger Plant