- Public - talk.mikrotik.com.au

How to set the pptp client default route distance for IPv6??
by Damien Gardner Jnr 03 Aug '15

03 Aug '15

Hi Folks, Not sure if I've found a bug in the PPTP client in RouterOS, or if I'm just missing something. Our ADSL at home is pretty horrendous, so I run ADSL + LTE, PPTP over the top of both back to SY3, and then OSPF over the those (only for connected routes, not default routes - default comes from the PPTP interfaces). Home nat's out of the the DC, unless the DC is offline, then it falls back to ADSL, an then to 4G. We do a lot of traffic on our LTE connection, but I've noticed that occasionally we have long streams of outbound traffic, but it's usually overnight, so I haven't been able to torch it. Turns out, it's IPv6! I didn't realise I even had IPv6 running over the PPTP tunnels, I figured it was just local to the house only, and going to the 'net over our DSL. But no, we have V6 on the PPTP tunnels, which was unexpected. The issue turns out to be, that the default routes being created when the PPTP sessions come up, aren't using the 'Default Route Distance' setting on the PPTP interface. Our V4 default routes look like this: [admin@MikroTik] > /ip route print detail where dst-address=0.0.0.0/0 Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit 0 A S dst-address=0.0.0.0/0 gateway=203.45.254.1 gateway-status=203.45.254.1 reachable via pppoe-tid distance=1 scope=30 target-scope=10 routing-mark=out-force-tid ^ Manual default route for servers in the DMZ 1 A S dst-address=0.0.0.0/0 gateway=192.168.8.1 gateway-status=192.168.8.1 reachable via lte1 distance=50 scope=30 target-scope=10 routing-mark=out-force-lte ^ Manual default route for traffic destined to m.telstra.com 2 ADS dst-address=0.0.0.0/0 gateway=192.168.13.2 gateway-status=192.168.13.2 reachable via pptp-out-syd3-adsl distance=10 scope=30 target-scope=10 ^ Default route over PPTP-ADSL. Lowest distance, as preferred 3 DS dst-address=0.0.0.0/0 gateway=192.168.13.3 gateway-status=192.168.13.3 reachable via pptp-out-syd3-lte distance=20 scope=30 target-scope=10 ^ Default route over PPTP-LTE. Second-lowest distance, keeps NAT sessions running, but we firewall off a few things to keep bandwidth down 4 DS dst-address=0.0.0.0/0 gateway=203.45.254.1 gateway-status=203.45.254.1 reachable via pppoe-tid distance=40 scope=30 target-scope=10 ^ Default route if both PPTP are down - out ADSL 5 DS dst-address=0.0.0.0/0 gateway=192.168.8.1 gateway-status=192.168.8.1 reachable via lte1 distance=50 scope=30 target-scope=10 vrf-interface=lte1 ^ Deafult route of last resort, natting out behind LTE However our V6 routes look like this: [admin@MikroTik] > /ipv6 route print detail where dst-address=::/0 Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable 0 ADS dst-address=::/0 gateway=pppoe-tid gateway-status=pppoe-tid reachable distance=1 scope=30 target-scope=10 1 DS dst-address=::/0 gateway=fe80::2a94:fff:fef1:5900%pppoe-tid gateway-status=fe80::2a94:fff:fef1:5900%pppoe-tid reachable distance=1 scope=30 target-scope=10 2 DS dst-address=::/0 gateway=pptp-out-syd3-adsl gateway-status=pptp-out-syd3-adsl reachable distance=1 scope=30 target-scope=10 3 DS dst-address=::/0 gateway=pptp-out-syd3-lte gateway-status=pptp-out-syd3-lte reachable distance=1 scope=30 target-scope=10 Yep, the distances are ALL 1. So it's ignoring the default distance in use on the PPTP and PPPOE interfaces entirely. Am I missing something? I guess I could remove the 'Add Default Route' tickbox on each session, and manually enter default routes? But surely the Default Route Distance should be applying to V6 as well? At the worst, can I just turn OFF V6 on the PPTP-LTE session? V6 won't work with ADSL down, since it's using TID-assigned V6 space at the moment. This is a CRS-109-8G-1S-2HnD on 6.30.2. 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

