May 2019 - Public - talk.mikrotik.com.au

Axiom Cyber Shield
by Philip Loenneker 27 Jan '21

27 Jan '21

Hi all, After seeing their presentation at the Melbourne MUM, we've been having a look at Axiom Cyber Shield. Is anyone on here using it and happy to provide some feedback, on-list or off-list? It certainly sounds like a good product, but I only seem to be able to find sales pitch information, not unbiased reviews. Regards, Philip Loenneker | Network Engineer | TasmaNet 40-50 Innovation Drive, Dowsing Point, Tas 7010, Australia P: 1300 792 711 philip.loenneker(a)tasmanet.com.au<mailto:philip.loenneker@tasmanet.com.au> www.tasmanet.com.au<http://www.tasmanet.com.au/>

3 7

Filtering by part of URL
by Malcolm Faed 05 Jun '19

05 Jun '19

Hi all, I would like to filter access by a portion of the URL. I have a HLS streaming server where the URLs are in the form: http://123.123.123.123:4545/hls/1/1.m3u8 http://123.123.123.123:4545/hls/2/2.m3u8 http://123.123.123.123:4545/hls/3/3.m3u8 (These can not be changed) The server is behind DST-NAT I need to allow / block access from different IP public addresses based on the " hls/1/1.m3u8" part of the URL. Here has been my naive approach that did not work. I tried creating a layer 7 filter add comment="Match HLS stream for CCTV" name=CCTV regexp="\/hls\/1\/1.m3u8" And using this in the filter add action=drop chain=input comment="Drop all traffic to CCTV except allowed" dst-address='my public ip' dst-port=4545 layer7-protocol=CCTV log=yes protocol=tcp src-address=!203.123.168.150 I also tried the forward chain based on the wiki, but since this is behind a DST NAT, I think input is correct. Any advise appreciated. TIA, Mal *Malcolm Faed*Network Broadcast Engineer malcolm(a)avcomm.com.au Av-Comm Office: +61 2 9939 4377 Mobile+61 424 957 053 Unit 24 / 9 Powells Road, Brookvale, NSW 2100, Australia. avcomm.com.au [image: Twitter] <https://twitter.com/AvCommSatellite>[image: Google Plus] <https://plus.google.com/+AvcommAustralia/>[image: Youtube] <https://www.youtube.com/channel/UCO8ZtcnwoTH7e54LAndE-yw>[image: Linkedin] <https://www.linkedin.com/company-beta/6583589/> This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorised disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. Av-Comm is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.

4 7

Re: [MT-AU Public] Radar detection Chaos Since 6.40.4
by Mike Everest 31 May '19

31 May '19

