IKEv2 Mobile VPN IOS

anav · March 22, 2019, 12:41pm

Tis true, I am attempting to setup up IKEv2, to primarily use the MT App and to further of course my knowledge of configuring RouterOS.
I have managed to create the necessary certificates on the MT and transfer them to my Iphone (thanks to python).
I believe I have configured the IPSEC portion successfully but I am now flailing somewhat moving forward.
Specifically, I am lost in terms of setting firewall rules. I could not find clear guidance anywhere at least that I understood.
I know that IKEv2 uses UDP port 500 for phase 1 and that is probably all I need in terms of port forwarding.
But to where?? My made up subnet pool for ipsec is 192.168.44.0/24
/add firewall nat
add action=dstnat chain=dst-nat in-interface-list=WAN dst-port=500 protocol=udp to address=???

I am also thinking that I will have to create a forward firewall rule from the vpn-pool, to the subnet I wish to gain access to through the vpn tunnel
/add firewall filter
add action=accept chain=forward in-interface=vpnsubnet out-interface=home-vlan11 (log=yes)

Reading tutorials, wikis, viewing videos, I get the sense that I also will ALSO have to create source nat rules and mangle traffic, but should it be that hard and complex???
There are potentially three scenarios
(1) Primary Purpose: Be able to use IOS app to gain access to winbox.
(2) Secondary Purpose: Be able to gain access to LAN shares (or even print on home printer)
(3) Tertiary Purpose: Be able to surf the internet but using the Router as my firewall.

I believe all three scenarios can be boiled down to simply accessing the home-lan (my home-vlan11).
Thus this is what I think I need help in to complete my config.

Abbreviated for clarity, please have a look to see if I have missed any ipsec type items…
For example, not sure but I think saw something that indicated perhaps the default ipsec policy forward chain rules should be BEFORE fastrack??

# mar/22/2019 09:07:31 by RouterOS 6.44
# model = RB450Gx4
/interface ethernet
set [ find default-name=ether5 ] comment=Port5 name=Bell_eth5 speed=100Mbps
set [ find default-name=ether1 ] comment=Port1 name=Eastlink_eth1 speed=\
    100Mbps
set [ find default-name=ether4 ] comment=PI_DNS_RESOLVER name=eth4-PI (future work pi is on its way!!)
set [ find default-name=ether2 ] comment=LAN1-Home speed=100Mbps
set [ find default-name=ether3 ] comment=LAN1-Home speed=100Mbps
/interface bridge
add admin-mac= auto-mac=no comment=defconf name=HomeBridge \
    vlan-filtering=yes
/interface vlan
add interface=HomeBridge name=Home-LAN_V11 vlan-id=11
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/ip ipsec profile
add dh-group=modp2048 dpd-interval=1h enc-algorithm=aes-256,aes-128 \
    hash-algorithm=sha256 name=ios-profile
/ip ipsec peer
add exchange-mode=ike2 name=ios-peer passive=yes profile=ios-profile \
    send-initial-contact=no
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=ios-ikev2-proposal \
    pfs-group=none
/ip pool
add name=pool-mobilevpn ranges=192.168.44.0/24
add name=dhcp-HomeLAN ranges=192.168.0.33-192.168.0.150
/ip dhcp-server
add address-pool=dhcp-HomeLAN disabled=no interface=Home-LAN_V11 lease-time=\
    1d name=HoMeLAN
/ip ipsec mode-config
add address-pool=pool-mobilevpn name=cfg1 static-dns=8.8.8.8 system-dns=no
/interface bridge port
add bridge=HomeBridge comment=defconf ingress-filtering=yes interface=ether2
add bridge=HomeBridge comment=defconf ingress-filtering=yes interface=ether3
/ip settings
set allow-fast-path=no icmp-rate-limit=100 rp-filter=loose
/interface bridge vlan
add bridge=HomeBridge tagged=HomeBridge,ether2 vlan-ids=\
    30,2,36,40,45,55,100,200,666