2 5

Working with 3/4G.
by Daniel Hoffman 01 Aug '15

01 Aug '15

I have just had to put a hap lite in to be a client to a Vodafone 4g wifi modem and bring that connection back into my network via Ethernet. All works really well but wondering if anyone has any experience with firewall rulesets and or application filtering to block big data use such as MS/Apple updates, apple iCloud backups etc etc. I've been thinking about just some big IP range drops for the big companies such as Apple and MS and AWS but thought maybe there is a better way. Anyone.

3 2

Re: [MT-AU Public] Public Digest, Vol 17, Issue 10
by Kevin Scott 28 Jul '15

28 Jul '15

Hey there, It is my experience that anything cable provided is prone to excessive congestion and also IP Address changes at a whim - it is considered to be a residential service after all. Congestion will cause slowness to the internet and that is purely and simply due to the amount of people using the same cable in the street or area. Remember it is just one cable from the pole going to every location in the street or neighbourhood so it is very prone to congested periods no matter what you do at the clients end. In the past, I have copied the Mac of the first device that connects to the Cable Modem and used that in the Router, or I would log into the cable modem and address the advanced settings to resolve the issues of 1 x Mac connection only or get rid of the modem completely if I can and use a better model. Perhaps using Dynamic DNS would assist you in your endeavours if you need to address the Mikrotik Router. Just my 2 cents worth. Regards, Kevin Scott SCOTTS IP Ph: (03) 9008-5696 Fx: (03) 9008-5686 Mb: 0419-650-550 Web: www.scottsip.com.au ---------------------------------------------------------------------------------------------------------------- This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. ---------------------------------------------------------------------------------------------------------------- On 28/07/2015 12:00 PM, public-request(a)talk.mikrotik.com.au wrote: > Send Public mailing list submissions to > public(a)talk.mikrotik.com.au > > To subscribe or unsubscribe via the World Wide Web, visit > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au > > or, via email, send a message with subject or body 'help' to > public-request(a)talk.mikrotik.com.au > > You can reach the person managing the list at > public-owner(a)talk.mikrotik.com.au > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Public digest..." > > > Today's Topics: > > 1. Cable Modem DHCP Issues (Ben Jackson) > 2. Re: Cable Modem DHCP Issues (Paul Julian) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 28 Jul 2015 10:53:10 +1000 > From: Ben Jackson <ben(a)elogik.net> > To: MikroTik Australia Public List <public(a)talk.mikrotik.com.au> > Subject: [MT-AU Public] Cable Modem DHCP Issues > Message-ID: > <CACv=4uox=iLAVoMx_qQ7+if1VPSJ2r9orvvXwzK=wDrjHEjkvA(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi All, > > I'm hoping someone can help me as I'm at my wit's end with this one. > > We use Mikrotik gear (Mainly RB2011's and and more recently, the > CRS125-24G) in large residential AV situations where invariably, the > Mikrotik is in dhcp client mode, in a cable internet scenario where > Telstra's / Optus's modem has been placed into "bridge" mode (NAT switched > off) and the carrier-supplied WAN IP address gets bound to the gateway > interface of the Mikrotik. > > The Mikrotik, in turn is connected to, on average, about 3 UniFi access > points, and at least 3-4 zones of Sonos. On initial set up, everything > seems to work great, with the full bandwidth of the cable modem getting > passed on to the rest of the network, even when 802.11 clients are > connected (a testament to the UniFi's I my opinion - I only use dual band > Pro AP's). > > However, after a week or so the internet connection seems to get either > very slow, or stop working altogether. If I look in the logs (with dhcp > logging switched on) I can see regular NAK's getting passed from the dhcp > server on the cable modem. The problem is I don't really understand how > DHCP works on cable modems. I'm assuming every so often the cable modem > gets a new IP address from the carrier (normally after a reset) and at this > point the modem is not passing this new address onto the Mikrotik which is > effectively cut off from the internet. Since we are stuck with using > Bigpond and Optus modems these are the only solutions I have discovered > which seem to stop the issue from occurring (at least as regularly). > > 1) Leave the cable modem in "router" mode and switch off all extraneous > services such as Wi-Fi, and also put one IP address in the dhcp pool so > that the Mikrotik always gets the same private IP address. However, this > creates a double nat situation which means I can no longer perform reliable > port forwarding for things such as DVR's and CBus controllers (which I find > the Mikrotik's great for). > > 2) Allow the cable modem to perform all dhcp, routing, port forwarding > (which is a joke on these devices) and firewall tasks for the entire LAN > and turn the CRS into an unmanaged L2 switch. The main problem here is that > these Bigpond devices simply do not have the grunt to deal with large > networks with lots of AV streaming and control happening. > > Since both of the above have severe drawbacks in terms of functionality, I > wonder if anyone has had similar experiences as I am just about ready to > dump the MikroTik's and start looking at other options in the hope that > they play better with the Bigpond gear. > > Thanks in advance, > > > Ben Jackson > eLogik > m:0404 924745 > e: ben(a)elogik.net > w: www.elogik.com.au > [image: http://www.elogik.com.au] <http://www.elogik.com.au> > > > ------------------------------ > > Message: 2 > Date: Tue, 28 Jul 2015 11:11:01 +1000 > From: Paul Julian <paul(a)oxygennetworks.com.au> > To: 'MikroTik Australia Public List' <public(a)talk.mikrotik.com.au> > Subject: Re: [MT-AU Public] Cable Modem DHCP Issues > Message-ID: > <c7a5c37b-7d25-4bbe-9f2e-2ae88ae61963(a)oxygennetworks.com.au> > Content-Type: text/plain; charset="us-ascii" > > Hey Ben, the only thing I can think of is that Telstra and Optus Cable networks use MAC based DHCP, they bind the IP to the MAC of the NTU or in the case of bridge mode the first client that makes a request, and often you have trouble with these things because of this, I don't really think it's a Mikrotik thing. > > However, as long as the Mikrotik is maintaining the same MAC on the interface plugged into the NTU and the NTU is truly in bridge mode and the Mikrotik is the only thing plugged into the NTU I can't see why it would be having issues. > > Is there any chance that another device might somehow be getting a DHCP request through to the NTU somehow the way you have it all plugged in ? > > Regards > Paul > > -----Original Message----- > From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Ben Jackson > Sent: Tuesday, 28 July 2015 10:53 AM > To: MikroTik Australia Public List > Subject: [MT-AU Public] Cable Modem DHCP Issues > > Hi All, > > I'm hoping someone can help me as I'm at my wit's end with this one. > > We use Mikrotik gear (Mainly RB2011's and and more recently, the > CRS125-24G) in large residential AV situations where invariably, the Mikrotik is in dhcp client mode, in a cable internet scenario where Telstra's / Optus's modem has been placed into "bridge" mode (NAT switched > off) and the carrier-supplied WAN IP address gets bound to the gateway interface of the Mikrotik. > > The Mikrotik, in turn is connected to, on average, about 3 UniFi access points, and at least 3-4 zones of Sonos. On initial set up, everything seems to work great, with the full bandwidth of the cable modem getting passed on to the rest of the network, even when 802.11 clients are connected (a testament to the UniFi's I my opinion - I only use dual band Pro AP's). > > However, after a week or so the internet connection seems to get either very slow, or stop working altogether. If I look in the logs (with dhcp logging switched on) I can see regular NAK's getting passed from the dhcp server on the cable modem. The problem is I don't really understand how DHCP works on cable modems. I'm assuming every so often the cable modem gets a new IP address from the carrier (normally after a reset) and at this point the modem is not passing this new address onto the Mikrotik which is effectively cut off from the internet. Since we are stuck with using Bigpond and Optus modems these are the only solutions I have discovered which seem to stop the issue from occurring (at least as regularly). > > 1) Leave the cable modem in "router" mode and switch off all extraneous services such as Wi-Fi, and also put one IP address in the dhcp pool so that the Mikrotik always gets the same private IP address. However, this creates a double nat situation which means I can no longer perform reliable port forwarding for things such as DVR's and CBus controllers (which I find the Mikrotik's great for). > > 2) Allow the cable modem to perform all dhcp, routing, port forwarding (which is a joke on these devices) and firewall tasks for the entire LAN and turn the CRS into an unmanaged L2 switch. The main problem here is that these Bigpond devices simply do not have the grunt to deal with large networks with lots of AV streaming and control happening. > > Since both of the above have severe drawbacks in terms of functionality, I wonder if anyone has had similar experiences as I am just about ready to dump the MikroTik's and start looking at other options in the hope that they play better with the Bigpond gear. > > Thanks in advance, > > > Ben Jackson > eLogik > m:0404 924745 > e: ben(a)elogik.net > w: www.elogik.com.au > [image: http://www.elogik.com.au] <http://www.elogik.com.au> _______________________________________________ > Public mailing list > Public(a)talk.mikrotik.com.au > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Public mailing list > Public(a)talk.mikrotik.com.au > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au > > > ------------------------------ > > End of Public Digest, Vol 17, Issue 10 > **************************************

