RoadWarrior IKEv2 Windows 10 OK but "no ping"

RouterOS General
1

Hello Folks!

I followed these two documents:

https://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Road_Warrior_setup_using_IKEv2_with_RSA_authentication
https://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Windows_client_configuration

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!

2

Can you post the export of your ****

/ip firewall nat

rules?

3

/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

4

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?

While the WIndows machine is connected, how does ****

/ip ipsec policy print

look like (replace public IPs with x.x.x.x)?

5

Yes that is all there is.
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

6

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?

7

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.

8
9

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.

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:

/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

and check whether you can reach the 172.16.1.130 from the VPN client when this additional rule exists.

10

It did not work either…

11

If Microsoft firewall is active on a device, it does not respond to pings. Can this be the reason?
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.

12

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.

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–

13

and? Has it made that server’s RDP accessible via the VPN or not?
What do ****

/ip firewall nat print

and

/ip firewall nat print stats

show?

14

Nope, it is not reachable via vpn.

[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

15

The most important columns (bytes, packets matched) are missing.

16

Sorry, trying again
[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

17

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.

If you add a rule ****

/ip firewall filter add chain=forward dst-address=10.10.30.0/24 action=passthrough

above 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.

18

Still no joy, neither is there any bytes or packets on the forward chain rule or the nat rule.

19

Ok, so try to place that rule to chain prerouting of table mangle and check again.

20

No joy, neither is there any bytes or packages counted up.