add bridge=HomeBridge tagged=HomeBridge,ether3 vlan-ids=99,77,33
add bridge=HomeBridge tagged=HomeBridge,ether2,ether3 vlan-ids=11
/ip address
add address=192.168.0.1/24 interface=Home-LAN_V11 network=192.168.0.0
/ip dhcp-server network
add address=192.168.0.0/24 dns-server=192.168.0.1 gateway=192.168.0.1
/ip dns
set allow-remote-requests=yes servers=\
    8.8.8.8,8.8.4.4,208.67.220.220,208.67.222.222,1.0.0.1
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related" \
    connection-state=established,related
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="Allow ADMIN to Router" \
    in-interface-list=LAN src-address-list=adminaccess
add action=accept chain=input comment="Allow LAN DNS queries-UDP" \
    connection-state="" dst-port=53 in-interface-list=LAN protocol=udp
add action=accept chain=input comment="Allow LAN DNS queries - TCP" dst-port=\
    53 in-interface-list=LAN protocol=tcp
add action=drop chain=input comment="DROP ALL ELSE" log-prefix=\
    "INPUT DROP ALL"
    {forward chain}
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related
add action=drop chain=forward comment="Drop external DNS - UDP" \
    dst-port=53 in-interface-list=WAN protocol=udp
add action=drop chain=forward comment="Drop external DNS - TCP" \
    dst-port=53 in-interface-list=WAN protocol=tcp
add action=accept chain=forward comment=\
    "defconf: accept established,related, " connection-state=\
    established,related
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="ENABLE HomeLAN  to WAN" \
    in-interface=HomeBridge log-prefix="ALLOWED LAN 2 WAN TRAFFIC" \
    out-interface-list=WAN src-address=192.168.0.0/24
add action=accept chain=forward comment="allow VLANS  to WAN " \
    in-interface-list=VLANSwInt out-interface-list=WAN
add action=accept chain=forward comment=\
    "Allow Port Forwarding -  DSTNAT" connection-nat-state=dstnat \
    connection-state=new in-interface-list=WAN
add action=drop chain=forward comment=\
    "DROP ALL other  FORWARD traffic" log-prefix="FORWARD DROP ALL"
/ip firewall nat
add action=masquerade chain=srcnat comment="SCR_NAT for LAN - Cable" \
    ipsec-policy=out,none out-interface=Eastlink_eth1
add action=masquerade chain=srcnat comment="SCR_NAT FOR LAN - FibreOP" \
    out-interface=vlanbell
/ip ipsec identity
add auth-method=rsa-signature certificate=vpnRM.server generate-policy=\
    port-strict match-by=certificate mode-config=cfg1 my-id=fqdn:vpnRM.server \
    peer=ios-peer remote-certificate=RMi6svpn.client remote-id=\
    fqdn:RMi6svpn.client
/ip route
add check-gateway=ping distance=3 gateway=8.8.4.4
add check-gateway=ping distance=4 gateway=208.67.220.220
add distance=10 gateway=ISP2gatewayIP
add distance=3 dst-address=8.8.4.4/32 gateway=ISP1gatewayIP scope=10
add comment=Email_bypass distance=1 dst-address=24.222.0.20/32 gateway=\
    ISP2gatewayIP
add distance=4 dst-address=208.67.220.220/32 gateway=ISP1gatewayIP scope=10
/system logging
add topics=ipsec
/system ntp client
set enabled=yes server-dns-names=time.nrc.ca,nrc.chu.ca
/tool bandwidth-server
set enabled=no
/tool mac-server
set allowed-interface-list=none
/tool mac-server mac-winbox
set allowed-interface-list=RBwin

emils · March 22, 2019, 12:49pm

Do not need to NAT anything on server side. Accept UDP/500 and UDP/4500 in input chain. This should be enough to establish the tunnel. Then you have to accept the traffic between the VPN subnet and your local subnet in forward chain.

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