2 2

Fwd: Seamless roaming
by Jason Hecker (Up & Running Tech) 20 Jul '15

20 Jul '15

Hi Mike, It must be a device operating system issue where the Wifi driver signals a link break of some kind to the TCPIP stack. One thing I have wondered but don't know the answer to, if a client switches AP's even on the same SSID is a DHCP request made at re-connection? I suppose the answer is yes - the client would reset all IP connections as the network settings *may* change with a new DHCP request. This is how a trick like keeping the AP MAC the same as a client roams would stop devices closing their connections as no new DHCP request is made. One thing to try would be to run OpenVPN on the sensitive clients. My limited experience in the past shows you can break and make your ethernet or ADSL connection and OpenVPN will resume any connections it's encapsulating like nothing happened. So, OpenVPN client paired with a Mikrotik OpenVPN server and set as the default route would ensure a client like Facetime or SIP VoIP would still keep running as the hullabaloo of switching AP's would be abstracted away from the client application and it won't drop the connection. Jason On 20 July 2015 at 00:40, Mike Everest <mike(a)duxtel.com> wrote: > Hi Jason! > > Unfortunately, what you are seeing is the transport layer timing out the > connection before the wifi has managed to re-negotiate the link. Since this > is a client behaviour setting, there is nothing that can be done about it > at > the network infrastructure end, only at the client side AND server side. > It > may be possible to get some relief from this problem by increasing tcp > time-out on the client - e.g: > > https://www.google.com.au/?q=tcp%20increase%20timeout > > Since either client or server can potentially time-out the session, even a > change to client time-out may not help at all if the server is the end > responsible for terminating the connection :-/ > > I had some correspondence with MikroTik software development team about > CAPsMAN system before it was released, and there was some indication there > about implementing some kind of managed hand-off between managed devices. > That kind of feature will allow the target AP to take control of the > session > by masquerading the MAC address of the original AP which should result in a > truly seamless roaming experience similar to the 3G/lte behaviour. > > There has been no official work of potential release of such that I am > aware > of, so when (or IF) this will be released is a matter of pure speculation > :-} > > 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: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of > > Jason Hecker (Up & Running Tech) > > Sent: Saturday, 18 July 2015 9:12 AM > > To: MikroTik Australia Public List > > Subject: [MT-AU Public] Seamless roaming > > > > I have here at home two Mikrotik devices set up with WIFI. > > > > Each has: > > * The same SSID. > > * RSTP bridging with WIFI andf Eth as members. > > * Access list with the cutoff signal below -80. > > > > The access list works well and it's easy to see the devices hop from one > > access point to the other instead of the device holding with a vice grip > to the > > original but very weaker signal which is what would normally happen. > > > > The issue is that Facetime drops when this access point transition > occurs. > > > > On client sites with multiple radios I haven't used something like > Facetime to > > check signal transitions rather just wandered about with the laptop > reloading > > web pages or playing Youtube videos with no discernible problems. > > > > Is there anything I can do to mitigate the fickleness of Facetime and > > presumably other real time applications like Skype and SIP VoIP when > > switching access points? > > > > Jason > > _______________________________________________ > > Public mailing list > > Public(a)talk.mikrotik.com.au > > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au > > -- --