Hi Harry, thanks for the comments! (have you tried subscribing to the public list? What happens when you try to add a subscription?) That is only the LIPD class license document but it does not list the relevant standards. The standards list some of the ETSI specifications which according to MT include radar detect operation. From MT perspective, they claim that DFS implies Radar Detect in the relevant standards. I have no doubt that it DOES make that link in the EU specification, but since our AU compliance requirements also refer to some ETSI standard then it is possible that our rules are also affected by the recent updates to relevant ETSI standards simply by association and since ACMA have not explicitly excluded that revision... This is what I am attempting to ascertain ;) So far, I have not been able to find the direct relationships and have been doing the rounds of some compliance folks to try to get to the bottom of it all. It may take some time :-1 Cheers, Mike. ---------------------------------------------------------------------------- -------- Why Choose DuxTel for all your MikroTik needs? 10 good reasons: http://duxtel.com/why_duxtel ---------------------------------------------------------------------------- -------- Follow our tweets for news and updates: http://twitter.com/duxtel > -----Original Message----- > From: Harry Fiotakis [mailto:Harry.Fiotakis@tasmanet.com.au] > Sent: Monday, 23 October 2017 10:39 AM > To: Mike Everest (mike(a)duxtel.com) <mike(a)duxtel.com> > Cc: Philip Loenneker <Philip.Loenneker(a)tasmanet.com.au> > Subject: RE: [MT-AU Public] Radar detection Chaos Since 6.40.4 > > Morning Mike, Phil forwarded me the latest correspondence as I still have not > been approved on the mailing list :( > > https://www.legislation.gov.au/Details/F2015L01438 (Radiocommunications > (Low Interference Potential Devices) Class Licence 2015) > > 5250-5350 Must use DFS > 5470-5600 Must use DFS > 5650-5725 Must use DFS > > No Radar Detect required (it is not implied) > > We will have to seek official clarification on that if Mikrotik require it, but > with it forced on we are downgrading Mikrotik radios or simply not using > them. > > > Regards, > > Harry Fiotakis | TasmaNet > 40-50 Innovation Drive, Tas 7010, Australia > M: 0418 540 806 P: 1300 792 711 > Email: harry.fiotakis(a)tasmanet.com.au > > > -----Original Message----- > From: Philip Loenneker > Sent: Monday, October 23, 2017 10:30 AM > To: Harry Fiotakis <Harry.Fiotakis(a)tasmanet.com.au> > Subject: FW: [MT-AU Public] Radar detection Chaos Since 6.40.4 > > > -----Original Message----- > From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of > Mike Everest > Sent: Monday, 23 October 2017 9:50 AM > To: 'MikroTik Australia Public List' <public(a)talk.mikrotik.com.au> > Subject: Re: [MT-AU Public] Radar detection Chaos Since 6.40.4 > > Further update on this issue, > > I've had a bit of correspondence with them, but they are 'fighting' it. Latest > comment from them is that "ETSI standard mentions when you use DFS and > those ranges you need to use the Radar-detect. Radar detect is happening > only for 1 minute." > > The line they are taking is that since our LIPD class license specification says > that DFS must be enabled for the sub 5785 channels, then radar detect must > also be enabled. I've been trying to pore through all the relevant ACMA > documentation so that I can find some definitive paragraph that clarifies the > situation, but so far have drawn a blank. > > I need someone who has some specific familiarity with the relevant rules and > standard that can find something that will convince them to turn it off - any > takers? :-} > > Cheers, Mike. > > > > _______________________________________________ > Public mailing list > Public(a)talk.mikrotik.com.au > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au

5 26

Mikrotik VPN and MS Windows authentication issues
by Paul Julian 29 May '19

29 May '19

Hi All, We have a customer who is running a Windows server environment with Active Directory, they also use a Mikrotik and run PPTP VPN to connect into their office. They are having issues with authentication on the Windows PC's when accessing the shares on the server and wondering if anybody has any suggestions on how to make this work. I recall some time ago that there were issues if the cached credentials on the PC's weren't updated regularly, and I have also wondered if using Windows IAS for the VPN Authentication may help but the customer is looking to us for help and I haven't really done this sort of thing for a while and was hoping that somebody could point me in the right direction for a solution which would work for them and not cause them to have to re-auth when accessing those resources on the server. Thanks Paul

7 13

Mikrotiks odds and ends for sale
by Jason Hecker 26 May '19

26 May '19

If you didn't think you had enough 24V plugpacks and PoE splitter cables lying about then have I got a deal for you! PSU https://www.ebay.com.au/itm/113761747032 100Mbit splitters https://www.ebay.com.au/itm/113760524420 1Gbit splitters https://www.ebay.com.au/itm/113761733187 And this HP switch which I will send to you in the CRS328 box that replaced it. https://www.ebay.com.au/itm/113761690096 Regards, Jason Hecker <https://www.upandrunningtech.com.au/> <https://www.upandrunningtech.com.au/>

1 0

IPv6 with VRRP?
by Damien Gardner Jnr 09 May '19

09 May '19