anav · March 22, 2019, 12:54pm

Thank you emils, you are a scholar and a gentleman and there are damned few of us left.
I am assuming you mean input from the WAN interface vice the LAN interface??

emils · March 22, 2019, 1:06pm

Yes, of course.

Basically the RW client (iOS) has secure session between itself and the RW server (RouterOS) over UDP/4500 (input chain on router). Then the traffic is decrypted and captured by the forward chain and the actual src and dst addresses are visible. Perhaps, the packet flow diagram will explain this better.

https://wiki.mikrotik.com/wiki/Manual:Packet_Flow_v6#Ipsec_Encryption.2FDecryption

anav · March 22, 2019, 1:12pm

Thanks
So far so good.
I entered in the input chain rule and BINGO, connection was established very quickly and held for a while…
I entered in my forward chain rule
add chain=forward action=accept source address=192.168.44.0/24 out-interface=home-lan-vlan11

I then went to my safari browser BUT was not able to open up any devices on the LAN?
I tried to use my MT APP but noticed shortly after that my IKE was ‘killed’

Something I am missing?
Order/placement of rules?

I can confirm I am unable to browse the internet from my connected iphone, nor access the router via the MT app??? ( I am still holding a good connection though)

anav · March 22, 2019, 9:05pm

Success, now have internet through VPN tunnel from iphone cell data to router and out firewall
Success, now have access to LAN components such as my 260GS switches
Success, now have access to router via WINBOX.

Why is what I need to know. Why I had to put the input chain rule and the forward chain rules to allow access BEFORE THE established related rules in each chain?****?

Sob · March 22, 2019, 10:12pm

You need input rules for udp 500 and 4500, because IPSec uses that to create tunnel. It’s similar to e.g. OpenVPN, where you’d need to allow access to tcp 1194 (or some other non-default port you’d use).

You need forward rule(s) (but not before established & related, it can be after) because traffic from IPSec looks as if it comes from WAN and you most likely block that. Instead by source address, you can tell internet traffic from tunneled traffic using ipsec-policy matcher.

anav · March 22, 2019, 11:07pm

How do I keep or ALLOW my ‘fake’ vpn subnet access to the router (for my MT App) and to my LANs, but exclude external addresses of the same ilk.
Right now I would have to assume that anybody would be able to access my router or my LANS if they approach my WANIP with a source address the same as my fake VPN subnet**??**

(I have tried source-mac-address, source-type-local, blocking the vpn subnet but with in-interface=WAN, but nothing works to allow the traffic desired and block unwanted traffic)??

Sob · March 23, 2019, 1:53am

You want this page: https://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Filter
And search for “ipsec-policy”.

anav · March 23, 2019, 2:58am

Hmmm, makes me think my previous rules were wise to have disabled.

The one rule I need not worry about is the incoming encryted traffic from the iphone over the internet.
add action=accept chain=input comment=“VPN To Router”
connection-state=new disabled=no protocol=udp
dst-ports=500,4500 in-interface-list=WAN

For the Input Rule for after the vpn connection (from fakevpn subnet) to the router for winbox purpose, the traffic is no longer or going to undergo encryption, so I gather this is what you meant???
(and the return traffic does not require encryption either)
add action=accept chain=input comment=“Allow Mobile_ADMIN to Router”
connection-state=new disabled=yes ipsec-policy=in,none
src-address-list=Mobile-vpn \

Because of the ipsec policy part of the rule does that mean an external user hitting the router with the correct IP address would NOT access the router???

Likewise for the FORWARD RULE the same logic applies??? .
add action=accept chain=forward comment=“Allow Mobile_ADMIN to the LAN”
connection-state=new disabled=yes ipsec-policy=in,none
out-interface-list=LAN src-address-list=Mobile-vpn \