3 2

Seamless roaming
by Jason Hecker (Up & Running Tech) 19 Jul '15

19 Jul '15

I have here at home two Mikrotik devices set up with WIFI. Each has: * The same SSID. * RSTP bridging with WIFI andf Eth as members. * Access list with the cutoff signal below -80. The access list works well and it's easy to see the devices hop from one access point to the other instead of the device holding with a vice grip to the original but very weaker signal which is what would normally happen. The issue is that Facetime drops when this access point transition occurs. On client sites with multiple radios I haven't used something like Facetime to check signal transitions rather just wandered about with the laptop reloading web pages or playing Youtube videos with no discernible problems. Is there anything I can do to mitigate the fickleness of Facetime and presumably other real time applications like Skype and SIP VoIP when switching access points? Jason

4 4

Leap Second NTP bug?
by Kyle J. Hunter 02 Jul '15

02 Jul '15

Hey all, Just had a bunch of my CCRs crashing within a few minutes of each other around 10:00am, the only ones which didn’t crash were ones not running NTP. Just curious if this has happened to anyone else today or for people not on a CCR? Kyle.

10 18

ccr1036
by Alex Samad - Yieldbroker 30 Jun '15

30 Jun '15

Hi Wondering if people have played with /queue> interface print detail On their phy interfaces ? Mine is set to only-hardware-queue, wondering why we are not using multi-queue-ethernet-default ? Alex

