Issue:
PPTP/SSTP - could not add bridge port - BCP not working
Description:
BCP for SSTP and PPTP does not work, if a client with a bridge configured attemts to connect, he can not. Errors in logs stay “could not add bridge port”
Versions affected:
6.7, 6.6
How to reproduce:
Connect 2 RBs on ether 5.
Apply config for AC:
/interface pptp-server
add name=pptp-in1 user=pptp
/interface sstp-server
add name=sstp-in1 user=pptp
/interface bridge
add name=br_ppp
/ppp profile
add bridge=br_ppp local-address=2.2.2.1 name=pptp remote-address=2.2.2.2
/interface bridge port
add bridge=br_ppp interface=ether3
/interface pptp-server server
set default-profile=pptp enabled=yes keepalive-timeout=5
/interface sstp-server server
set default-profile=pptp enabled=yes keepalive-timeout=5 max-mru=1450 max-mtu=1450
/ip address
add address=1.1.1.1/24 interface=ether5 network=1.1.1.0
/ppp secret
add name=pptp password=pptp profile=pptp
/system identity
set name=SSTP_ACApply configs for client:
/interface bridge
add name=br_ppp
/ppp profile
add bridge=br_ppp name=pptp
/interface sstp-client
add connect-to=1.1.1.1 keepalive-timeout=5 name=sstp-out1 password=pptp profile=pptp user=pptp verify-server-address-from-certificate=no
/interface pptp-client
add connect-to=1.1.1.1 keepalive-timeout=5 name=pptp-out1 password=pptp profile=pptp user=pptp
/interface bridge port
add bridge=br_ppp interface=ether3
/ip address
add address=1.1.1.2/24 interface=ether5 network=1.1.1.0
/system identity
set name=SSTP_ClientPPTP and SSTP can not connect. Errors in log regarding “could not add bridge port”
Notes:
If you disable the static binding on the AC, sometimes the client connects, and sometimes the same error occurs in the logs on the client.
Issue:
L2TP Server bug - replies from wrong IP address
Description:
When a router has multiple IP addresses on an interface, an L2TP server always uses the lowest IP address as the source address of L2TP packets, which makes the L2TP connection impossible to establish.
Versions affected:
6.14-6.0, 5.x
How to reproduce:
Connect 2 RB’s on ether5. Apply configs:
L2TP AC:
/interface l2tp-server server
set enabled=yes
/ip address
add address=10.0.0.1/24 interface=ether5 network=10.0.0.0
add address=1.1.1.1/32 interface=ether5 network=1.1.1.1
/ip firewall mangle
add action=log chain=input port=1701 protocol=udp
add action=log chain=output port=1701 protocol=udp
/ppp secret
add name=123 password=123
/system identity
set name=ACL2TP client:
/interface l2tp-client
add connect-to=1.1.1.1 name=l2tp-out1 password=123 user=123
/ip address
add address=10.0.0.2/24 interface=ether5 network=10.0.0.0
/ip route
add distance=1 gateway=10.0.0.1
/system identity
set name=ClientL2TP will not establish. Looking at the logs will show that the L2TP server replies with a wrong IP address:
Notes:
This is really annoying, especially if you have a public IP which the clients use to connect to the L2TP server on a loopback.
The lowest IP address of the incoming interface will still be used, instead of the public IP on the loopback, making the L2TP AC not work.
You can use NAT as a workaround.
/ip firewall nat
add action=dst-nat chain=dstnat comment=“Fix for an L2TP src-address bug” dst-address=“Address you want your L2TP client to connect to”
dst-port=1701 protocol=udp to-addresses="src-address that L2TP sends wrong packets with"Support TicketID:
Ticket#2013020866000414
It could be specific to only the 2 USB modems I tested, however even if the modems are rebooted with usb-power-reset, the issue continues. (however, after a routerboard reboot, they work)
Also, a few other people in the forum reported problems.
A bit more info can be found here: http://forum.mikrotik.com/t/gsm-error-unable-to-load-unread-sms-timeout/71268/1 (and my last post in that topic) or in the support ticket mentioned in the post in this topic.
Duplicate address-list entries (same list name and same address or address range) are causing a crash. Avoid making 2 identical entries, or write to support for v6.8rc1 pre-release version with the fix.
Thanks for your support, and keep sending emails to support if you find any problems.
Issue:
Only a single IPsec VPN client (road warrior) can connect from behind the same NAT.
Description:
Only a single IPsec client can connect to a given RouterOS based VPN concentrator from behind the same NAT device. Even though RouterOS has ‘nat-traversal’ option in ‘/ip ipsec peer’ configuration, all this option does is it allows using ESP over UDP encapsulation mode. It seems that either IPsec policy processor does not take the client’s UDP port number into account, or dynamic policy generator does not put client’s UDP port number into the policy it generates, and thus RouterOS can not distinguish between two remote IPsec peers that are behind the same NAT device.
This type of configuration is standardized, is known to work on devices of different vendors, and is thus expected to be supported by the RouterOS as well.
Versions affected:
Tested with 6.6 and 6.7.
Support TicketID:
Ticket#2013120266000273.
Support replied on Dec 10, 2013 that “This setup is not possible with Road Warrior configuration, the router is unable to distinguish clients behind the same NAT.”
Sadly, this is not a bug, but rather a missing feature. Its hard to classify it as a bug, since its missing functionality, rather then something that should work, but doesnt.
You could even set generate-policy=port-strict or create a policy yourself with level=unique and it would still not work with multiple peers behind a single NAT.
MikroTik knows this doesnt work, hopefully the feature will be added.
Anyhow, people should know that IPsec NAT-T support is incomplete (or even broken) on RouterOS. To my knowledge, it has not been documented/mentioned anywhere till now. And for me it also means there’s currently not a single viable mobile VPN option available on RouterOS, despite all the new and exciting IPsec features introduced in RouterOS v6. Sad.
I agree its a pain that its not working. As soon as we have a client that has multiple IPSec clients at the same location, we deploy a router and build a S2S tunnel, thats how we get over this particular problem.
Normis (or any other MikroTik staff), if you are reading this, should this be added into the list of known issues and considered a known issue?
Or is this a missing feature that should be requested in the feature request topic?
I need this feature mostly for our employees who travel a lot and often need to access our office network during their business trips. If several travelers are staying in the same hotel at the same time, chances are they are behind the same NAT, and that’s a huge problem. And, unfortunately, S2S is not a solution in this case at all.
Well, I have ASA5505 which handles similar scenarios just fine at the moment. Being able to use Mikrotik for similar tasks is very desirable, but does not seem to be possible, unfortunately.
dynamic address-list or static address-list? it would be terrible for me to upgrade to v6.7 if the bug also meant for dynamic address-list, because i have port knock filter rules, which keeps re-adding dynamic address-list to keep alive an open connection.