Finally, for the outgoing WAN Traffic of the vpn subnet, in other words using the router for its internet and firewall for the iphone … (we recognize the packets going from the fakevpn subnet out the router are part of an ipsec originated policy.
add action=accept chain=forward comment=“Mobile_using Firewall for WWW”
connection-state=new disabled=yes ipsec-policy=in,none
out-interface-list=WAN src-address-list=Mobile-vpn \

To summarize, I should use ipsec-policy in my associated rules for traffic flow from fake vpn subnet.
Since none of this traffic is going to be encrypted, it gets the NONE setting. The direction of the policy we are using is IN.
By placing the ipsec-policy as part of the rule, the packets are inspected by the router to ensure they are actually part of the decrypted traffic.
In this way any external traffic using the same fakeVPN Ip address will be dropped as invalid or not meeting the necessary criteria???

Sob · March 23, 2019, 3:25am

It’s the other way around, you want ipsec-policy=in,ipsec to match traffic from tunnel. It’s traffic that originally came encrypted, but now was decrypted by router and it’s entering the firewall again (first time it was in form of either esp packets or udp/4500 packets, both encrypted; those would match ipsec-policy=in,none). And you don’t need to worry much about source address of these packets, because nobody can just slip some in unexpectedly. They could send packets with same source as you vpn subnet uses, but they can’t encrypt and pass them as legitimate ipsec traffic, because they don’t know your key or ipsec secret. For outgoing packets to your vpn subnet, you again want to allow those that match ipsec-policy=out,ipsec. Those that don’t would be leaks that could happen when then tunnel is down. Not that they would get far, but it’s better to block them.

anav · March 23, 2019, 1:39pm

Roger, so the matching ipsec-policy=ipsec should be inter****preted as, matching any traffic that required encryption, which addresses my traffic from the iphone.
(I initially read the exceedingly sparse document setting explanation to mean since the traffic was already decrypted it no longer needed encryption or would be encrypted and thus ‘none’ was appropriate )

Thus, step 1.
add action=accept chain=input comment=“Allow Mobile_ADMIN to Router”
connection-state=new disabled=yes ipsec-policy=in,ipsec
src-address-list=Mobile-vpn

add action=accept chain=forward comment=“Allow Mobile_ADMIN to the LAN”
connection-state=new disabled=yes ipsec-policy=in,ipsec
out-interface-list=LAN src-address-list=Mobile-vpn

Further, you state there is no need to indicate source address due to the fact that the router knows about and is tracking the ispsec decrypted traffic**?**
Thus step2
add action=accept chain=input comment=“Allow Mobile_ADMIN to Router”
connection-state=new disabled=yes ipsec-policy=in,ipsec \

add action=accept chain=forward comment=“Allow Mobile_ADMIN to the LAN”
connection-state=new disabled=yes ipsec-policy=in,ipsec
out-interface-list=LAN
Note: Assuming I still need to delineate where this traffic is intended to be forwarded too**?**
(for example if I only wanted my vpnfakesubnet traffic to be forwarded to a specific vlan interface I would have delineated that on this rule??)

Lastly, your last comment was a bit confusing

For outgoing packets to your vpn subnet, you again want to allow those that match ipsec-policy=out,ipsec. Those that don’t would be leaks that could happen when then tunnel is down. Not that they would get far, but it’s better to block them

???

I am not sure what you mean? My mobile-admin to WWW (via the router and its firewall) outgoing packets are to the internet not to the vpnfake subnet?
The return packets from WWW would come back through the router (not the vpn tunnel) and back to the vpnfakesubnet address (regular source nat traffic) and this return traffic would then go from the fakevpn subnet back into the tunnel headed for my iphone.

It seems you are suggesting this config…
add action=accept chain=forward comment=“Mobile_using Firewall for WWW”
connection-state=new disabled=yes ipsec-policy=out,ipsec
out-interface-list=WAN
Note: Assuming I still need to delineate where this traffic is intended to be forwarded too**?**

Sadly, I do not understand this config or the explanations. Is there another source of reading material to explain it?? Ive read the firewall bit, and the ipsec bit and no where is this really explained.
Other than normis on a thread saying the default rules are in place because people dont understand how to set up filter rules for ipsec… DAT TRUE!!!

Update. With the new rules suggested (change to ipsec, and removal of source address list) status follows:
a. vpnsubnet to LAN works!!
b. vpnsubnet to Router (via winbox app) works!!
c. vpnsubnet to WWW fails!

Sob · March 23, 2019, 3:19pm

To make it clear, use simple translation, ipsec-policy:

in,ipsec - packet came from tunnel (was originally encrypted, now is decrypted)
in,none - packet did not come from tunnel (regular traffic)
out,ipsec - packet will go out to tunnel (now it’s plain packet, will be encrypted)
out,none - packet will not go out to tunnel (regular traffic)

Knowing that, it should be easy. Not needing to care about source address for in,ipsec traffic may not be entirely true, but if you have only one VPN, it is, because anything matching ipsec-policy=in,ipsec will always match src-address-list=Mobile-vpn too.

The leaks part, let’s assume that internal device wants to connect to some address in Mobile-vpn list, but VPN client is not connected right now. If you’d just allow traffic to Mobile-vpn addresses, packets would go out (to default gateway) unencrypted. But if you require outgoing ipsec, they won’t (will be stopped by default drop at the end). If you want to also filter by addresses, it again depends how complex config you have. For one vpn without special access right for different client you can just require ipsec and don’t worry about addresses. And if you don’t need internal devices iniciate connections to VPN clients, you can skip this completely.

If you mean access to internet, you’d need e.g.:

/ip firewall filter
add action=accept chain=forward connection-state=new ipsec-policy=in,ipsec out-interface-list=WAN

That’s the confusing part about IPSec VPN that unlike others, it doesn’t have interface. With something like OpenVPN, you could use simple in-interface=, but in-interface for IPSec VPN is WAN and you need to use ipsec-policy.

anav · March 23, 2019, 5:27pm

Sob there appears to be a contradiction.
A. out,none - packet will not go out to tunnel (regular traffic) to me describes the use case where I want to to out to the internet via the router and source nat (regular traffic) and thus through the firewall rules of the router etc… IPHONE----------->vpn tunnel-------------->Router-------unencrypted----------Router--------->vpnfakesubnet-------------------->www------------->vpnfakesubnet------------->Router------------encrypted-------------Router-------------->vpn tunnel--------------------->IPHONE

The part in blue is what I think I am discussing.

B. The firewall rule you are suggesting to implement this…
you’d need e.g.:
/ip firewall filter
add action=accept chain=forward connection-state=new ipsec-policy=in,ipsec out-interface-list=WAN

What I can tell unequivocally is that
my input rule to access the router from my vpnfakesubnet works great!! (in,ipsec, no need for source address, MT App is real smooth)
my forward rule to access the LAN from my vpnfakesunet works great!! (in,ispec, no need for source address, but do use out-interface=LAN, accessed two different vlans, one with switch logins and on with a telnet control panel login).

BUT, the access to WWW is still failed,
I tried the following combinations with no luck.
/ip firewall filter
add action=accept chain=forward connection-state=new ipsec-policy=in,ipsec out-interface-list=WAN
/ip firewall filter
add action=accept chain=forward connection-state=new ipsec-policy=in,ipsec
/ip firewall filter
add action=accept chain=forward connection-state=new ipsec-policy=out,ipsec out-interface-list=WAN
/ip firewall filter
add action=accept chain=forward connection-state=new ipsec-policy=out,ipsec

I further tried all of the same combinations above with NONE entered vice ipsec policy.
Nothing worked but the with the setting of ‘NONE’, the firewall rules were matched but with all kinds of weird to and from addresses all over the vlans etc… not useful.

Dont laugh, since my DNS rules on the input chain state in-interface=LAN, I am now thinking, maybe
I have to make up special DNS input rules**???**
Or what I am attempting is simply not possible.

Sob · March 23, 2019, 5:57pm

In other words, you want to connect iPhone to your router using vpn and then browse internet through the vpn and your router, right? If so, my rule should work, because it matches traffic coming from phone (ipsec-policy=in,ipsec) and going to internet (out-interface-list=WAN). And in fact, you don’t really need it, if you still have this rule from first post:

add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec

If I see correctly that you give 8.8.8.8 to vpn client, you don’t need to worry about input rules for dns, client won’t be asking your router.

anav · March 23, 2019, 7:49pm

Concur 100%, but its not - so I am looking for some assistance in a specific rule (and logging) or sniffing, I should create to see where the issue is occurring?

anav · March 23, 2019, 7:54pm

Okay it works now??, I had to move the ipsec rule to right after my fastrack accept rule.
I am thinking that there is a firewall rule that is getting in the way. There is a whole bunch from axiom cyber and it would not surprize me if one of them is a stopper.

Spoke to soon, it stopped working, perhaps intermittent may be appropriate??

Okay it works seemingly okay if I keep the filter rule right at the top after fastrack, and removing state=new and removing out-interface=WAN.
BUT If this is the case, then I dont need my second rule for LAN cause its covered already by this first rule correct???

Arggg its intermittent for both to lan and to wan. Driving me nuts… wonder if its a buggy implementation now???

anav · March 24, 2019, 12:02am

I was out earlier and managed to simultaneously use two browsers to connect to a switch on one vlan, the septic panel via terminal on another and have my MT app working, plus I could also get to the WWW. So all in all, I guess satisfactory.

anav · March 29, 2019, 1:14pm

I need some input as to whether I should be concerned or not about a couple of logged firewall entries that I saw recently.
I have disabled my vpn (ike) fw rules until I have a better understanding.
Note my iphone was not connected at any time when these events took place.

"iphone connecting to router input: in:vlanbell out: (unknown 0), src-mac 08:81:f4:e7:b7:c0, proto udp, 104.152.52.22:5655 -->my primaryWANIP:4500
"iphone connecting to router input: in:vlanbell out: (unknown 0), src-mac 08:81:f4:e7:b7:c0, proto udp, 51.68.213.67:54788 -->my primaryWANIP:4500
"iphone connecting to router input: in:Eastlink-eth1 out: (unknown 0), src-mac 00:01:5c:73.12.46, proto udp, 51.68.213.67:54788 -->mysecondaryWANIP:4500

march 29 (07:06)
march 29 (09:06)
march 29 (09:14)
respectively.

Going back in the log, the same src-mac and IPs are noted several times.

Applicable fw rules.
/ip firewall filter
{input chain}
add action=accept chain=input comment=“VPN To Router” connection-state=new
disabled=yes dst-port=500,4500 log=yes log-prefix=
IphoneConnectingToRouter protocol=udp
add action=accept chain=input comment=“Allow Mobile_ADMIN to Router”
connection-state=new disabled=yes ipsec-policy=in,ipsec log=yes
log-prefix=MobileAdmin_to_Router src-address-list=Mobile-vpn
{forward chain}
add action=accept chain=forward comment=MobileVPN-ToWWW connection-state=“new”
disabled=yes ipsec-policy=in,ipsec log=yes log-prefix=MobileVPN_WWW
add action=accept chain=forward comment=MobileVPN-ToLAN connection-state=new
disabled=yes ipsec-policy=in,ipsec log=yes log-prefix=MobileVPN_to_LAN
out-interface-list=LAN

Sob · March 29, 2019, 2:47pm

It’s like any other VPN (or generally server) that needs to be accessible from anywhere. If you should be able to connect to it from anywhere, so can anyone else. The difference is that you’ll have the right key or password, so you will get in, whle the others won’t have it and will be refused (well, unless there’s some horrible mistake in MikroTik’s implementation of particular VPN).