/ip firewall filter export
, please.
I have a suspicion.
Here the firewall filter rules comes:
/ip firewall filter
add action=add-src-to-address-list address-list=port-scanners address-list-timeout=10m chain=input comment="Port scanners to list"
protocol=tcp psd=21,3s,3,1 src-address-list=!niceones
add action=add-src-to-address-list address-list=port-scanners address-list-timeout=10m chain=input comment="NMAP FIN Stealth scan"
protocol=tcp psd=21,3s,3,1 src-address-list=!niceones tcp-flags=fin,!syn,!rst,!psh,!ack,!urg
add action=add-src-to-address-list address-list=port-scanners address-list-timeout=10m chain=input comment="SYN/FIN scan" protocol=
tcp psd=21,3s,3,1 src-address-list=!niceones tcp-flags=fin,syn
add action=add-src-to-address-list address-list=port-scanners address-list-timeout=10m chain=input comment="SYN/RST scan" psd=
21,3s,3,1 src-address-list=!niceones tcp-flags=""
add action=add-src-to-address-list address-list=port-scanners address-list-timeout=10m chain=input comment="FIN/PSH/URG scan"
protocol=tcp psd=21,3s,3,1 src-address-list=!niceones tcp-flags=fin,psh,urg,!syn,!rst,!ack
add action=add-src-to-address-list address-list=port-scanners address-list-timeout=10m chain=input comment="ALL/ALL scan" protocol=
tcp psd=21,3s,3,1 src-address-list=!niceones tcp-flags=fin,syn,rst,psh,ack,urg
add action=add-src-to-address-list address-list=port-scanners address-list-timeout=10m chain=input comment="NMAP NULL scan"
protocol=tcp psd=21,3s,3,1 src-address-list=!niceones tcp-flags=!fin,!syn,!rst,!psh,!ack,!urg
add action=drop chain=input comment="Port Scanners" in-interface=vlan112 src-address-list=port-scanners
add action=passthrough chain=forward dst-address=10.10.30.0/24
add action=jump chain=forward comment="ANY spammer drop" connection-state=new jump-target=block-ddos src-address-list=!niceones
add action=drop chain=forward connection-state=new dst-address-list=ddosed src-address-list=ddoser
add action=return chain=block-ddos dst-limit=50,50,src-and-dst-addresses/10s
add action=add-dst-to-address-list address-list=ddosed address-list-timeout=1d chain=block-ddos
add action=add-src-to-address-list address-list=ddoser address-list-timeout=1d chain=block-ddos
add action=accept chain=input protocol=ipsec-esp
add action=accept chain=input protocol=ipsec-ah
add action=accept chain=forward disabled=yes dst-address=0.0.0.0/0 src-address=10.10.30.0/24
add action=accept chain=forward disabled=yes dst-address=10.10.30.0/24 src-address=0.0.0.0/0
add action=accept chain=input comment=dns dst-port=53 protocol=udp src-address-list=niceones
add action=accept chain=input comment=dns dst-port=53 protocol=tcp src-address-list=niceones
add action=accept chain=input comment=mail dst-port=25 protocol=tcp src-address-list=niceones
add action=log chain=input comment="ssh, winbox, web" disabled=yes dst-port=80,443,999,8291 in-interface=vlan112 protocol=tcp
add action=accept chain=input comment="ssh, winbox, web" dst-port=80,443,999,8291 in-interface=vlan112 protocol=tcp
add action=accept chain=input comment="l2tp, winbox-mac" dst-port=500,1701,4500,5678 in-interface=vlan112 protocol=udp
add action=accept chain=input disabled=yes log=yes log-prefix=niceones src-address-list=niceones
add action=accept chain=input comment="default configuration ping" protocol=icmp src-address-list=niceones
add action=accept chain=input comment="default configuration established" connection-state=established in-interface=vlan112
log-prefix=established
add action=accept chain=input comment="default configuration related" connection-state=related in-interface=vlan112
add action=log chain=input comment="default configuration" disabled=yes in-interface=vlan112 log-prefix="firewall drop"
add action=drop chain=input comment="default configuration" in-interface=vlan112
Then I made a discovery on the windows 10 client side !
I added a bridge in the vpn router and added to it ip address 10.10.30.130,
I could ping it from the windows 10 client with the connected vpn tunnel.
Still on windows 10 client I tried to ping the vpn router ip address 172.16.1.129, it failed off course, like before.
After that I went back to the windows 10 client, checking routes:
IPv4 Route Table
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.211.55.1 10.211.55.3 25
10.0.0.0 255.0.0.0 On-link 10.10.30.124 26
10.10.30.124 255.255.255.255 On-link 10.10.30.124 281
10.211.55.0 255.255.255.0 On-link 10.211.55.3 281
10.211.55.3 255.255.255.255 On-link 10.211.55.3 281
10.211.55.255 255.255.255.255 On-link 10.211.55.3 281
10.255.255.255 255.255.255.255 On-link 10.10.30.124 281
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
169.254.0.0 255.255.0.0 On-link 169.254.229.67 281
169.254.229.67 255.255.255.255 On-link 169.254.229.67 281
169.254.255.255 255.255.255.255 On-link 169.254.229.67 281
194.218.206.131 255.255.255.255 10.211.55.1 10.211.55.3 26
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 169.254.229.67 281
224.0.0.0 240.0.0.0 On-link 10.211.55.3 281
224.0.0.0 240.0.0.0 On-link 10.10.30.124 281
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 169.254.229.67 281
255.255.255.255 255.255.255.255 On-link 10.211.55.3 281
255.255.255.255 255.255.255.255 On-link 10.10.30.124 281
If there is not any IP magics engaged I can not see that the windows 10 client has any route telling where 172.16.1.0/24 is.
So I as user admin added routes in the windows 10 client:
c:> route add 172.16.1.0 mask 255.255.255.0 10.10.30.124
c:> ping 172.16.1.129
Pinging 172.16.1.129 with 32 bytes of data:
Reply from 172.16.1.129: bytes=32 time=63ms TTL=64
Reply from 172.16.1.129: bytes=32 time=75ms TTL=64
Reply from 172.16.1.129: bytes=32 time=74ms TTL=64
Reply from 172.16.1.129: bytes=32 time=61ms TTL=64
Ping statistics for 172.16.1.129:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 61ms, Maximum = 75ms, Average = 68ms
Now remote desktop to 172.16.1.130, 172.16.1.132 and so on now works as they should.
Bringing down the vpn tunnel also clears the routing table, bringing it up and you have to add routes to 172.16.1.0/24 as admin to make it work.
That raises the question, why has windows 10 not added the routes or what is missing in the magics ?
Why are these two rules disabled?
The point is that the packet decrypted and de-encapsulated from an IPsec packet is seen by the firewall as coming in via the interface through which the IPsec transport packet carrying it came in. So unless you make an ****
action=accept
exception for packets coming in through vlan112 for packets with
ipsec-policy=in,ipsec
(which is not the same like permitting ipsec-esp and ipsec-ah), you have to accept them based on their IP addresses. Otherwise it should not work even with your added route.
The above should be done in ****
/ip firewall filter chain=input
to get to the Mikrotik itself and in
/ip firewall filter chain=forward
to get to other devices.
Then I made a discovery on the windows 10 client side !
I added a bridge in the vpn router and added to it ip address 10.10.30.130,
I could ping it from the windows 10 client with the connected vpn tunnel.
Still on windows 10 client I tried to ping the vpn router ip address 172.16.1.129, it failed off course, like before.After that I went back to the windows 10 client, checking routes:
IPv4 Route Table
Active Routes:
Network Destination Netmask Gateway Interface Metric
10.0.0.0 255.0.0.0 On-link 10.10.30.124 26
10.10.30.124 255.255.255.255 On-link 10.10.30.124 281
10.255.255.255 255.255.255.255 On-link 10.10.30.124 281
224.0.0.0 240.0.0.0 On-link 10.10.30.124 281
255.255.255.255 255.255.255.255 On-link 10.10.30.124 281
>
> If there is not any IP magics engaged I can not see that the windows 10 client has any route telling where 172.16.1.0/24 is.
>
> That raises the question, why has windows 10 not added the routes or what is missing in the magics ?
The magics should have been in the ****
```text
/ip ipsec mode-config
part, which is used to tell the client what IPsec policy to use. Your generated policy suggests that it worked:
1 DA src-address=0.0.0.0/0 src-port=any dst-address=10.10.30.126/32 dst-port=any protocol=all action=encrypt level=unique
ipsec-protocols=esp tunnel=yes sa-src-address=XXX.XXX.XXX.XXX sa-dst-address=YYY.YYY.YYY.YYY proposal=default ph2-count=1
AFAIK this policy at server side is not generated from the mode-config directly locally but is requested by the client as a mirror of its local policy which is based on the received mode-config. So the fact that src-address in the server-side policy is 0.0.0.0/0 would indicate that the Windows machine has understood the mode-config properly. Nevertheless, the Windows machine has not transformed the policy into its local routing table properly, creating only a route for 10.0.0.0/8, not for 0.0.0.0/0 suggested by the mode-config (implicitly, by absence of a list of subnets to be made available using individual policies).
If you feel like that, you may try to modify your mode-config the following way:
/ip ipsec mode-config set [find name=cfg1] split-include=10.0.0.0/8,172.16.0.0/12
But it is just a theory, it may actually get worse (even the 10.0.0.0/8 you can now see in the routing table of the Windows client may be missing after the change).
VPN and routes are notorious PITA. It seems like almost everyone expects VPN clients to route all their traffic through remote server. If you do that, everything is fine. But when you want to reach only few remote subnets and use own default gw for the rest, the trouble begins. Even though some options for routes exists in different protocols, the state of interoperability is really sad. I’m still looking for automatic and reliable solution for RouterOS ↔ Windows VPN, and haven’t found anything that would completely satisfy me.
The thread become long.
The two firewall rules I first added but they did not make any difference so I disabled them during all tests here and there.
/ip firewall filter
…
add action=accept chain=forward disabled=yes dst-address=0.0.0.0/0 src-address=10.10.30.0/24
add action=accept chain=forward disabled=yes dst-address=10.10.30.0/24 src-address=0.0.0.0/0
I had the two submets in the mode-config from the beginning, but it did not make any differences, also mikrotik write in documentation windows does ignore the setttings.
I realise this windows support vary, on server 2016 it worked perfectly, windows 10 does not.
Having no idea what happens under the hood of Windows, I can only suggest you to use the ****
netmap
flavour of NAT to make 172.16.1.0/24 and 192.168.2.0/24 subnets visible to the Windows clients as 10.x.x.0/24 and 10.y.y.0/24, with all the notorious issues of NAT of course.
Or if the config is going to be static, i.e. you won’t change the subnets on server side, you can manually add routes on client side (Windows 10, not older) with:
Add-VpnConnectionRoute -ConnectionName "<connection name>" -DestinationPrefix <remote subnet>/<mask> -PassThru
It’s one time operation and will be remembered for future use.
Big thanks for all of you having pation to engage you so much in my tedious VPN problems, this was worth much!
Thanks for the powershell oneliner and all hints and tips, leading to something that works at least partly.
Our developers will write some code, connected to AD and some vpn role, that will automatically generate the necessary certificates and provide to our users.
We think about some small program with embedded certificate that users will execute that will install the certificate and add the routes if needed, when needed.
So far we managed get mikrotik IKEv2 road warrior VPN working for:
server 2016 out of the box, no hacks, just to follow MT instruction and you are home, end users can handle it.
windows 10, need some hacking, manually adding routes to subnets in the windows 10 client, could be handled by power user.
macOS High Sierra, need lots of hacking including installing some obscure “mac configurator”, no comments.
IOS, not working and have not been investigated why.
Android, not yet tested.
We really want to be able replacing our Cisco VPN solution, which works for almost all platforms without bigger hassle, to the level that endusers easily can handle it.
I will do some more tests and add the results of them here and also present the full solution so others can follow it as well.
Hello Again!
Here comes some more.
Indeed vpn tunnels on Windows 10 is a long story, Microsoft confess various bugs and so on, read their tech forums. Nowhere is a clear simple way getting it working.
Here are some links for the one who likes to read more about it:
http://forum.mikrotik.com/t/split-tunnel-in-vpn-remote-access/111674/1
https://docs.microsoft.com/en-us/windows/security/identity-protection/vpn/vpn-routing
https://social.technet.microsoft.com/Forums/windows/en-US/c7c97883-8ad3-4d62-adbc-911953d4e258/unable-to-run-powershell-command-for-adding-vpn-with-tunnel-type-ikev2?forum=win10itpronetworking
I want to keep it simple and as much standard as possible.
The IPSEC mode-config in mikrotik router with split routes did work with windows 10 no matter the settings, so I left them empty till further.
I added back:
/ip firewall filter
add action=accept chain=forward disabled=no dst-address=0.0.0.0/0 src-address=10.10.30.0/24
add action=accept chain=forward disabled=no dst-address=10.10.30.0/24 src-address=0.0.0.0/0
On windows 10 client side I setup the ikev2 tunnel per mikrotik instruction. As I understand it, one could add the whole ikev2 tunnel in powershell, but I have not figured that out yet.
- Then I have a few options, manually add routes to 172.16.1.0/24 and 192.168.2.0/24 or doing it via powershell(yet not tested).
or
- Change the properties on the “WAN Miniport (IKEv2)” -device → Network menu → Double click on TCP/IPv4 → click on Advanced → “Check Use standard gateway on the remote network” → OK
The first option I think is the better, because it does not affect any else routes.
The second option could lead to “undefined” traffic over the IKEv2 tunnel.
More to come…
Second option (VPN as default gateway) is easier, in Windows it seems to be default way that “just works”. But it’s not very practical in many cases. If as user I want to connect to more than one remote network at the same time (and I do), I can’t have them both as default gateway. I guess it might not be a problem for most users. But then there’s another one. If as admin I want users to access just few remote servers in company LAN from outside, I’m not interested in all their Youtube streaming and such getting routed though VPN. So the first option (only selected subnets routed through VPN) is almost always the right one for me.
But it’s easier said than done. Windows built-in VPN clients have three options what routes to add (everything, nothing, class-based). I don’t want everything, nothing is not useful either and class-based adds route to only one subnet, and e.g. 10.0.0.0/8 is also little too much. In theory, there are other options. Windows L2TP client should be able to get routes using DHCP (mentioned here), but RouterOS doesn’t support that. IKEv2 can set split networks, but Windows don’t care about that. Then there’s IPSec + modeconf, but it seems completely unsupported by Windows, unless you install third-party client. OpenVPN has support for pushing routes as standard feature, but MikroTik decided to not implement it in RouterOS. SSTP doesn’t seem to offer anything either.
So I don’t really see any simple & no compromises way how to have split tunnelling between RouterOS and Windows with everything controlled from server side.
Hello Folks!
So far all seems to work, off course the clients find it difficult to get their vpn tunnels working properly compared to cisco vpn solution that just works.
For some users I got lots of this in the log files:
19:28:27 ipsec,error no proposal chosen
As far I know, the tunnel works for the user, at least he told me so, but what is this and can it harm in some way, and how can I fix it ?
annoying to have in logs.
That sounds dangerous, not just annoying, to me to see this in the logs and still have the connection established for the users. I may be wrong but I’m afraid that it indicates that your L2TP server settings say “use-ipsec=yes” instead of “use-ipsec=required”, therefore the L2TP tunnel is established even though the IPsec transport securing it has failed to establish.
The softer explanation why the clients connect successfully although no proposal has been chosen could be that the client retries with a different proposal if the initial attempt has failed but that seems unlikely to me.
Hmm the l2tp server is disabled. I don’t get it the I connect my tunnel, so maybe there is something weird with one users windows vpn configuration, have to check that out.
Sorry, doing several times at a time is never good. I’ve forgotten that you don’t use L2TP/IPsec but plain IPsec so the L2TP catch came immediately to my mind. Ignore that idea.
In the light of another topic, I can suppose that the client may use several connection attempts with different proposals to prevent exceeding the server’s handling capacity by a single proposal containing too many encryption protocols. Excluding packet bytes from the debug (****
/system logging set [find topics=ipsec] topics=ipsec,!packet
) should give you a compact enough log to confirm this speculation.
ipsec,error no proposal chosen
One windows 10 client causes this an the user also experience frequent kick outs and has to dissconnect and connect again. It is unclear at time of writing if the user has missed something in the settings.
I have the same setup, with respekt to the other user might have missed something, in my case there is nothing in the logs at all.
OK, I was too brief, I try that from time to time and it always causes more bad than good 
What I had in mind was whether this ****
ipsec,error no propsal chosen
was systematically immediately followed by a successful attempt from the same client, indicating that the client uses several establihment attempts, each with a different proposal, in a row.
Hello Folks!
Here is what is in the log, when this user have the vpn up. User windows 10 vpn client configuration yet unknown. I will connect my vpn tunnel to and see what I got, at least I had no errors at all in my vpn logs. But this poor user has.
The only difference I am aware about is that this customer sit behind NAT-router of some kind with his windows 10 pro.
But I am also behind NAT, because I have my windows 10 home in a parallels virtual session which also natted to my mac-os host which is connected via mobile phone (natted again) or my NAT router.
I just touch and go today, so I have not had any time analyzing this properly yet.
17:10:21 system,info log rule added by admin
17:10:26 ipsec,debug ===== received 428 bytes from yyy.yyy.yyy.yyy[4500] to xxx.xxx.xxx.xxx[4500]
17:10:26 ipsec ike2 request, exchange: CREATE_CHILD_SA:c4 yyy.yyy.yyy.yyy[4500]
17:10:26 ipsec payload seen: ENC
17:10:26 ipsec processing payload: ENC
17:10:26 ipsec,debug => iv (size 0x8)
17:10:26 ipsec,debug b42b6c85 1b83e20c
17:10:26 ipsec,debug => plain payload (trimmed) (first 0x100 of 0x174)
17:10:26 ipsec,debug 280000c0 02000028 01030403 6a80b638 0300000c 0100000c 800e0100 03000008
17:10:26 ipsec,debug 03000002 00000008 05000000 02000028 02030403 6a80b638 0300000c 0100000c
17:10:26 ipsec,debug 800e0080 03000008 03000002 00000008 05000000 02000024 03030403 6a80b638
17:10:26 ipsec,debug 03000008 01000003 03000008 03000002 00000008 05000000 02000024 04030403
17:10:26 ipsec,debug 6a80b638 03000008 01000002 03000008 03000002 00000008 05000000 00000024
17:10:26 ipsec,debug 05030403 6a80b638 03000008 0100000b 03000008 03000002 00000008 05000000
17:10:26 ipsec,debug 2c000034 2796bffc 9ef50e23 dce701d1 c80dbb17 10a24ddf efe68607 6c9c16eb
17:10:26 ipsec,debug a3c3c8b6 7fab68e3 90579264 7db4a379 533f0498 2d000040 02000000 07000010
17:10:26 ipsec,debug decrypted
17:10:26 ipsec payload seen: SA
17:10:26 ipsec payload seen: NONCE
17:10:26 ipsec payload seen: TS_I
17:10:26 ipsec payload seen: TS_R
17:10:26 ipsec create child: respond
17:10:26 ipsec processing payload: NONCE
17:10:26 ipsec processing payloads: NOTIFY (none found)
17:10:26 ipsec processing payloads: NOTIFY (none found)
17:10:26 ipsec peer wants tunnel mode
17:10:26 ipsec processing payload: CONFIG (not found)
17:10:26 ipsec processing payload: TS_I
17:10:26 ipsec 0.0.0.0/0
17:10:26 ipsec [::/0]
17:10:26 ipsec processing payload: TS_R
17:10:26 ipsec 0.0.0.0/0
17:10:26 ipsec [::/0]
17:10:26 ipsec TSi in tunnel mode replaced with config address: 10.10.30.120
17:10:26 ipsec canditate selectors: 0.0.0.0/0 <=> 10.10.30.120
17:10:26 ipsec canditate selectors: [::/0] <=> [::/0]
17:10:26 ipsec processing payload: SA
17:10:26 ipsec IKE Protocol: ESP
17:10:26 ipsec proposal #1
17:10:26 ipsec enc: aes256-cbc
17:10:26 ipsec auth: sha1
17:10:26 ipsec proposal #2
17:10:26 ipsec enc: aes128-cbc
17:10:26 ipsec auth: sha1
17:10:26 ipsec proposal #3
17:10:26 ipsec enc: 3des-cbc
17:10:26 ipsec auth: sha1
17:10:26 ipsec proposal #4
17:10:26 ipsec enc: des-cbc
17:10:26 ipsec auth: sha1
17:10:26 ipsec proposal #5
17:10:26 ipsec enc: null
17:10:26 ipsec auth: sha1
17:10:26 ipsec searching for policy for selector: 0.0.0.0/0 <=> 10.10.30.120
17:10:26 ipsec generating policy
17:10:26 ipsec,error no proposal chosen
17:10:26 ipsec removing generated policy
17:10:26 ipsec adding payload: NOTIFY
17:10:26 ipsec notify: NO_PROPOSAL_CHOSEN
17:10:26 ipsec,debug ===== sending 92 bytes from xxx.xxx.xxx.xxx[4500] to yyy.yyy.yyy.yyy[4500]
17:10:26 ipsec,debug 1 times of 96 bytes message will be sent to yyy.yyy.yyy.yyy[4500]
17:10:33 ipsec,debug KA: xxx.xxx.xxx.xxx[4500]->yyy.yyy.yyy.yyy[4500]
17:10:33 ipsec,debug 1 times of 1 bytes message will be sent to yyy.yyy.yyy.yyy[4500]