Hello,
I have a brand new Mikrotik RB4011gs and latest RouterOS 6.48.1 behind my (W)ISP antenna/router in DMZ zone (unfortunately I can not manage directly PPPoE connection....negotiating about that) and with a public dynamic IP. There are no other devices connected to ISP router, and all the traffic is forwarded (DMZ) to Mikrotik ether1 WAN port.
Internet <-----> ISP Router <------> Mikrotik <-----> LAN(s)
I can setup an OpenVPN TCP server in Mikrotik (I know, not optimized and slow). However, I would like to have a IPSec IKEv2 or an L2TP/IPsec VPN server to access my lan remotely. I started with the tutorials here:
https://wiki.mikrotik.com/wiki/Manual:I ... entication
From logs, looks ipsec connects correctly, I can see the active peer connected, PH2 phase looks ok, SAs enstablishes, the Android device used for test acquires a correct IP from the VPN pool...but no traffic. Also, from firewall rules I can see packets on 500, 4500 ports but not on on ipsec-esp rule. The SA source address is the private IP of Mikrotik toward WAN port (ether1) connected to ISP router. SA dst. address is the public IP of the android phone. PH2 state enstablished, PH2 count = 1, Src address = 0.0.0.0\0 dst. address = the private address of android device within the pool
Do you have any suggestion? Is it possible in general to have IPSec server under double nat as above?
Thanks!
Re: IPsec IKEv2 Server for Road Warriors/Site to Site behind double NAT - rb4011 and OS6.48.1
Up. Does anybody tried already to have IPSec Ikev2 responder behind NAT?
Re: IPsec IKEv2 Server for Road Warriors/Site to Site behind double NAT - rb4011 and OS6.48.1
Yes, sure. The number of NATs doesn't matter (provided that all of them work properly).Is it possible in general to have IPSec server under double nat as above?
That is no surprise. If there is at least one NAT on the path between the peers, the ESP gets encapsulated into UDP, and the encapsulation (payload -> ESP -> UDP), as well as decapsulation in the reverse order, is done in a single step by the IPsec protocol stack, so the ESP packets are invisible to the firewall (unlike the UDP transport ones and the payload ones).from firewall rules I can see packets on 500, 4500 ports but not on on ipsec-esp rule.
I would say the reason is either firewall misconfiguration or something broken in 6.48.1. You mention Android as an initiator but you haven't explicitly specified that you use IKEv2. The src-address and dst-address of the policy suggest that you do, so do you run some recent Android version which supports IKEv2 natively or do you use a 3rd party VPN application, like Strongswan?Do you have any suggestion?
You also haven't shown any configuration export from the MIkrotik, see my automatic signature below for a micro-howto.
When you try to access some web page from the Android via the VPN, does /ip ipsec installed-sa print interval=1s show that the Android -> Mikrotik SA receives some packets? If it does, it is a firewall issue; if it doesn't, it may be a routing issue at Android side or the NAT detection may have failed. Do the src-address and dst-address of the installed SAs show only the public IP address of the Android device or also the port?
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
Re: IPsec IKEv2 Server for Road Warriors/Site to Site behind double NAT - rb4011 and OS6.48.1
Hello Sindy, thanks for your reply!
Here is the Mikrotik config exported (with some sensitive data removed )
I included also OpenVPN server configuration...that works perfectly.
I also tried to remove all the "drop" rules from firewall (so, no firewall :) ) with the same result...ports on the remote android side is also shown.
A question: the IKEv2 tunnel should create also a dynamic routing rule when establishes? (similar to the OpenVPN server....). Meanwhile when an openvpn connection sets I can see a routing dynamic rule on the list, I don't see the same for the IPSec IKEv2 connection...
Thanks!
I'm using native Android 10 IPSec IKEv2 support on Samsung S9+I would say the reason is either firewall misconfiguration or something broken in 6.48.1. You mention Android as an initiator but you haven't explicitly specified that you use IKEv2. The src-address and dst-address of the policy suggest that you do, so do you run some recent Android version which supports IKEv2 natively or do you use a 3rd party VPN application, like Strongswan?
Here is the Mikrotik config exported (with some sensitive data removed )
Code: Select all
# feb/15/2021 08:50:37 by RouterOS 6.48.1
# software id = xxxxxx
#
# model = RB4011iGS+
# serial number = xxxxxxxx
/interface bridge
add admin-mac=XX:XX:XX:XX:XX:XX auto-mac=no comment=defconf name=bridge
/interface ethernet
set [ find default-name=ether1 ] name=ether1-WAN
/interface ethernet switch port
set 0 default-vlan-id=0
set 1 default-vlan-id=0
set 2 default-vlan-id=0
set 3 default-vlan-id=0
set 4 default-vlan-id=0
set 5 default-vlan-id=0
set 6 default-vlan-id=0
set 7 default-vlan-id=0
set 8 default-vlan-id=0
set 9 default-vlan-id=0
set 10 default-vlan-id=0
set 11 default-vlan-id=0
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=xxxxxxxxx
/ip ipsec policy group
add name=ipsec-group
/ip ipsec profile
set [ find default=yes ] enc-algorithm=aes-256,aes-192,aes-128 hash-algorithm=\
sha256
add enc-algorithm=aes-256,aes-192,aes-128 name=ipsec-profile
/ip ipsec peer
add exchange-mode=ike2 local-address=192.168.0.253 name=user1 passive=yes \
profile=ipsec-profile send-initial-contact=no
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256,sha1 enc-algorithms=\
aes-256-cbc,aes-256-gcm,aes-192-cbc,aes-192-gcm,aes-128-cbc,aes-128-gcm \
lifetime=8h
add enc-algorithms="aes-256-cbc,aes-256-ctr,aes-256-gcm,aes-192-cbc,aes-192-ctr,\
aes-192-gcm,aes-128-cbc,aes-128-ctr,aes-128-gcm" lifetime=8h name=\
ipsec-proposal pfs-group=none
/ip pool
add name=dhcp ranges=192.168.178.2-192.168.178.254
add name=vpn-pool ranges=192.168.8.10-192.168.8.99
add name=ipsec-pool ranges=192.168.100.2-192.168.100.99
/ip dhcp-server
add address-pool=dhcp disabled=no interface=bridge lease-time=2h name=defconf
/ip ipsec mode-config
add address-pool=ipsec-pool address-prefix-length=32 name=ipsec-config \
split-include=0.0.0.0/0 system-dns=no
/ppp profile
set *0 use-ipv6=default
add dns-server=192.168.8.250 local-address=192.168.8.250 name=vpn-profile \
remote-address=vpn-pool use-compression=no use-encryption=required \
use-ipv6=default
/system logging action
set 0 memory-lines=10000
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=ether6
add bridge=bridge comment=defconf interface=ether7
add bridge=bridge comment=defconf interface=ether8
add bridge=bridge comment=defconf interface=ether9
add bridge=bridge comment=defconf interface=ether10
add bridge=bridge comment=defconf interface=sfp-sfpplus1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1-WAN list=WAN
/interface ovpn-server server
set auth=sha1 certificate=server-certificate cipher=aes192,aes256 \
default-profile=vpn-profile enabled=yes require-client-certificate=yes
/ip address
add address=192.168.178.1/24 comment=defconf interface=bridge network=\
192.168.178.0
add address=192.168.0.253/24 interface=ether1-WAN network=192.168.0.0
/ip cloud
set ddns-enabled=yes ddns-update-interval=5m
/ip dhcp-client
add comment=defconf interface=ether1-WAN
/ip dhcp-server network
add address=192.168.178.0/24 comment=defconf gateway=192.168.178.1 netmask=24
/ip firewall filter
add action=accept chain=input comment=\
"defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
"defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=accept chain=input comment="allow OpenVPN" dst-port=1194 protocol=\
tcp
add action=accept chain=input in-interface-list=dynamic protocol=tcp \
src-address=192.168.8.0/24
add action=accept chain=input comment="L2TP/IPSec rules" dst-port=500,4500 \
protocol=udp
add action=accept chain=input protocol=ipsec-esp
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
ipsec-policy=out,ipsec
add action=accept chain=forward comment=\
"defconf: accept established,related, untracked" connection-state=\
established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
invalid
add action=drop chain=forward comment="defconf: drop invalid" connection-state=\
invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" \
connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=!LAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
out-interface-list=WAN src-address=192.168.178.0/24
/ip ipsec identity
add generate-policy=port-strict mode-config=ipsec-config peer=user1 \
policy-template-group=ipsec-group remote-id=key-id:user1
/ip ipsec policy
add dst-address=192.168.100.0/24 group=ipsec-group proposal=ipsec-proposal \
src-address=0.0.0.0/0 template=yes
/ip ipsec settings
set accounting=no
/ip route
add distance=1 gateway=192.168.0.254
/ppp secret
add name=mobile profile=vpn-profile service=ovpn
/system clock
set time-zone-name=Europe/Rome
/system identity
set name=xxxxxxxxx
/system ntp client
set enabled=yes primary-ntp=108.61.73.243 secondary-ntp=138.68.201.49
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
Yes, I can see packets from Android to Mikrotik. But I can not see what is wrong on firewall...When you try to access some web page from the Android via the VPN, does /ip ipsec installed-sa print interval=1s show that the Android -> Mikrotik SA receives some packets? If it does, it is a firewall issue; if it doesn't, it may be a routing issue at Android side or the NAT detection may have failed. Do the src-address and dst-address of the installed SAs show only the public IP address of the Android device or also the port?
Code: Select all
> /ip ipsec installed-sa print interval=1
Flags: H - hw-aead, A - AH, E - ESP
0 HE spi=an hex number src-address=x.x.x.x:4255 dst-address=192.168.0.253:4500
state=mature enc-algorithm=aes-gcm enc-key-size=288
enc-key="something long :)"
addtime=feb/15/2021 09:06:21 expires-in=7h58m33s add-lifetime=6h24m/8h
current-bytes=47085 current-packets=228 replay=128
1 HE spi=another hex number src-address=192.168.0.253:4500 dst-address=x.x.x.x:4255
state=mature enc-algorithm=aes-gcm enc-key-size=288
enc-key="other boring long stuff :)"
add-lifetime=6h24m/8h replay=128
-- [Q quit|D dump|C-z pause]
A question: the IKEv2 tunnel should create also a dynamic routing rule when establishes? (similar to the OpenVPN server....). Meanwhile when an openvpn connection sets I can see a routing dynamic rule on the list, I don't see the same for the IPSec IKEv2 connection...
Thanks!
Re: IPsec IKEv2 Server for Road Warriors/Site to Site behind double NAT - rb4011 and OS6.48.1
Not really funny, the filth from the net may be incredibly fast to squat in (been there, seen that).I also tried to remove all the "drop" rules from firewall (so, no firewall :) )
Nope. With IPsec on Mikrotik, the traffic to be sent via an IPsec SA is chosen by traffic selectors, which override the result of the "normal" routing. So first a packet is routed using the normal routing, and if the result of the routing is that the packet should be sent out via some interface, its headers are matched against the traffic selectors of all existing IPsec policies; the first match eventually found diverts the packet to the SA associated to the respective policy.A question: the IKEv2 tunnel should create also a dynamic routing rule when establishes?
The actual issue is that your one and only action=masquerade rule is too selective: it matches on src-address=192.168.178.0/24, whereas the IPsec clients get their addresses from ipsec-pool with ranges=192.168.100.2-192.168.100.99. Hence the initial packet sent by the Android client to some public address does not get src-nated as the router forwards it to the internet, and therefore either your ISP drops it as an illegal one, or such packet does make it to the server but the server responds to 192.168.100.x and the response is routed according to its local routing for this address, so definitely not back to your router.
On the other hand, you have to exclude packets towards 192.168.100.2-192.168.100.99 (or 192.168.100.0/24 to make it simple) from being src-nated (or masqueraded, the difference between the two is not relevant here) if you want to be able to initiate connections to the IPsec client device acting as a server (i.e. to ping it). The NAT rules are only applied on the initial packet of each connection; the decision taken for the initial packet is stored in the context of the connection, and all subsequent packets of that connection are treated the same way (or inversely, depending on their direction).
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
Re: IPsec IKEv2 Server for Road Warriors/Site to Site behind double NAT - rb4011 and OS6.48.1
I tried to both relax masquerade rule for non IPSec traffic (no src-address specified) and also to set up a dedicated masquerade for the IPSec IP pool (similar to what shown here: https://mum.mikrotik.com/presentations/ ... 543676.pdf ). I can see traffic hitting the masquerade rule in the NAT, but no webpage or other traffic will pop up succefully on the Android client, and of course no ping to internal LAN. I played around with the configuration showed also in the PDF, without any luck:The actual issue is that your one and only action=masquerade rule is too selective: it matches on src-address=192.168.178.0/24, whereas the IPsec clients get their addresses from ipsec-pool with ranges=192.168.100.2-192.168.100.99. Hence the initial packet sent by the Android client to some public address does not get src-nated as the router forwards it to the internet, and therefore either your ISP drops it as an illegal one, or such packet does make it to the server but the server responds to 192.168.100.x and the response is routed according to its local routing for this address, so definitely not back to your router.
Code: Select all
/ip firewall filter
add action=accept chain=input comment=\
"defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=accept chain=forward comment=\
"defconf: accept established,related, untracked" connection-state=\
established,related,untracked
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
"defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=accept chain=input comment="allow OpenVPN" dst-port=1194 protocol=\
tcp
add action=accept chain=input in-interface-list=dynamic protocol=tcp \
src-address=192.168.8.0/24
add action=accept chain=input comment="L2TP/IPSec rules" dst-port=500,4500 \
protocol=udp
add action=accept chain=input protocol=ipsec-esp
add action=accept chain=input ipsec-policy=in,ipsec src-address=\
192.168.100.0/24
add action=accept chain=forward dst-address=192.168.178.0/24 ipsec-policy=\
in,ipsec src-address=192.168.100.0/24
add action=accept chain=forward dst-address=0.0.0.0/0 ipsec-policy=in,ipsec \
src-address=192.168.100.0/24
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
ipsec-policy=out,ipsec
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
invalid
add action=drop chain=forward comment="defconf: drop invalid" connection-state=\
invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" \
connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=!LAN
/ip firewall nat
add action=masquerade chain=srcnat ipsec-policy=out,none out-interface-list=WAN \
src-address=192.168.100.0/24
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=\
out,none out-interface-list=WAN
Not sure how to obtain this... can you give me an example configuration of that rule?On the other hand, you have to exclude packets towards 192.168.100.2-192.168.100.99 (or 192.168.100.0/24 to make it simple) from being src-nated (or masqueraded, the difference between the two is not relevant here) if you want to be able to initiate connections to the IPsec client device acting as a server (i.e. to ping it). The NAT rules are only applied on the initial packet of each connection; the decision taken for the initial packet is stored in the context of the connection, and all subsequent packets of that connection are treated the same way (or inversely, depending on their direction).
Thanks!!
Re: IPsec IKEv2 Server for Road Warriors/Site to Site behind double NAT - rb4011 and OS6.48.1
Hm. The masquerade rule is definitely not related to pinging a LAN host, so something more must be wrong. So runI can see traffic hitting the masquerade rule in the NAT, but no webpage or other traffic will pop up succefully on the Android client, and of course no ping to internal LAN.
/tool sniffer quick ip-address=8.8.4.4
on the Mikrotik, ping 8.8.4.4 from the phone, and see how far the request makes it and whether a response comes (and how far it makes it). Then do the same for an address on LAN which you can ping from the router itself.
Place a rule chain=srcnat action=accept dst-address=192.168.100.0/24 before (above) the masquerade ones. On a command-line, an additional parameter place-before=x works when adding a rule, and /ip firewall nat move x destination=y works when you want to change order of already existing rules; on the GUIs, drag and drop is used to change the order of rules.Not sure how to obtain this... can you give me an example configuration of that rule?
Or add ipsec-policy=out,none to the masquerade rule, which is however a less selective way and hence not suitable for all situations (sometimes you need the reverse, to masquerade/srcnat some traffic in order that it would match a policy).
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
Re: IPsec IKEv2 Server for Road Warriors/Site to Site behind double NAT - rb4011 and OS6.48.1
Something is happening...wrong. Google DNS ping generate traffic back/forth ether1 interface (mac addresses between mirkotik and ISP router), but no ping on the Android phone. Ping to LAN comes to ether1---> bridge ----> ether2 LAN interface and reverse. But still no ping succeded on the Android phone. Crazy.Hm. The masquerade rule is definitely not related to pinging a LAN host, so something more must be wrong. So run
/tool sniffer quick ip-address=8.8.4.4
on the Mikrotik, ping 8.8.4.4 from the phone, and see how far the request makes it and whether a response comes (and how far it makes it). Then do the same for an address on LAN which you can ping from the router itself.
Done...It did not help.Place a rule chain=srcnat action=accept dst-address=192.168.100.0/24 before (above) the masquerade ones. On a command-line, an additional parameter place-before=x works when adding a rule, and /ip firewall nat move x destination=y works when you want to change order of already existing rules; on the GUIs, drag and drop is used to change the order of rules.
Or add ipsec-policy=out,none to the masquerade rule, which is however a less selective way and hence not suitable for all situations (sometimes you need the reverse, to masquerade/srcnat some traffic in order that it would match a policy).
Re: IPsec IKEv2 Server for Road Warriors/Site to Site behind double NAT - rb4011 and OS6.48.1
So in the Google DNS case, you can see the IPsec payload decapsulated from the transport packet to arrive via ether1 and be sent via ether1 again, then the response to arrive from ether1, and that's all, correct? If so, it is a correct behaviour, because the payload packet is not visible in sniffer before geting encrypted and encapsulated. Given that the SA for Mikrotik->Android direction doesn't count packets, it means the response packet got lost somewhere. Since there is a rule in your firewall, which says "accept forwarded packets matching an outgoing IPsec policy", can you see that rule to count as you are pinging (/ip firewall filter print stats interval=1s)? And can you see the installed-sa to count, now after the change of the masquerade rule?Something is happening...wrong. Google DNS ping generate traffic back/forth ether1 interface (mac addresses between mirkotik and ISP router), but no ping on the Android phone. Ping to LAN comes to ether1---> bridge ----> ether2 LAN interface and reverse. But still no ping succeded. Crazy.
It could not help with the above, it should only have allowed you to ping the phone from the Mikrotik itself. So also here, if you ping this way, can you see the installed-sa in the Mikrotik-Android direction to count?Done...It did not help.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
Re: IPsec IKEv2 Server for Road Warriors/Site to Site behind double NAT - rb4011 and OS6.48.1
Correct for the Google DNS behavior on ether1, but ping still fails on Android.
However, the outgoing rules is never hitted, only the input ipsec one. But, I can see traffic outgoing in the SA from local to remote Android device.
When I ping from Android to Mikrotik LAN, same.
However, the outgoing rules is never hitted, only the input ipsec one. But, I can see traffic outgoing in the SA from local to remote Android device.
When I ping from Android to Mikrotik LAN, same.
Re: IPsec IKEv2 Server for Road Warriors/Site to Site behind double NAT - rb4011 and OS6.48.1
I'm surprised that the action=accept ipsec-policy=out,ipsec rule does not count whereas the mikrotik->android installed-sa does.
But if I read you right, both installed-sa now count when you ping from the Android, and don't otherwise? Or I have missed something?
If you run /tool sniffer ip-address=the.public.ip.of.the.phone, and ping anything (Google DNS or LAN host) from the phone, can you see packets to both arrive and leave?
But if I read you right, both installed-sa now count when you ping from the Android, and don't otherwise? Or I have missed something?
If you run /tool sniffer ip-address=the.public.ip.of.the.phone, and ping anything (Google DNS or LAN host) from the phone, can you see packets to both arrive and leave?
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
Re: IPsec IKEv2 Server for Road Warriors/Site to Site behind double NAT - rb4011 and OS6.48.1
You have read correctly: both counters increases, but the firewall rules is not hitted.
The packet sniffing tools sees packets in both directions from the public Android IP and the ether1 wan interface IP (192.168.0.253), not only pinging, but probably from other services on my android phone trying to communicate through the tunnel....
(God, when RouterOS 7 with Wireguard will be ready :) )
The packet sniffing tools sees packets in both directions from the public Android IP and the ether1 wan interface IP (192.168.0.253), not only pinging, but probably from other services on my android phone trying to communicate through the tunnel....
(God, when RouterOS 7 with Wireguard will be ready :) )
Re: IPsec IKEv2 Server for Road Warriors/Site to Site behind double NAT - rb4011 and OS6.48.1
Well... so the IPsec transport packets are now going in both directions, installed-sa are counting - it sounds to me like an Android problem, or a problem of incorrect encryption and/or authentication at Mikrotik side, making the received packets at Android side undecipherable.
To find out which assumption is correct, using some other RouterOS version than 6.48.1 may be the simplest way. For me, IKEv2 works fine in 6.46.8. And the multiple NAT has nothing to do with it, except if the native IKEv2 in Android was equally stupid as the one in Windows, which doesn't like NAT at responder side by default and you have to tell it using registry to accept it. But the Windows one at least claims the error already during Phase 1. And you can fool that by attaching the public IP to a port-less bridge interface on the Mikrotik, setting the local-address of the /ip ipsec peer row to that address, and doing dst-nat from 192.168.0.253 "back" to the public IP, but I'm not sure how the public IP detection of /ip cloud will react on that.
The advantage of the native Android client seems to be the support of PSK authentication, so if you want to substitute it by Strongswan, you'll have to create the certificates (hint: Strongswan cares abot Subject Alt Name, not about Common Name).
Regarding Wireguard, where's the client address assignment by server?
To find out which assumption is correct, using some other RouterOS version than 6.48.1 may be the simplest way. For me, IKEv2 works fine in 6.46.8. And the multiple NAT has nothing to do with it, except if the native IKEv2 in Android was equally stupid as the one in Windows, which doesn't like NAT at responder side by default and you have to tell it using registry to accept it. But the Windows one at least claims the error already during Phase 1. And you can fool that by attaching the public IP to a port-less bridge interface on the Mikrotik, setting the local-address of the /ip ipsec peer row to that address, and doing dst-nat from 192.168.0.253 "back" to the public IP, but I'm not sure how the public IP detection of /ip cloud will react on that.
The advantage of the native Android client seems to be the support of PSK authentication, so if you want to substitute it by Strongswan, you'll have to create the certificates (hint: Strongswan cares abot Subject Alt Name, not about Common Name).
Regarding Wireguard, where's the client address assignment by server?
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
Re: IPsec IKEv2 Server for Road Warriors/Site to Site behind double NAT - rb4011 and OS6.48.1
But still I can't justify why the output ip filter rule is not hitted...even if packets count and sniffer see rx/tx flows...Well... so the IPsec transport packets are now going in both directions, installed-sa are counting - it sounds to me like an Android problem, or a problem of incorrect encryption and/or authentication at Mikrotik side, making the received packets at Android side undecipherable.
I was aware about that issue with Android, but since IKEv2 tunnel phases 1 and 2 were ok, sounds strange that later Android can not decode packets... Encryption keys are set up correctly for both installed SAs...To find out which assumption is correct, using some other RouterOS version than 6.48.1 may be the simplest way. For me, IKEv2 works fine in 6.46.8. And the multiple NAT has nothing to do with it, except if the native IKEv2 in Android was equally stupid as the one in Windows, which doesn't like NAT at responder side by default and you have to tell it using registry to accept it. But the Windows one at least claims the error already during Phase 1.
There is no Wireguard yet on 6.48.1. I have actually an Rpi 4 on the LAN behind the Mikrotik that works as WG server: it assigns the remote IP and then I forward selected traffic with iptables from Rpi toward LAN/WAN....Rough, but worked flawlessy after 5 minutes. It's my actual main VPN system (I tried openvpn on Mikrotik but it's sloooooow...and tcp only).Regarding Wireguard, where's the client address assignment by server?
Re: IPsec IKEv2 Server for Road Warriors/Site to Site behind double NAT - rb4011 and OS6.48.1
Still with 6.48.1, i tried also to set up strongswan on android and RSA certificate identity. No luck with that solution too. Even if fqdn server identification works ok, client can not login with the same erro...
identity not found for peer: DER DN: client.(something)
the client.(something) is the same common name on the certificate used.
Looks something is really broken in IPSec and 6.48.1 at this point.
identity not found for peer: DER DN: client.(something)
the client.(something) is the same common name on the certificate used.
Looks something is really broken in IPSec and 6.48.1 at this point.
Re: IPsec IKEv2 Server for Road Warriors/Site to Site behind double NAT - rb4011 and OS6.48.1
Show me the /certificate print detail (assuming you've created the certificate for the Strongswan client on the 4011 so it will be there as well) and the /ip ipsec export hide-sensitive.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
Re: IPsec IKEv2 Server for Road Warriors/Site to Site behind double NAT - rb4011 and OS6.48.1
here we go:Show me the /certificate print detail (assuming you've created the certificate for the Strongswan client on the 4011 so it will be there as well) and the /ip ipsec export hide-sensitive.
Code: Select all
Flags: K - private-key, L - crl, C - smart-card-key, A - authority,
I - issued, R - revoked, E - expired, T - trusted
0 KL A T name="ca-certificate" digest-algorithm=sha256 key-type=rsa
common-name="Example" key-size=4096 subject-alt-name=""
days-valid=3650 trusted=yes key-usage=key-cert-sign,crl-sign
serial-number="something"
fingerprint="something"
akid="" skid=something
invalid-before=feb/05/2021 20:09:45
invalid-after=feb/03/2031 20:09:45 expires-after=519w6d3h12m54s
1 K I T name="server-certificate" digest-algorithm=sha256 key-type=rsa
common-name="server.Example" key-size=4096 subject-alt-name=""
days-valid=3650 trusted=yes
key-usage=digital-signature,key-encipherment,tls-server
ca=ca-certificate serial-number="something"
fingerprint="something"
akid=something
skid=something
invalid-before=feb/05/2021 20:12:35
invalid-after=feb/03/2031 20:12:35 expires-after=519w6d3h15m44s
2 K I T name="client-certificate" digest-algorithm=sha256 key-type=rsa
common-name="client.Example" key-size=4096 subject-alt-name=""
days-valid=3650 trusted=yes key-usage=tls-client ca=ca-certificate
serial-number="something"
fingerprint="something"
akid=something
skid=something
invalid-before=feb/05/2021 20:14:19
invalid-after=feb/03/2031 20:14:19 expires-after=519w6d3h17m28s
/ip ipsec mode-config
add address-pool=ipsec-pool address-prefix-length=32 name=ipsec-config \
split-include=0.0.0.0/0 system-dns=no
/ip ipsec policy group
add name=ipsec-group
/ip ipsec profile
set [ find default=yes ] enc-algorithm=aes-256,aes-192,aes-128 \
hash-algorithm=sha256
add enc-algorithm=aes-256,aes-192,aes-128 name=ipsec-profile
/ip ipsec peer
add exchange-mode=ike2 local-address=192.168.0.253 name=user1 passive=yes \
profile=ipsec-profile send-initial-contact=no
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256,sha1 enc-algorithms=\
aes-256-cbc,aes-256-gcm,aes-192-cbc,aes-192-gcm,aes-128-cbc,aes-128-gcm \
lifetime=8h
add enc-algorithms="aes-256-cbc,aes-256-ctr,aes-256-gcm,aes-192-cbc,aes-192-ct\
r,aes-192-gcm,aes-128-cbc,aes-128-ctr,aes-128-gcm" lifetime=8h name=\
ipsec-proposal pfs-group=none
/ip ipsec identity
add auth-method=digital-signature certificate=server-certificate \
generate-policy=port-strict match-by=certificate mode-config=ipsec-config \
my-id=fqdn:(my dynamic public address) peer=user1 policy-template-group=ipsec-group \
remote-certificate=client-certificate
/ip ipsec policy
add dst-address=192.168.100.0/24 group=ipsec-group proposal=ipsec-proposal \
src-address=0.0.0.0/0 template=yes
/ip ipsec settings
set accounting=no
Re: IPsec IKEv2 Server for Road Warriors/Site to Site behind double NAT - rb4011 and OS6.48.1
Using IP address together with type fqdn as peer identity is not a good idea as the Strongswan expects the type of the Subject-Alt-Name of the certificate to match the identity type. So if identity type is fqdn, the subject alt name type must be DNS; if identity type is address, the subject alt name type must be IP. Unless something has changed recently, if the Subject-Alt-Name of the server certificate is empty, like in your case, Strongswan will consider the certificate invalid to authenticate the server; I'm also not sure whether Strongswan doesn't require the key-usage list to contain ipsec-end-system and/or ipsec-tunnel. Mikrotik, somehow oddly, requires tls-client and tls-server items to consider the certificate applicable for IPsec authentication of an initiator and responder, respectively.
But all the above is related to the Strongswan side; I never set my-id at the identity rows with auth-mode=digital-signature, which means I don't know how doing so affects matching of the peer's ID to the /ip ipsec identity rows. Try to set my-id to auto and see how far you get that way.
But all the above is related to the Strongswan side; I never set my-id at the identity rows with auth-mode=digital-signature, which means I don't know how doing so affects matching of the peer's ID to the /ip ipsec identity rows. Try to set my-id to auto and see how far you get that way.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
Re: IPsec IKEv2 Server for Road Warriors/Site to Site behind double NAT - rb4011 and OS6.48.1
Very good explanation, thanks!!. I was able to fix the issues with certificates...but the behavior is exactly the same as with the pre-shared key solution and the native Android client. No LAN ping, no WAN access, similar packet flows and packet sniffer results...Using IP address together with type fqdn as peer identity is not a good idea as the Strongswan expects the type of the Subject-Alt-Name of the certificate to match the identity type. So if identity type is fqdn, the subject alt name type must be DNS; if identity type is address, the subject alt name type must be IP. Unless something has changed recently, if the Subject-Alt-Name of the server certificate is empty, like in your case, Strongswan will consider the certificate invalid to authenticate the server; I'm also not sure whether Strongswan doesn't require the key-usage list to contain ipsec-end-system and/or ipsec-tunnel. Mikrotik, somehow oddly, requires tls-client and tls-server items to consider the certificate applicable for IPsec authentication of an initiator and responder, respectively.
But all the above is related to the Strongswan side; I never set my-id at the identity rows with auth-mode=digital-signature, which means I don't know how doing so affects matching of the peer's ID to the /ip ipsec identity rows. Try to set my-id to auto and see how far you get that way.
Re: IPsec IKEv2 Server for Road Warriors/Site to Site behind double NAT - rb4011 and OS6.48.1
That pretty much excludes issues at the Android end. So I'd myself try 6.46.8 before digging further. Not because that version is special in some way but because I know IKEv2 works on it, whereas I haven't tested 6.47.9 nor 6.48.1 yet.but the behavior is exactly the same as with the pre-shared key solution and the native Android client
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
Re: IPsec IKEv2 Server for Road Warriors/Site to Site behind double NAT - rb4011 and OS6.48.1
I need to put this Mikrotik out of my main network before do that... Never tried downgrading MT devices, but I would expect issues on existing configurations, etc. I asked also official support from Mikrotik about that issue, still no news.That pretty much excludes issues at the Android end. So I'd myself try 6.46.8 before digging further. Not because that version is special in some way but because I know IKEv2 works on it, whereas I haven't tested 6.47.9 nor 6.48.1 yet.but the behavior is exactly the same as with the pre-shared key solution and the native Android client
For the moment, thanks for all your support!
Re: IPsec IKEv2 Server for Road Warriors/Site to Site behind double NAT - rb4011 and OS6.48.1
Some feedback from Helpdesk:
Meanwhile I'm pretty sure I tried already to add a srcnat rule to cope with the first point, I understood manual routing was not necessary with IPSEC IKEv2 tunnel setup....split include is 0.0.0.0/0, no other routing setting would be pushed from mode-config as much as I understood....This is definitely a firewall issue. To be able to reach 192.168.178.0/24 you have to add exception rule for your source NAT rule, otherwise the traffic from 192.168.178.x to 192.168.100.x is source natted and no longer matches the IPsec policy. You have to exclude this traffic from the source nat rule.
Since 192.168.0.0/24 network is reachable through your WAN interface, I would suspect it is routing issue, most likely the network host devices are not trying to reach 192.168.100.0/24 network through this router but via a different default gateway.
Re: IPsec IKEv2 Server for Road Warriors/Site to Site behind double NAT - rb4011 and OS6.48.1
It seems to me that the support guy got lost in your network prefixes and maybe in the trouble description.
As I wrote in post #5, you would only need the exception rule suggested by the support if you wanted to initiate connections from 192.168.178.0/24 to the Android client (whose adress comes from the pool for mode-config - 192.168.100.0/24). For connections initiated by the Android client this rule is not necessary, because only the initial packet of each connection is processed by the srcnat and dstnat rules; all subsequent packets of each connection inherit the NAT handling chosen for the first packet, with respect to their direction.
As for 192.168.0.0/24, it's the same story - for connections initiated by the Android client, the masquerade rule makes anything in 192.168.0.0/24 see the packets from Android as coming from your ether1 address. For connections from within 192.168.0.0/24 to the Android client, yes, a route may be missing on the external router, saying that 192.168.100.0/24 is accessible via your 4011's address from 192.168.0.0/24 assigned to ether1, but that's not the scenario you struggle with.
As I wrote in post #5, you would only need the exception rule suggested by the support if you wanted to initiate connections from 192.168.178.0/24 to the Android client (whose adress comes from the pool for mode-config - 192.168.100.0/24). For connections initiated by the Android client this rule is not necessary, because only the initial packet of each connection is processed by the srcnat and dstnat rules; all subsequent packets of each connection inherit the NAT handling chosen for the first packet, with respect to their direction.
As for 192.168.0.0/24, it's the same story - for connections initiated by the Android client, the masquerade rule makes anything in 192.168.0.0/24 see the packets from Android as coming from your ether1 address. For connections from within 192.168.0.0/24 to the Android client, yes, a route may be missing on the external router, saying that 192.168.100.0/24 is accessible via your 4011's address from 192.168.0.0/24 assigned to ether1, but that's not the scenario you struggle with.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.