Routing to interface with IPIP-dummy

RouterOS General
1

I am bussy with using the latest implementation of IKv2 with EAP authentication. I have it working but I have to manually change each time the entry address of the IKEv2 connection in Mangle.

Using the IPIP is partly working when I test it using the ping tool in Winbox.

/ip address
add address=172.20.20.5 interface=ipip-inner network=172.20.20.1
/interface ipip
add local-address=172.20.20.5 mtu=1500 name=ipip-inner remote-address=127.0.0.1

This creates a route:
DC 172.20.20.1/32 172.20.20.5 ipip-inner 255
When I ping to an external IP the traffic is going through the tunnel because it is matched in NAT by the source address 172.20.20.5 which dynamicly generated when connecting to the IKEv2 server.

 0  D ;;; ipsec mode-config
      chain=srcnat action=src-nat to-addresses=10.xx.xx.162 src-address-list=IKEV dst-address-list=!KEV

In connection tracking the ipencap is visible:

6    C  s  protocol=ipencap src-address=172.20.20.5 dst-address=127.0.0.1 reply-src-address=127.0.0.1 reply-dst-address=10.xx.x.162 timeout=9m56s orig-packets=260 orig-bytes=10 400 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=0 repl-bytes=0 
            repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps

And when pinging through the IPIP interface:

13  S C  s  protocol=icmp src-address=172.20.20.5 dst-address=8.8.8.8 reply-src-address=8.8.8.8 reply-dst-address=10.xx.x.162 icmp-type=8 icmp-code=0 icmp-id=46338 timeout=9s orig-packets=7 orig-bytes=350 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 
            repl-packets=7 repl-bytes=350 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=800bps repl-rate=400bps

How can get it working that I send traffic through the IPIP address so that if ends up at the entry-point 10.xx.x.162 to go through the IKEv2 tunnel?

2

Solved it by marking routing…I did this hundreds of times but not try it here.

I will make a short manual so using the new IKEv2 possibilities easier without an client available in ROS/Winbox.

Thanks to Sindy for the IPIP idea.

It was working and then it stopped and I have figure out why it does not work any more.

I put the source address and the IPIP and on the bridge so that is my starting point.

Any suggestions are still welcome.

3

Wait. I don’t understand what you want to achieve through use of the IPIP tunnel, as we’ve checked that currently the IPsec policy can see also the fasttracked packets.

Is your goal to let the same host (i.e. the same source IP) send some outgoing traffic via the IKEv2 tunnel and some outgoing traffic directly via WAN, bypassing the tunnel, although the tunnel’s policy says dst-address=0.0.0.0/0?

If yes, you have to use the usual means (routes or “policy routing” in the sense of routing-mark etc.) to route packets from that host to some destinations via the WAN gateway, and to other destinations via the IPIP tunnel (interface name as route’s gateway is sufficient). Then, you use an action=src-nat rule to set the to-addresses of anything with out-interface=ipip-inner to some non-conflicting IP address, nc.nc.nc.nc, and add nc.nc.nc.nc as a single item to the address-list you refer to from the mode-config (in your example, IKEV).

You don’t need any additional policy routing to handle whatever emerges from the “outer” end of the IPIP interface, as it will be routed either to the WAN or to the inner end of the IPIP tunnel, but it will first be src-nated to the address assigned by the VPN server and subsequently grabbed by the policy. What you do need, however, is a static route with dst-address=nc.nc.nc.nc gateway=ipip-outer, as the “outer” tracked connection will “un-src-nat” the incoming packet’s destination address from the one assigned by the VPN server to nc.nc.nc.nc, and you need the other pass through the firewall also for incoming packets so that the “inner” connection could “un-src-nat” the destination address from nc.nc.nc.nc to the real one.

4

What I want to archive is that ‘basic’ client behavior using a IKEv2 connection. It is not that simple now the NAT line is created triggered by the source address and the source address is the one of the clients. I tried double NAT on one box and did not get that working.

When I use IPIP I saw the correct IP sequence: source address — dst-address — dest-addres — IKEv2 entry in connections as I show in the first post.

Indeed in routing I put:
dst-addres=0.0.0.0/
gateway IPIP-IKEv2-1
type unicast
dist 1 scope 30 target scope 10
Routing Mark IKEv2-1

When it was working, I enabled Fasttracking and it worked but not well and the speed was about 20% lower instead of double. Non-fasttracked was stable.

I am going to try your explanation later today.

5

Assignment of routing-mark using mangle rules is incompatible with fasttracking intrinsically, could that be the problem? If yes, use IP route rule instead.

6

I tried mangle route to an IP in 10.0.1.0 which is in the outer but no luck.

Then I went back to route marking and ping on the router itself works but from a client it doesn’t. There really strange things the NAT is not hit.
Using route marking I see in connections the client IP - target - target - 10.0.1.1 and 10.0.1.1 should be 10.40.x.x which is the entry point of the IKEv2 tunnel.
inner-outer.JPG
Correction: it hits the NAT when I activate the 10.0.1.1 address and so it knows what the IKEv2 entry IP is.

7

Show me the whole export. There must be some mistake.

8

This is what I have added.

/ip address
add address=127.0.1.1 interface=aux-lo network=127.0.1.1
add address=10.0.1.1 interface=ipip-outer network=10.0.1.1

/interface ipip
add mtu=1500 name=ipip-inner remote-address=127.0.1.1
add local-address=127.0.1.1 mtu=1500 name=ipip-outer remote-address=127.0.0.1

/ip route
add distance=1 dst-address=10.0.0.0/20 gateway=ipip-inner
add distance=1 dst-address=10.0.15.254/32 gateway=ipip-outer

/ip firewall nat
add action=src-nat chain=srcnat out-interface=ipip-outer to-addresses=10.0.1.1

