Hello Folks!
I followed these two documents:
https://wiki.mikrotik.com/wiki/Manual:I ... entication
https://wiki.mikrotik.com/wiki/Manual:I ... figuration
We boiled them down to the following setup:
XXX.XXX.XXX.XXX = the public ip address of mikrotik router.
/certificate
add common-name=ca name=ca
sign ca ca-crl-host=XXX.XXX.XXX.XXX
add common-name=XXX.XXX.XXX.XXX subject-alt-name=IP:XXX.XXX.XXX.XXX key-usage=tls-server name=server1
sign server1 ca=ca
/ip pool
add name=rw-pool ranges=10.10.30.16-10.10.30.128
/ip ipsec policy
set 0 level=unique dst-address=10.10.30.0/24
/ip ipsec mode-conf
add name=cfg1 system-dns=yes address-pool=rw-pool address-prefix=32
/ip ipsec peer
add auth-method=rsa-signature certificate=server1 generate-policy=port-strict mode-config=cfg1 passive=yes remote-certificate=none exchange-mode=ike2
/certificate
add common-name=Windows_client name=Windows_client
sign Windows_client ca=ca
export-certificate Windows_client export-passphrase=XXXXXXXXXXX type=pkcs12
The mikrotik router is connected directly to a few other subnets, 172.16.1.129/24 and 192.168.2.40/24 and internet via the public XXX.XXX.XXX.XXX.
The router is classically configured to nat traffic from 172.16.1.0/24 to internet, a simple firewall is configured and port 500, 4500 is opened plus some more needed.
The windows 10 client successfully imports the exported certificates, and after configuring the IKEv2 vpn tunnel the described way in mikrotik documentation, the windows 10 client successfully connects and gets it 10.10.30.xxx ip address, in a blink.
Now the problems arrives, the windows 10 client can not ping or connect to any server in 172.16.1.0/24 nor 192.168.2.0/24, yet they are directly connected.
If I configure a bridge device in the mikrotik router and add an ip address in 10.10.30.0/24 network I can ping it and connect to the mikrotik router using that subnet. So tunnel seem to work so far.
I worked before, and yes there have been some mikrotik updates since I did this in January/February 2018, but must have missed something, do anyone know what is missing ?
Thank you in advance!
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
Can you post the export of yourI worked before, and yes there have been some mikrotik updates since I did this in January/February 2018, but must have missed something, do anyone know what is missing ?
Code: Select all
/ip firewall natRe: RoadWarrior IKEv2 Windows 10 OK but "no ping"
/ip firewall natCan you post the export of yourI worked before, and yes there have been some mikrotik updates since I did this in January/February 2018, but must have missed something, do anyone know what is missing ?rules?Code: Select all/ip firewall nat
add action=src-nat chain=srcnat comment="vm1 IIS" log-prefix=rev-proxy-return out-interface=vlan112 src-address=172.16.1.130 to-addresses=\
XXX.XXX.XXX.XXX
add action=dst-nat chain=dstnat comment="vm1 IIS" dst-address=XXX.XXX.XXX.XXX dst-port=80 in-interface=vlan112 log-prefix=http-req \
protocol=tcp to-addresses=172.16.1.130 to-ports=80
add action=dst-nat chain=dstnat comment="vm1 IIS" dst-address=XXX.XXX.XXX.XXX dst-port=443 in-interface=vlan112 log-prefix=https-req \
protocol=tcp to-addresses=172.16.1.130 to-ports=443
The verbose variant:
/ip firewall nat
add action=src-nat chain=srcnat comment="vm1 IIS" !connection-bytes !connection-limit !connection-mark !connection-rate !connection-type \
!content disabled=no !dscp !dst-address !dst-address-list !dst-address-type !dst-limit !dst-port !fragment !hotspot !icmp-options \
!in-bridge-port !in-bridge-port-list !in-interface !in-interface-list !ingress-priority !ipsec-policy !ipv4-options !layer7-protocol \
!limit log=no log-prefix=rev-proxy-return !nth !out-bridge-port !out-bridge-port-list out-interface=vlan112 !out-interface-list \
!packet-mark !packet-size !per-connection-classifier !port !priority !protocol !psd !random !routing-mark !routing-table src-address=\
172.16.1.130 !src-address-list !src-address-type !src-mac-address !src-port !tcp-mss !time !tls-host to-addresses=XXX.XXX.XXX.XXX \
!to-ports !ttl
add action=dst-nat chain=dstnat comment="vm1 IIS" !connection-bytes !connection-limit !connection-mark !connection-rate !connection-type \
!content disabled=no !dscp dst-address=XXX.XXX.XXX.XXX !dst-address-list !dst-address-type !dst-limit dst-port=80 !fragment !hotspot \
!icmp-options !in-bridge-port !in-bridge-port-list in-interface=vlan112 !in-interface-list !ingress-priority !ipsec-policy \
!ipv4-options !layer7-protocol !limit log=no log-prefix=http-req !nth !out-bridge-port !out-bridge-port-list !out-interface \
!out-interface-list !packet-mark !packet-size !per-connection-classifier !port !priority protocol=tcp !psd !random !routing-mark \
!routing-table !src-address !src-address-list !src-address-type !src-mac-address !src-port !tcp-mss !time !tls-host to-addresses=\
172.16.1.130 to-ports=80 !ttl
add action=dst-nat chain=dstnat comment="vm1 IIS" !connection-bytes !connection-limit !connection-mark !connection-rate !connection-type \
!content disabled=no !dscp dst-address=XXX.XXX.XXX.XXX !dst-address-list !dst-address-type !dst-limit dst-port=443 !fragment !hotspot \
!icmp-options !in-bridge-port !in-bridge-port-list in-interface=vlan112 !in-interface-list !ingress-priority !ipsec-policy \
!ipv4-options !layer7-protocol !limit log=no log-prefix=https-req !nth !out-bridge-port !out-bridge-port-list !out-interface \
!out-interface-list !packet-mark !packet-size !per-connection-classifier !port !priority protocol=tcp !psd !random !routing-mark \
!routing-table !src-address !src-address-list !src-address-type !src-mac-address !src-port !tcp-mss !time !tls-host to-addresses=\
172.16.1.130 to-ports=443 !ttl
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
Is that all? You've written that you have several subnets there, and you only src-nat packets sent from a single source address. Does that mean that none of the devices in your LANs has access to internet or that they do not access internet via this Mikrotik but via some other path?Can you post the export of yourI worked before, and yes there have been some mikrotik updates since I did this in January/February 2018, but must have missed something, do anyone know what is missing ?rules?Code: Select all/ip firewall natCode: Select all/ip firewall nat add action=src-nat chain=srcnat comment="vm1 IIS" log-prefix=rev-proxy-return out-interface=vlan112 src-address=172.16.1.130 to-addresses=\ XXX.XXX.XXX.XXX add action=dst-nat chain=dstnat comment="vm1 IIS" dst-address=XXX.XXX.XXX.XXX dst-port=80 in-interface=vlan112 log-prefix=http-req \ protocol=tcp to-addresses=172.16.1.130 to-ports=80 add action=dst-nat chain=dstnat comment="vm1 IIS" dst-address=XXX.XXX.XXX.XXX dst-port=443 in-interface=vlan112 log-prefix=https-req \ protocol=tcp to-addresses=172.16.1.130 to-ports=443
While the WIndows machine is connected, how does
Code: Select all
/ip ipsec policy printRe: RoadWarrior IKEv2 Windows 10 OK but "no ping"
Yes that is all there is.Is that all? You've written that you have several subnets there, and you only src-nat packets sent from a single source address. Does that mean that none of the devices in your LANs has access to internet or that they do not access internet via this Mikrotik but via some other path?Can you post the export of yourI worked before, and yes there have been some mikrotik updates since I did this in January/February 2018, but must have missed something, do anyone know what is missing ?rules?Code: Select all/ip firewall natCode: Select all/ip firewall nat add action=src-nat chain=srcnat comment="vm1 IIS" log-prefix=rev-proxy-return out-interface=vlan112 src-address=172.16.1.130 to-addresses=\ XXX.XXX.XXX.XXX add action=dst-nat chain=dstnat comment="vm1 IIS" dst-address=XXX.XXX.XXX.XXX dst-port=80 in-interface=vlan112 log-prefix=http-req \ protocol=tcp to-addresses=172.16.1.130 to-ports=80 add action=dst-nat chain=dstnat comment="vm1 IIS" dst-address=XXX.XXX.XXX.XXX dst-port=443 in-interface=vlan112 log-prefix=https-req \ protocol=tcp to-addresses=172.16.1.130 to-ports=443
While the WIndows machine is connected, how doeslook like (replace public IPs with x.x.x.x)?Code: Select all/ip ipsec policy print
Correct, all devices in subnet 172.16.1.0/24 and 192.168.2.0/24, except the reverse proxy 172.16.1.130, routes all traffic to other mikrotik devices.
Only 172.16.1.130 uses this mikrotik device as default gateway(172.16.1.129).
Here is how it looks like while the windows 10 client is connected:
[admin@MikroTik] > ip ipsec policy print
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default
0 T * group=default src-address=0.0.0.0/0 dst-address=10.10.30.0/24 protocol=all proposal=default template=yes
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
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
In that case, do all the other devices have a route to 10.10.30.0/24 pointing to this Mikrotik on which the IKEv2 is running? As you say that 172.16.1.0/24 and 192.168.2.0/24 are local subnets of this Mikrotik but the defaut routes of devices in these subnets are other Mikrotiks, then how do the devices know that for 10.10.30.0/24, they should use this Mikrotik exceptionally?Correct, all devices in subnet 172.16.1.0/24 and 192.168.2.0/24, except the reverse proxy 172.16.1.130, routes all traffic to other mikrotik devices.
Only 172.16.1.130 uses this mikrotik device as default gateway(172.16.1.129).
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
Okey that it could be, they do not know that off course , I will add a route to 10.10.30.0/24 in the other mikrotik devices and we will see what happens.In that case, do all the other devices have a route to 10.10.30.0/24 pointing to this Mikrotik on which the IKEv2 is running? As you say that 172.16.1.0/24 and 192.168.2.0/24 are local subnets of this Mikrotik but the defaut routes of devices in these subnets are other Mikrotiks, then how do the devices know that for 10.10.30.0/24, they should use this Mikrotik exceptionally?Correct, all devices in subnet 172.16.1.0/24 and 192.168.2.0/24, except the reverse proxy 172.16.1.130, routes all traffic to other mikrotik devices.
Only 172.16.1.130 uses this mikrotik device as default gateway(172.16.1.129).
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
Okey that it could be, they do not know that off course , I will add a route to 10.10.30.0/24 in the other mikrotik devices and we will see what happens.In that case, do all the other devices have a route to 10.10.30.0/24 pointing to this Mikrotik on which the IKEv2 is running? As you say that 172.16.1.0/24 and 192.168.2.0/24 are local subnets of this Mikrotik but the defaut routes of devices in these subnets are other Mikrotiks, then how do the devices know that for 10.10.30.0/24, they should use this Mikrotik exceptionally?Correct, all devices in subnet 172.16.1.0/24 and 192.168.2.0/24, except the reverse proxy 172.16.1.130, routes all traffic to other mikrotik devices.
Only 172.16.1.130 uses this mikrotik device as default gateway(172.16.1.129).
I begun adding a toute to 10.10.30.0/24 to 172.16.1.129 in the reverse proxy (microsoft Server 2016) with ip address 172.16.1.130, because it had 10.0.0.0/8 pointing to another router. But it did not work, it is eventually because the new route (10.10.30.0/24) ended up after 10.0.0.0/8. I will investigate how to change the order in the routing table, if possible.
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.16.1.129 172.16.1.130 276
10.0.0.0 255.0.0.0 172.16.1.1 172.16.1.130 21
10.10.30.0 255.255.255.0 172.16.1.129 172.16.1.130 21
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
172.0.0.0 255.0.0.0 172.16.1.1 172.16.1.130 21
172.16.1.0 255.255.255.0 On-link 172.16.1.130 276
172.16.1.130 255.255.255.255 On-link 172.16.1.130 276
172.16.1.255 255.255.255.255 On-link 172.16.1.130 276
192.0.0.0 255.0.0.0 172.16.1.1 172.16.1.130 21
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 172.16.1.130 276
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 172.16.1.130 276
===========================================================================
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
I'm afraid it is not the reason. If you have a look, 0.0.0.0/0 is "before" the 10.0.0.0/8 and still doesn't override it. The route table is always searched through for best match, i.e. longest mask, regardless the order of the items and regardless the metric value - the metric value is only important when several routes with the same mask length match.Okey that it could be, they do not know that off course , I will add a route to 10.10.30.0/24 in the other mikrotik devices and we will see what happens.In that case, do all the other devices have a route to 10.10.30.0/24 pointing to this Mikrotik on which the IKEv2 is running? As you say that 172.16.1.0/24 and 192.168.2.0/24 are local subnets of this Mikrotik but the defaut routes of devices in these subnets are other Mikrotiks, then how do the devices know that for 10.10.30.0/24, they should use this Mikrotik exceptionally?Correct, all devices in subnet 172.16.1.0/24 and 192.168.2.0/24, except the reverse proxy 172.16.1.130, routes all traffic to other mikrotik devices.
Only 172.16.1.130 uses this mikrotik device as default gateway(172.16.1.129).
I begun adding a toute to 10.10.30.0/24 to 172.16.1.129 in the reverse proxy (microsoft Server 2016) with ip address 172.16.1.130, because it had 10.0.0.0/8 pointing to another router. But it did not work, it is eventually because the new route (10.10.30.0/24) ended up after 10.0.0.0/8. I will investigate how to change the order in the routing table, if possible.
However, you've chosen for the test the only device for which the src-nat rule in this Mikrotik exists, which may interfere with the IPsec policy operation. Please try to do the following:
Code: Select all
/ip firewall nat
add action=accept chain=srcnat comment="exception from src-nat for the proxy" out-interface=vlan112 src-address=172.16.1.130 dst-address=10.10.30.0/24 place-before=0
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
It did not work either...I'm afraid it is not the reason. If you have a look, 0.0.0.0/0 is "before" the 10.0.0.0/8 and still doesn't override it. The route table is always searched through for best match, i.e. longest mask, regardless the order of the items and regardless the metric value - the metric value is only important when several routes with the same mask length match.Okey that it could be, they do not know that off course , I will add a route to 10.10.30.0/24 in the other mikrotik devices and we will see what happens.In that case, do all the other devices have a route to 10.10.30.0/24 pointing to this Mikrotik on which the IKEv2 is running? As you say that 172.16.1.0/24 and 192.168.2.0/24 are local subnets of this Mikrotik but the defaut routes of devices in these subnets are other Mikrotiks, then how do the devices know that for 10.10.30.0/24, they should use this Mikrotik exceptionally?Correct, all devices in subnet 172.16.1.0/24 and 192.168.2.0/24, except the reverse proxy 172.16.1.130, routes all traffic to other mikrotik devices.
Only 172.16.1.130 uses this mikrotik device as default gateway(172.16.1.129).
I begun adding a toute to 10.10.30.0/24 to 172.16.1.129 in the reverse proxy (microsoft Server 2016) with ip address 172.16.1.130, because it had 10.0.0.0/8 pointing to another router. But it did not work, it is eventually because the new route (10.10.30.0/24) ended up after 10.0.0.0/8. I will investigate how to change the order in the routing table, if possible.
However, you've chosen for the test the only device for which the src-nat rule in this Mikrotik exists, which may interfere with the IPsec policy operation. Please try to do the following:and check whether you can reach the 172.16.1.130 from the VPN client when this additional rule exists.Code: Select all/ip firewall nat add action=accept chain=srcnat comment="exception from src-nat for the proxy" out-interface=vlan112 src-address=172.16.1.130 dst-address=10.10.30.0/24 place-before=0
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
If Microsoft firewall is active on a device, it does not respond to pings. Can this be the reason?It did not work either...
If not, let's try a brute force approach - choose some device and tell it that the Mikrotik acting as VPN server is its default gateway.
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
It is a default installed microsoft server with firewall opened for standard ports whilst adding the roles like rdp, iis, and we can login to it using remote desktop from elsewhere, except the ikev2 vpn tunnel, and yes, the firewall stops ping.If Microsoft firewall is active on a device, it does not respond to pings. Can this be the reason?It did not work either...
If not, let's try a brute force approach - choose some device and tell it that the Mikrotik acting as VPN server is its default gateway.
Okey, the reverse proxy (windows server) has mikrotik vpn server as its default gateway.IPv4 Route Table.
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.16.1.129 172.16.1.130 276
10.0.0.0 255.0.0.0 172.16.1.1 172.16.1.130 21
10.10.30.0 255.255.255.0 172.16.1.129 172.16.1.130 21
--cut--
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
and? Has it made that server's RDP accessible via the VPN or not?Okey, the reverse proxy (windows server) has mikrotik vpn server as its default gateway.IPv4 Route Table.
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.16.1.129 172.16.1.130 276
10.0.0.0 255.0.0.0 172.16.1.1 172.16.1.130 21
10.10.30.0 255.255.255.0 172.16.1.129 172.16.1.130 21
--cut--
What do
Code: Select all
/ip firewall nat printCode: Select all
/ip firewall nat print statsRe: RoadWarrior IKEv2 Windows 10 OK but "no ping"
Nope, it is not reachable via vpn.and? Has it made that server's RDP accessible via the VPN or not?Okey, the reverse proxy (windows server) has mikrotik vpn server as its default gateway.IPv4 Route Table.
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.16.1.129 172.16.1.130 276
10.0.0.0 255.0.0.0 172.16.1.1 172.16.1.130 21
10.10.30.0 255.255.255.0 172.16.1.129 172.16.1.130 21
--cut--
What doandCode: Select all/ip firewall nat printshow?Code: Select all/ip firewall nat print stats
[admin@MikroTik] > ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; exception from src-nat for the proxy
chain=srcnat action=accept
src-address=172.16.1.130
dst-address=10.10.30.0/24
out-interface=vlan112 log=no log-prefix=""
1 ;;; vm1 IIS
chain=srcnat action=src-nat
to-addresses=X.x.x.x
src-address=172.16.1.130
out-interface=vlan112 log=no
log-prefix="rev-proxy-return"
2 ;;; vm1 IIS
chain=dstnat action=dst-nat
to-addresses=172.16.1.130 to-ports=80
protocol=tcp dst-address=X.x.x.x
in-interface=vlan112 dst-port=80 log=no
log-prefix="http-req"
3 ;;; vm1 IIS
chain=dstnat action=dst-nat
to-addresses=172.16.1.130 to-ports=443
protocol=tcp dst-address=X.x.x.x
in-interface=vlan112 dst-port=443 log=no
log-prefix="https-req"
[admin@MikroTik] > ip firewall nat print stats
Flags: X - disabled, I - invalid, D - dynamic
# CHAIN ACTION
0 ;;; exception from src-nat for the proxy
srcnat accept
1 ;;; vm1 IIS
srcnat src-nat
2 ;;; vm1 IIS
dstnat dst-nat
3 ;;; vm1 IIS
dstnat dst-nat
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
The most important columns (bytes, packets matched) are missing.[admin@MikroTik] > ip firewall nat print stats
Flags: X - disabled, I - invalid, D - dynamic
# CHAIN ACTION
0 ;;; exception from src-nat for the proxy
srcnat accept
1 ;;; vm1 IIS
srcnat src-nat
2 ;;; vm1 IIS
dstnat dst-nat
3 ;;; vm1 IIS
dstnat dst-nat
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
Sorry, trying againThe most important columns (bytes, packets matched) are missing.[admin@MikroTik] > ip firewall nat print stats
Flags: X - disabled, I - invalid, D - dynamic
# CHAIN ACTION
0 ;;; exception from src-nat for the proxy
srcnat accept
1 ;;; vm1 IIS
srcnat src-nat
2 ;;; vm1 IIS
dstnat dst-nat
3 ;;; vm1 IIS
dstnat dst-nat
[admin@MikroTik] > ip firewall nat print stats
Flags: X - disabled, I - invalid, D - dynamic
# CHAIN ACTION BYTES PACKETS
0 ;;; exception from src-nat for the proxy
srcnat accept 0 0
1 ;;; vm1 IIS
srcnat src-nat 70 412 1 136
2 ;;; vm1 IIS
dstnat dst-nat 17 516 339
3 ;;; vm1 IIS
dstnat dst-nat 4 592 111
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
Okay, so the packets from the 172.16.1.130 were not routed via vlan112, so the src-nat on them was not the issue.Sorry, trying againThe most important columns (bytes, packets matched) are missing.[admin@MikroTik] > ip firewall nat print stats
Flags: X - disabled, I - invalid, D - dynamic
# CHAIN ACTION
0 ;;; exception from src-nat for the proxy
srcnat accept
1 ;;; vm1 IIS
srcnat src-nat
2 ;;; vm1 IIS
dstnat dst-nat
3 ;;; vm1 IIS
dstnat dst-nat
[admin@MikroTik] > ip firewall nat print stats
Flags: X - disabled, I - invalid, D - dynamic
# CHAIN ACTION BYTES PACKETS
0 ;;; exception from src-nat for the proxy
srcnat accept 0 0
1 ;;; vm1 IIS
srcnat src-nat 70 412 1 136
2 ;;; vm1 IIS
dstnat dst-nat 17 516 339
3 ;;; vm1 IIS
dstnat dst-nat 4 592 111
If you add a rule
Code: Select all
/ip firewall filter add chain=forward dst-address=10.10.30.0/24 action=passthroughRe: RoadWarrior IKEv2 Windows 10 OK but "no ping"
Still no joy, neither is there any bytes or packets on the forward chain rule or the nat rule.Okay, so the packets from the 172.16.1.130 were not routed via vlan112, so the src-nat on them was not the issue.Sorry, trying againThe most important columns (bytes, packets matched) are missing.[admin@MikroTik] > ip firewall nat print stats
Flags: X - disabled, I - invalid, D - dynamic
# CHAIN ACTION
0 ;;; exception from src-nat for the proxy
srcnat accept
1 ;;; vm1 IIS
srcnat src-nat
2 ;;; vm1 IIS
dstnat dst-nat
3 ;;; vm1 IIS
dstnat dst-nat
[admin@MikroTik] > ip firewall nat print stats
Flags: X - disabled, I - invalid, D - dynamic
# CHAIN ACTION BYTES PACKETS
0 ;;; exception from src-nat for the proxy
srcnat accept 0 0
1 ;;; vm1 IIS
srcnat src-nat 70 412 1 136
2 ;;; vm1 IIS
dstnat dst-nat 17 516 339
3 ;;; vm1 IIS
dstnat dst-nat 4 592 111
If you add a ruleabove all the rules in this chain and try the RDP to the proxy, will this rule's counters show any packets? If yes, the response packets from the proxy do come, otherwise they don't.Code: Select all/ip firewall filter add chain=forward dst-address=10.10.30.0/24 action=passthrough
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
Ok, so try to place that rule to chain prerouting of table mangle and check again.Still no joy, neither is there any bytes or packets on the forward chain rule or the nat rule.
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
No joy, neither is there any bytes or packages counted up.Ok, so try to place that rule to chain prerouting of table mangle and check again.Still no joy, neither is there any bytes or packets on the forward chain rule or the nat rule.
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
No joy, neither is there any bytes or packages counted up.
Code: Select all
/ip firewall filter exportI have a suspicion.
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
Here the firewall filter rules comes:No joy, neither is there any bytes or packages counted up., please.Code: Select all/ip firewall filter export
I have a suspicion.
/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 ?
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
Here the firewall filter rules comes:No joy, neither is there any bytes or packages counted up., please.Code: Select all/ip firewall filter export
I have a suspicion.
/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.
To verify it still work I removed the bridge and bridge ip address 10.10.30.130, also the nat and mangle rule and the firewall forward rule.
And it still works, just you manually add that route in the windows 10 client.
That raises the question, why has windows 10 not added the routes or what is missing in the magics ?
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
Why are these two rules disabled?Here the firewall filter rules comes:
/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
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
Code: Select all
action=acceptCode: Select all
ipsec-policy=in,ipsecThe above should be done in
Code: Select all
/ip firewall filter chain=inputCode: Select all
/ip firewall filter chain=forwardThe magics should have been in theThen 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:
Code: Select allIPv4 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 ?
Code: Select all
/ip ipsec mode-configCode: Select all
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=1AFAIK 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:
Code: Select all
/ip ipsec mode-config set [find name=cfg1] split-include=10.0.0.0/8,172.16.0.0/12Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
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.
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
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.
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.
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
Having no idea what happens under the hood of Windows, I can only suggest you to use theThe 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.
Code: Select all
netmapRe: RoadWarrior IKEv2 Windows 10 OK but "no ping"
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:
It's one time operation and will be remembered for future use.
Code: Select all
Add-VpnConnectionRoute -ConnectionName "<connection name>" -DestinationPrefix <remote subnet>/<mask> -PassThruRe: RoadWarrior IKEv2 Windows 10 OK but "no ping"
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.
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.
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
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:
viewtopic.php?t=124988
https://docs.microsoft.com/en-us/window ... pn-routing
https://social.technet.microsoft.com/Fo ... networking
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.
1. 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
2. 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....
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:
viewtopic.php?t=124988
https://docs.microsoft.com/en-us/window ... pn-routing
https://social.technet.microsoft.com/Fo ... networking
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.
1. 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
2. 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....
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
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.
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.
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
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.
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.
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
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.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.
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.
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
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.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.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.
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.
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
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.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.
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 (
Code: Select all
/system logging set [find topics=ipsec] topics=ipsec,!packetRe: RoadWarrior IKEv2 Windows 10 OK but "no ping"
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.
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.
Re: RoadWarrior IKEv2 Windows 10 OK but "no ping"
OK, I was too brief, I try that from time to time and it always causes more bad than goodCode: Select allipsec,error no proposal chosen
What I had in mind was whether this
Code: Select all
ipsec,error no propsal chosenRe: RoadWarrior IKEv2 Windows 10 OK but "no ping"
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]
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]