3 8

ANZ MikroTik User Meetings
by Mike Everest 29 Jun '15

29 Jun '15

Hi Guys, It's been a bit quiet here lately, so thought I'd send a brief post to everyone ;) I received an update from Janis @ MikroTik the other day reporting attendances at the recent MUM events in Melbourne and Wellington. Melbourne was attended by 162 people - that's numbers through the door :) Compared to 105 in Sydney (2013) and 126 in Brisbane (2011) that's an excellent turn-out! The presentations were top calibre, and I reckon that the event ran quite smoothly! There was some excellent detail in the "RouterOS developments" presentation by Janis Megis (MikroTik software engineer)which is well worth watching/reviewing in case you missed it. There is a full video of the Wellington event here: https://www.youtube.com/watch?v=ML0tr-9zTw0 Melbourne event (plus individual presentations from NZ) will be available on the MikroTik channel 'soon' here: http://tiktube.com/ Cheers! Mike.

1 1

ccr1036-8g watchdog timer
by Alex Samad - Yieldbroker 23 Jun '15

23 Jun '15

Hi I had one of my ccr's dye last night, just locked up, very annoying had just finished dinner ! /system watchdog> print watch-address: none watchdog-timer: yes no-ping-delay: 5m automatic-supout: yes auto-send-supout: no why didn't this kick in ? I'm not watching an address but I do have the timer on ? should have I expected this to have auto restarted. When I got to the box the touch wasn't working !

2 3

MikroTik User Meeting
by Mike Everest 20 May '15

20 May '15

Hi folks, Only three more sleeps until the MUM event in Melbourne! I have a few full registration entry vouchers left over - if you'd like one, YELL NOW! :-D Regards, Mike Everest www.duxtel.com.au 138 Station Street, Norlane Victoria, 3214, AUSTRALIA 1300-DUXTEL (+61-3-5273-4905) ____________________________________________________________________________ ___ Wholesale Distributor for MikroTik and RouterBoard in Australia and Pacific Region ISP and WISP Solutions - Hardware, Software, Training, Engineering and Support All things MikroTik - http://shop.duxtel.com.au ____________________________________________________________________________ ___ Follow our tweets for news and updates: http://twitter.com/duxtel

3 4