Hi All, Having a bit of a weird one. Managed to score a couple of RB1100AHx4's cheap on eBay (Oh my lord they are fast!), so am using them for EOIP between sites for my personal colo, as well as BGP redundancy between the sites. v4 BGP is coming along nicely, but v6 is driving me nuts. Ideally I'd have VRRP between the two 1100's on the public VLAN facing my VM's, for the gateway IP, but still have an IP in the subnet on each router for reachability (aka a pretty standard setup..). That works as expected for IPv4. For IPv6, it's a whole other kettle of fish.. Here's a config chunk as example: /interface vlan add interface=bond_bridge mtu=9100 name=vlan39_PUBLIC vlan-id=39 /interface vrrp add interface=vlan39_PUBLIC mtu=9100 name=vlan39_vrrp v3-protocol=ipv6 vrid=39 /ipv6 address add address=2406:c500:fff3::1 advertise=no interface=vlan39_vrrp add address=2406:c500:fff3::2 advertise=no disabled=yes interface=vlan39_PUBLIC /ipv6 route add distance=1 gateway=2400:d400:b97:3c8f::1 add distance=1 gateway=2400:d400:b97:1c8f::1 add check-gateway=ping distance=1 dst-address=2406:c500:fff3:ff00::/56 gateway=2406:c500:fff3::29 Now, while that ::2 IP is disabled, everything works fine. I can ping hosts on the local /64, and on the routed /56. But if I enable the ::2 IP on the parent interface, I can still ping hosts on the local /64, but stop being able to ping hosts on the routed /56, until I remove the IP again: SEQ HOST SIZE TTL TIME STATUS 0 2400:d400:b97:3c8f::2 104 64 2ms hop limit exceeded 1 2400:d400:b97:3c8f::2 104 64 1ms hop limit exceeded 2 2400:d400:b97:3c8f::2 104 64 1ms hop limit exceeded >> disabled ::2 IP 3 2406:c500:fff3:ffe1::2 56 63 1ms echo reply 4 2406:c500:fff3:ffe1::2 56 63 0ms echo reply The v6 routing table for the local LAN with the ::2 IP disabled: 5 ADC dst-address=2406:c500:fff3::/64 gateway=vlan39_vrrp gateway-status=vlan39_vrrp reachable distance=0 scope=10 6 A S dst-address=2406:c500:fff3:ff00::/56 gateway=2406:c500:fff3::29 gateway-status=2406:c500:fff3::29 reachable via vlan39_vrrp check-gateway=ping distance=1 scope=30 target-scope=10 And same with the :2 IP enabled: 5 ADC dst-address=2406:c500:fff3::/64 gateway=vlan39_vrrp,vlan39_PUBLIC gateway-status=vlan39_vrrp reachable,vlan39_PUBLIC reachable distance=0 scope=10 6 S dst-address=2406:c500:fff3:ff00::/56 gateway=2406:c500:fff3::29 gateway-status=2406:c500:fff3::29 unreachable check-gateway=ping distance=1 scope=30 target-scope=10 Is anyone using VRRP on IPv6 successfully, and have any pointers? I 'could' up and down the spare IP in scripts on the VRRP interface, but that seems problematic... And the static route on V6 doesn't let me add %vlan39_PUBLIC or the like in the gateway field to force it out the parent interface.. Thanks, Damien -- Damien Gardner Jnr VK2TDG. Dip EE. GradIEAust rendrag(a)rendrag.net - http://www.rendrag.net/ -- We rode on the winds of the rising storm, We ran to the sounds of thunder. We danced among the lightning bolts, and tore the world asunder

1 1

Transit provider
by Malcolm Faed 01 May '19

01 May '19

Hi all, We are looking for an internet transit provider for 200+ Mbps in Syd EQ1 Target price is < AU$10 / Mbps. Does anyone have any recommendations based on experience, reliability, ease of setting up and customer service. TIA. *Malcolm Faed*Network Broadcast Engineer malcolm(a)avcomm.com.au Av-Comm Office: +61 2 9939 4377 Mobile+61 424 957 053 Unit 24 / 9 Powells Road, Brookvale, NSW 2100, Australia. avcomm.com.au [image: Twitter] <https://twitter.com/AvCommSatellite>[image: Google Plus] <https://plus.google.com/+AvcommAustralia/>[image: Youtube] <https://www.youtube.com/channel/UCO8ZtcnwoTH7e54LAndE-yw>[image: Linkedin] <https://www.linkedin.com/company-beta/6583589/> This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorised disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. Av-Comm is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.

1 0