|
SamDabbers posted:When I upgraded to 6.0 final from rc14, IPv6 conntrack stopped working. That is, none of the rules would create state and everything was hitting the default drop rules. I sent a detailed writeup of the problem (a bug report, really) with a supout file to support@mikrotik.com, and it took over a week for someone to respond with a link to a pre-release build of 6.1 and "no, you're wrong; it works fine." Oh, so you're the other guy who reported that. quote:Hello, He was polite enough to give me the 6.1-rc1 link (which did solve it).
|
#
¿
Jun 14, 2013 11:07
|
|
|
|
| # ¿ Apr 27, 2024 09:50 |
|
|
For what it's worth, the PPTP client is horribly broken for me too and has been since who-even-knows and nobody else seems to recognize that there's a problem, as usual. I can just about get straight text TCP sessions to start, SSL just stalls forever. This is to OctaneVPN, the same servers work swimmingly with the built-in PPTP/IPsec clients in Mac OS X so I can't really blame the servers. Meanwhile, the router can't use IPsec because there isn't a complete XAUTH implementation for the client (more specifically it can't receive IP config data for dynamic addressing using whatever that extension's named, so it's useless for that purpose), which means OpenVPN is the only thing that works, except Mikrotik's client is slow as hell, tcp-only for that lovely tcp-in-tcp negative feedback resonance, and officially recognized as broken (which is why they refuse to extend it.) But at least it connects and doesn't drop 99% of all packets or whatever is going on; so I just run three and split the tcp sessions by ip/port hash.  All that gives me oh, 60% of the performance a straight tcp+ssl stream of the same number of sessions even though the VPN GW lives practically in the same datacenter as the endpoint server. :mikrotik:
|
|
#
¿
Aug 5, 2013 22:26
|
|
|
Okay, what the poo poo. I had futzed around with that for hours before, and made sure to enable the built-in MSS workaround on the PPP profile (which forces 1280 I think, and creates two dynamic rules) - and its rules were being hit for sure. Except apparently not taking effect. Now I set the interface MTU/MRU to 1440 (IIRC the GRE packet overhead is in that range, correct me if I'm wrong!) and the MSS clamp to 1240 because whatever, apparently making a good optimal guess at this is impossible; and now I actually get throughput (so thanks!), but it's really bouncing around with a lot of little stall gaps, and readouts jumping wildly between 3-8Mbps. My connection is capable of way more than that, and I see at least 50% more with the horrible triple-ovpn setup active, even though it draws three times as much CPU and is TCP-encapsulated instead of sorta-dumb datagrams like PPTP (I hear it doesn't deal with reordering at all, which is pretty much uuuh? territory) CPU profiling showing 60-70% idle, so there should be room for more there. And guess what? I had already added mangle rules to bypass my cool QoS scheduling (because double-counting is bad - you can tell when this is going on because your queues will show 2x the actual throughput), I have a cool stateful connection-tagging setup overall. But because iptables is objectively the worst firewall on the face of the planet, the connection tagging randomly vanishes, and the hellaciously terrible connection tracking just loses track of the GRE session. It might as well not exist, it sure doesn't show up in the 'connections' tab nor does it match any rules. Adding a stupid rule to catch all packets of protocol 47 does work (but is bad because then it's going deep into the rule stack instead of being headed off at the first five or so by a "connection-state: established" rule), and adding a rule that matches "connection-state: related" also matches even though the state-tracking doesn't know about the packets  And it it still doesn't show up in the connections list even just filtering for protocol 47. I hate computers, and I double-immelman-with-a-rosette hate loving anything that comes within a parsec of the Linux networking stack.  Well, thanks for trying, it did sort of help. Slightly. :mikrotik:
|
|
#
¿
Aug 5, 2013 23:57
|
|
|
On the other hand, you can (supposedly) host Cisco-style-compatible basic incoming VPN since routeros 6.0, it's its client that's hosed. The IPsec itself is probably solid. Or if you're willing to gently caress around painfully on the client side you could always set up ISAKMP style IPsec, and that's been the case since forever.
|
|
#
¿
Aug 7, 2013 12:39
|
|
|
IPsec was symmetric right until Cisco got its grubby hands on it and redefined everything. For that matter, it is exactly as hosed as 802.11x is. Good luck getting one authentication method to work across all clients unless it's TLS client certificates, and maybe not even that. Roaming as in trying to keep a continuous connection across IP changes with unclean tunnel shutdown? Yeah, probably "good luck with that." Maybe L2TP could do it in one-connection-per-user-only mode, assuming it actually closes the old ones with that on, haven't tested. Wolf on Air fucked around with this message at 17:58 on Aug 8, 2013 |
|
#
¿
Aug 8, 2013 17:55
|
|
|
Hi, thread. RouterOS 6.4 breaks WinBox input forms randomly. That is all.
|
|
#
¿
Sep 13, 2013 15:16
|
|
|
My old Soekris net5501 with a 500MHz AMD Geode is hitting the CPU limits at around 130Mbps aggregate bandwidth on my new glorious 100/100 home connection. My firewall/QoS ruleset is way too heavy for it  It's lasted me since 2007! Wolf on Air fucked around with this message at 15:51 on Sep 14, 2013 |
|
#
¿
Sep 14, 2013 15:45
|
|
|
|
| # ¿ Apr 27, 2024 09:50 |
|
|
I recently heard from a friend who has a CRS that they couldn't get VLAN poo poo working on it properly at all (leaking traffic all over), and after a while Mikrotik support told him that they hadn't actually gotten around to implementing all the parts in the backend that are exposed in the UI, so what happens is, the function for not forwarding prohibited traffic (or whatever he meant, I'm not actually sure) to all VLANs is working, but not the associating-ports-with-VLANs part, so if you do that, you're going to lose all connectivity. Typical Mikrotik behaviour.
|
|
#
¿
Jan 14, 2014 22:35
|
|