/ip firewall mangle
add action=route chain=route-ikev passthrough=no route-dst=10.0.1.1

/ip firewall raw
add action=return chain=prerouting in-interface=ipip-inner

In NAT the top line is the dynamic src-nat for the IKv2.

9

Sorry if I understand the outer and inner in a different manner than you - for me the “outer” end of the IPIP tunnel is the one closer to WAN (so you send packets coming from WAN to it to deliver them towards the actual LAN), the “inner” end is closer to the LAN.

/ip address
add address=127.0.1.1 interface=aux-lo network=127.0.1.1
add address=10.0.1.1 interface=ipip-outer network=10.0.1.1 # you don’t need the nc.nc.nc.nc address to be actually assigned to any interface

/interface ipip
add mtu=1500 name=ipip-inner remote-address=127.0.1.1 local-address=127.0.0.1 # the local address should be explicity set
add local-address=127.0.1.1 mtu=1500 name=ipip-outer remote-address=127.0.0.1

/ip route
add distance=1 dst-address=10.0.0.0/20 gateway=ipip-inner # ??? do you access something on 10.0.0.0/20 via NordVPN? Or you test against some test VPN server of your own? I would put a public IP of a test server in the internet as the dst-address here.
add distance=1 dst-address=10.0.15.254/3210.0.1.1/32 gateway=ipip-outer

/ip firewall nat
add action=src-nat chain=srcnat out-interface=ipip-outerinner to-addresses=10.0.1.1

/ip firewall mangle
add action=route chain=route-ikev passthrough=no route-dst=10.0.1.1 # let the normal routing do its job, mangle and fasttrack don’t fit together anyway

/ip firewall raw
add action=return chain=prerouting in-interface=ipip-inner # What’s the idea behind this rule? It does nothing at all unless it is followed by some other raw rules.

You need the following path of the LAN->WAN packet which has to be sent out via (Nord)VPN:

LAN host → in-interface LAN → route via ipip-inner → src-nat to 10.0.1.1 → ipip-inner → ipip-outer → route via any gateway → src-nat to the address dynamically assigned by NordVPN → IPsec policy matching the new src-address → IPsec security association

and the following path of a response packet:

IPsec security association → un-src-nat from the NordVPN-assigned address to 10.0.1.1 → route via ipip-outer → ipip-outer → ipip-inner → un-src-nat from 10.0.1.1 to the actual LAN source IP of the request → route to connected subnet via LAN interface → out-interface LAN → LAN host

But all this mess is only necessary if those LAN hosts which need to talk to some servers in the internet via NordVPN also need to talk to some other hosts directly, i.e. not via NordVPN.

10

Thanks I am now adapting my config.

I factor is that I don’t have one IKEv2 connection but multiple and I want separate traffic to those IKEv2 connections with help of mangle. I had it working with multiple connections but I could not go far enough back to restore that.

Update:
Basically I want to do what I did with two routers by the inner router doing most of the work and the outer router doing the PPPoE and encrypting over different providers at the same time.
I can’t set the source address which is then catched by dynamic NAT line generated when connecting to a IKEv2 provider. Double NAT does not work on one router and when using two routers behind each other it is not a problem.

I need multiple source addresses to separate traffic over the IKEv2 connections.

I have it not working with the reduced settings and I think tomorrow evening I can have a new go at it. The 10.0.0.0/20 is from your earlier example. I was using before an other non existing IP in the 172.0.20.0 range.

11

Hi msatter! Besides that the config and setting are ZING above my head, I am interested in the potential practical applications of what you are doing.
What use cases will this adaption solve or deliver??

12

And it’s gone…

13

Again, mangling cannot coexist with fasttracking. So I’d suggest to use your address lists of source-sensitive sites to choose the proper action=src-nat rule with the proper to-addresses in the first pass (LAN to IPIP-inner), assigning one of “key” source addresses. In the second pass (IPIP-outer to WAN), some of these key source addresses would be matched by the src-nat rules generated from mode-config, which would make these packets visible to a corresponding IPsec policy, and other key source addresses would me matched by /ip route rule items which would assign them an appropriate routing table (mark) for WAN selection.

14

I am not fastracking since days and when the accident setup was working I activated fasttracking do see that it slowed down and made the connection unstable. I showed that fasttracking is working when using two routers.

Thanks sindy for the extra information and I will look how Policy Routing works and I have not used that before. The Wiki should give me the needed info.

15

The Wiki tends to narrow the meaning of “policy routing” to “assigning connection-marks and routing-marks using mangle rules”. For your final goal, however, this narrow interpretation would be limiting because to achieve the best throughput, the use of fasttracking is very important.

So what I’ve suggested is a way how to use only fasttracking-compatible means for policy routing and nevertheless be able to use other match fields than just the src-address; a pre-requisite for that is the tool originally intended to translate between “normal routing” and “IPsec policy traffic selector matching”, which is the double handling of each packet.

So reading the Wiki is good for understanding how to use the routing-mark once it is assigned; but in your case, even this would be too narrow because the IPsec policy traffic selector ignores the routing-mark and so the only way to enforce the use of the right IPsec policy is to set the right src-address.

So in the first pass, you use src-nat rules after routing, rather than mangle rules before routing, to assign a key value used to select the proper routing table; instead of routing-mark, the intermediate src-address is used as such a key.

In the second pass, you either translate the intermediate src-address to a final src-address which then triggers the IPsec policy, or translate it to a normal routing-mark which is then used the normal way, to identify the routing table which can be used for that packet.

16

I give it a rest for now. I can spend days trying to get it work. Who know Mikrotik will give IKEv2 it’s own interface and client settings so can do this without double NAT or IPIP tunnels.

Spend too much time on this running in circles.

Thank to Sindy again for all the help.