Routing over IPsec

RouterOS General
1

Hi,

I am trying to route traffic from L2TP clients to the other side of an IPsec tunnel.

When entering the gateway IP in the static route it is reported as unreachable, though is reachable from the bridge the IPsec is created to.

Is this just not supported at all on Mikrotik?

Thanks,
PK

2

Can you share your configuration (use “/export hide-sensitive” on the command line)? Your topology is not clear.

3

Hi,

Sorry some background info. I have a working IPsec tunnel between a CCR1009 and a pfSense firewall.


[admin@CCR1009] /ip ipsec> export hide-sensitive 
# feb/06/2018 19:41:07 by RouterOS 6.40.1
# software id = 4PQ6-NW3J
#
# model = CCR1009-8G-1S-1S+
/ip ipsec proposal
set [ find default=yes ] enc-algorithms=aes-128-cbc lifetime=5m
add enc-algorithms=3des lifetime=5m name=pfsense-ph2 pfs-group=none
/ip ipsec peer
add address=2.2.2.2/32 compatibility-options=skip-peer-id-validation dh-group=modp1024 dpd-interval=disable-dpd \
    enc-algorithm=aes-128 nat-traversal=no
/ip ipsec policy
add dst-address=172.16.10.0/24 proposal=pfsense-ph2 sa-dst-address=2.2.2.2 sa-src-address=1.1.1.1 \
    src-address=10.20.0.0/16 tunnel=yes

Which works fine with traffic to and from 10.20.0.0/16 <> 172.16.10.0/24

I am trying to have a client in the 10.20.0.0/16 say for example 10.20.100.0/24 be routed out over the IPsec tunnel. Internet traffic should look to appear from the 2.2.2.2 address which is the other side of the IPsec tunnel. When I create a static route for 10.20.100.0/24 to be routed to the gateway 172.16.10.1 which is the pfSense side of the IPsec the route is marked as unreachable. Can ping ok via the tunnel with a src IP set to be within 10.20.0.0/16.

Have similar setups working ok Mikrotik to Mikrotik using SSTP and then routing over these as SSTP shows as an available interface to route to. IPSec does not appear to create an interface to route to.

Thanks,
PK

4

the “/” before the “export” was not there for fun :slight_smile:

I can see your LAN subnet to be 10.20.0.0/16 from the IPsec policy but I cannot see what addresses the L2TP clients are getting and to what interface the local address from 10.20.0.0/16 is attached. To make it possible for ppp clients which get addresses from LAN subnet to reach other addresses in that subnet, arp proxy must be active on the interface which holds the local address from LAN subnet.

5

Sorry - the full config is sensitive without a lot of cleanup. To answer your specific questions:

The L2TP clients are assigned addresses within the 10.20.0.0/16 subnet via RADIUS and have no problem accessing both the other clients in the 10.20.0.0/16 subnet and also the 172.16.10.0/24 subnet. I have some clients which I wish their internet access to be from the 2.2.2.2 address and not the 1.1.1.1 address. Normally i would create a routing mark to identify the traffic then add a static route to route this to a distant gateway. When doing this over IPsec it does not work.

All clients on the Mikrotik side are in a bridge:


/interface bridge
add fast-forward=no name=bridge-lan
/ip address
add address=10.20.0.1/16 interface=bridge-lan network=10.20.0.0

Proxy-arp is not currently enabled on the bridge and PPP clients can access the LAN ok.

Thanks,
PK

6

OK, sorry, I have misunderstood a little bit what you want to achieve.

To make your local L2TP clients access internet through the uplink of the remote site, you have basically two possibilities:

  • to create a GRE tunnel through the IPsec tunnel (inspiration here), with a virtual interface at the local end, and give to the local L2TP clients the remote IP, in the same subnet like the local virtual interface, as a default gateway.
  • to add another IPsec policy which would have 0.0.0.0/0 as dst-address and a small subnet within 10.20.0.0/16 as src-address to the existing policy, but I am afraid (just afraid, not sure) that multiple policies per peer are only possible with IKEv2. The L2TP clients would get addresses from the sub-subnet of 10.20.0.0/16.

The 172.16.10.1 is pingable from 10.20.0.0/16 via the tunnel, but it cannot be used as a gateway for members of 10.20.0.0/16 because it is not a member of any local subnet, so it doesn’t resolve (not even recursively) to a MAC address. An ethernet packet for a.b.c.d (different from 172.16.10.0/24), even when a route via gateway c.d.e.f is found for it, still has destination IP a.b.c.d so your current IPsec policy doesn’t match on it.

7

Hi Sindy,

I added an additional IPsec policy src as the L2TP clients and dst as 0.0.0.0/0 which works perfectly.

Thanks,
PK