MikroTik

Hello,
In the wiki, IPSec section, chapter 17.1, there is an example of "Site to site IPSec tunnel"
In my case the site 2 have openvpn, this is not a Mikrotik router (Teltonika RUT955)

Could you give me a roadmap how to config the site 2 or a reference to a tutorial ?

Thank you by advance,

First, the openvpn implementation in RouterOS is very limited. It doesn't support UDP transport, compression, and pushing routes to client. So you have to configure the Teltonika accordingly (TCP transport, no compression). And you have to choose the same tunneling mode (L2 or L3) at both the server and the client.

Second, you cannot reasonably expect that every manufacturer will give you tutorials for interconnection with each and every competitor's product. So when interconnecting equipment from two different vendors, you have to check the available configuration options (and limitations!) of both, and choose a combination which can be set at both.

Teltonika RUT955 also use IPsec, PPTP or L2TP that can run very good in Mikrotik too!

Hello,
what a coincidence, I got yesterday a Teltonika RUT955 to test. Nice OpenWRT based router with a AR9344 SoC (RB951...wink...wink ).
Just configured IPSEC and OPENVPN (around 10Mbps throughput) and works fine, clean interface and many options.
In case you still need configuracion, for the Mikrotik side as server follow https://wiki.mikrotik.com/wiki/OpenVPN and for the Teltonika side as client check the attached image and their wiki page: https://wiki.teltonika.lt/view/OpenVPN_ ... n_examples.
As an interesting note, Teltonika masquerades all Lan traffic that goes over the OVPN by default, so by default it's not a site 2 site VPN per-se.
Hope it helps.

Regards.

Jorge.

Thank you Jorge but a fully description of both sides should be appreciable ...

Some questions (for the time being ...):
1) The RUT955 has a private IP address because it is a 4G router and my provider doesn't distribute public address.
What is/are the consequence(s) in the configuration of the Mikrotik ?
2) May I use the same LAN address (192.168.1.0/24) on both sites ?

Hi JPH (?),

sorry, I totally missed your response.

The configuration on Mikrotik side is made according to the Wiki page.
You can follow this document to create certificates for both OVPN server and Client and then go to this article of the wiki to configure the server.
On the Teltonika side you have to load the certificate and configure the OVPN client (the screenshot I sent you).
If you want something more detailed you have to upload at least a diagram and the configuration you already tryed.

As for the questions:
1) No problem with that, my 4G provider also assigns privates IP for its clients.
2) Short answer: No. Long answer: If you provide a network diagram and a good reason to use the same network on both sides maybe.

Hope it helps.

Regards.

Jorge.

Hello Jorge,
Nice to read you again !
This is my network configuration:

I read carefully (I thought ...) Mikrotik wiki but
Here is my Mikrotik server side config:
/ppp secret add name=user1 profile=ovpn service=ovpn
/ppp profile add name=ovpn local-address=172.22.22.1 remote-address=172.22.22.2 use-encryption=required dns-server=192.168.1.1 change-tcp-mss=default use-compression=default use-encryption=required
/interface ovpn-server add name=to_there user=user1
/interface ovpn-server server set auth=sha1 certificate=server2 cipher=aes128,aes256 enable=yes require-client-certificate=yes default-profile=ovpn
I added one static route:
/ip route distance=1 dst-address=192.168.2.0/24 gateway=172.22.22.2
I added a firewall and nat rules:
/ip firewall filter add action=accept chain=input disabled=no dst-port=1194 protocol=tcp
/ip firewall nat add action=accept chain=srcnat dst-address=192.168.2.0/24 src-address=192.168.1.0/24

I check the log:
...
tcp connection established from ...
...
user1 login in: 172.22.22.2
...
to_there connected
...

I test with ping:
ping 192.168.2.1 ok
ping 172.22.22.2 ok
ping 192.168.2.34 timeout 192.1168.2.34 is a portable connected into the 192.168.2.0 network

Here is the RUT955 config, based on your document:
client
nobind
persist-key
auth sha1
ca /lib/uci ....
cert /lib/uci ....
cipher AES-128-CBC
dev tun_c_rut955_ovpn_client
key /lib/uci ...
port 1194
proto tcp-client
remote <hostname of the server-side router>
resolv-retry infinite
route 192.168.1.0 255 255 255 0
verb 5
auth-user-pass /etc/openvpn/vpnclient.auth

the routes for the vpn are:
172.22.22.0 * 255.255.255.0 U tun_c_rut955_ov
192.168.1.0 172.22.22.1 255.255.255.0 UG tun_c_rut955_ov
192.168.2.0 * 255.255.255.0 U br_lan

I try to ping:
ping 172.22.22.1 No answer, <ctrl>-Z to exit
logread | grep openvpn display every x seconds:
daemon.err ... wite to tun/tap:invalid argument (code=22)

In the RUT955 webui, status > network > openvpn display nothing excepted enabled=yes

Voilà !
If you see a mistake ...

Jean-Philippe

hello again,
I note that I didn't fill the country, state, ... fields for the ca certificate but I did it for the server.
I also note that the days valid field of the ca is different of the server
Is it a potential source of errors ?

Jean-Philippe

Hi Jean-Philippe,

in this case the information about the certificates is not important, just the "key usage" attribute (TLS Server and Client on each side accordingly), who signs the certificate (the trusted CA on both side) and a valid Date (also on both) is important.

About the last post, as a short answer you should add a /ip firewall filter on input and forward chains to allow traffic from in-interface=to_there at the top of the firewall rule list just in case some other rule is blocking incoming traffic.
Also on the Teltonika you have to unset masquerade and set default action accept for the openvpn tunnel (attached screenshot) on Network--General Settings--Zone Forwarding.
Probably then traffic should flow OK.

I'm kind of busy right now but tonight I'll make the "long answer".....

Hope you get it working.

Regards.

Jorge.

hello again,
I note that I didn't fill the country, state, ... fields for the ca certificate but I did it for the server.
I also note that the days valid field of the ca is different of the server
Is it a potential source of errors ?

Jean-Philippe

Even longer answer to 2) - both Mikrotik and Teltonika support L2 tunneling mode (called TAP on Teltonika side and ethernet at Mikrotik side), so it is technically possible to bridge the two LANs using OpenVPN in TAP/ethernet mode.

But it is not recommended for multiple reasons. One is security (you cannot use IP firewall to control the traffic between the LANs), another one is higher traffic volume as all the broadcast traffic like ARP requests goes through the tunnel, and yet another one is that Mikrotik's implementation of OpenVPN can only use TCP as transport protocol which adds another overhead traffic to the total.

Hello Jorge,
For the "server2" certificate I didn't select tls server in key usage
For the client certificate I didn't select tls client in key usage

Shall I regenerate them ?

In /ppp profile I have the option use-compression=default
Shall I set use-compression=no because Mikrotik doesn't support LZO ?

Hello Jorge,
For the "server2" certificate I didn't select tls server in key usage
For the client certificate I didn't select tls client in key usage

Shall I regenerate them ?

As Jorge seems to be busy, here is my answer instead: since you could ping the remote end via the tunnel, neither end cares about declared certificate usage, so for now you don't urgently need to re-generate them. But it is possible that future software releases start looking at certificate usage, so from the long-term perspective it may make sense. In any case, the fact that you can ping the Teltonika box itself but not the devices on its LAN is not related to the absence of "tls server" and "tls client" usages.

In /ppp profile I have the option use-compression=default
Shall I set use-compression=no because Mikrotik doesn't support LZO ?

Same like above - the fact that you can ping the remote end via the tunnel means that the /interface ovpn-... ignores the use-compression parameter of /ppp profile, which is no surprise as this parameter is related to the actual PPP protocol behaviour, not to the behaviour of the encryption protocol transporting the PPP one.

1) Ok I can ping 172.22.22.2 and the router 192.168.2.1 but not the client PCs
2) the client log display every x seconds the following message:
daemon.err .... write to TUN/TAP : Invalid argument (code=22)
that is why I ask the question about the compression

3) according to Jorge suggestion, I added two firewall rules in the server and modified parameters in the client (firewall, zone forwarding, vpn: accept and no masquerading)
-> cannot always ping the client PCs
but
-> can ping from Teltonika EVERYTHING !!!!!

We progress ....

Well, unless you've asked it to do otherwise, the ping goes once per second, so if this message was a symptom of a problem with delivering the ping response, it should also be logged once per second, which is not the case.

So as Jorge has already said, check the firewall configuration on the Teltonika. It seems that it accepts packets coming in through the OpenVPN tunnel (or, from the perspective of the firewall, through interface tun_c_rut955_ovpn_client), which are for its own addresses (172.22.22.2 and 192.168.2.1). These are handled by chain INPUT of the firewall. As we talk about ICMP echo request packets here, this is no surprise as it is the default setting of OpenWRT's firewall to accept incoming ICMP on any interface

Packets transiting the router from one interface to another are handled by firewall chain forward, and it seems that in this case ICMP echo requests are not permitted, which is also no surprise.

So you can basically either add tun_c_rut955_ovpn_client as another interface to zone LAN, which means that the firewall won't interfere into communication between the actual LAN subnet and the tunnel (so no protection of one of them from bad guys on the other one), or you can create a dedicated zone for the tun_c_rut955_ovpn_client and define your own rules for forwarding between the zones.

This may not be enough, though. The host 192.168.2.34 may have a firewall on itself which prevents it from responding to pings not coming from its own subnet.

It is hard to guess your knowledge, so if I explain something elementary or, vice versa, I don't explain enough, sorry for that and give me a corresponding feedback.

My knowledge is limited indeed.

I note in the Teltonika > Traffic rules:

1) allow-ping from any host in wan, to any router IP on this device, input chain
2) allow-vpn-traffic from any host in wan, to any router IP on this device, input chain

I turn off the firewall on the 192.168.2.34 and I can ping from the server !!!!!!!!!!!

OK, but unless you put the interface representing the tunnel into a zone, only the default rules apply, which say REJECT for forward.

The zone concept just simplifies the rules - traffic between all interfaces in the same zone is unrestricted, whereas the rules for forwarding from any interface in one zone to any interface in another zone are defined in the source zone's forward chain; input and output chains of each zone control router's own incoming traffic from any interface in that zone and router's own outgoing traffic to any interface in that zone. So you don't need to set up individual rules per particular interface or IP address if you don't want to.

So as suggested by Jorge, by creating a new zone called VPN, adding the tunnel interface into it, and setting the forward rule VPN->LAN to ACCEPT you allow any client at the the Mikrotik side to establish new connections to servers in Teltonika's LAN; to permit clients in Teltonika's LAN to establish new connections to servers at Mikrotik side, you have to set the forward rule LAN->VPN to ACCEPT. If you don't need to restrict access between hosts in the LAN subnets of Mikrotik and Teltonika, this is all you need.to do at the Teltonika end; Mikrotik's firewall must also permit the same types of connections so that the end-to-end connections would succeed.

Mikrotik's firewall is less "pre-cooked" than OpenWRT's one, you have to set it up at somehow lower level, but on the other hand it uses the interface-list concept which is very close to the one of zones, and it implements the address-list idea which is a great way to allow use of a single rule for a group of otherwise unrelated addresses.

As your suggestion I set the following rules for Teltonika:
vpn to lan accept forward traffic
lan to vpn accept forward traffic

I try to connect a computer from the server lan (with putty or winscp) to the computer 192.168.2.34 with its firewall disable: no success (but ping ok).
I also tried filezilla but filezilla uses udp -> no success -> normal

For the time beeing only the ping command can access to a client computer.

And always the message "write to TUN/TAP:invalid argument (code=22)" every x minutes in the Teltonika log.

Just fyi..
I have Teltonika to Mikrotik working fine with pure ipsec.. super simple and avoids the tcp/udp problem with the ovpn.
let me know if interested...

Hello Jean-Philippe,

I see you made good progress with Sindy, that's great, we are almost there.

I would recommend doing a tcpdump on the Teltonika to confirm the packet flow. For example you could capture on the tunnel interface using:
, try to connect and check if packets are coming and going (I had a bad experience using host and protocol filters on this device so I would avoid using it).

About the invalid argument issue, I tryed your config in my setup and didn't have that error, are you using last firmware version on teltonika (RUTXX_R_00.06.04)? All points to a lzo config option problem as you said.

Regards.

Jorge.

@csalcedo
Yes, with a great interest !
If you could send me (by MP) the both configs ...
Thanks by advance
best regards,

jean-philippe

@jorgito

Thank you for your compassion !
Yes, I have the 00.06.04 version

tcpdump -nn -i tun_c_rut955_ovpn_client returns:
no such device exists

ip link show display for tun...client:
... mtu 1500 qdisc fq_code1 state UNKNOWN mode DEFAULT group default qlen 100
ip a display:
same line + link/none + inet 172.22.22.2/24 brd 172.22.22.255 scope global ...

Note: solved for tcpdump, the name is too long: tun_c_rut955_ov must be written

Other question:
Shall I modify the route for the whole client and server PCs ?

Hello,
traceroute 192.168.2.34 from a serve-side pc stops after 172.22.22.2
ok if I disable the 192.168.2.34 firewall

ssh -vv jpc@192.168.2.34 connection refused if firewall disable
stays blocking in connecting ... if firewall enable

From the server: currently only the ping messages go thru the tunnel until the pcs if its/their firewall is/are disabled

Hello,
I installed ssh on 192.168.2.34, created an incoming rule for port 22
RUT955: lan to vpn accept masquerading=yes / vpn to lan accept masquerading=yes
Everything is ok: ping, traceroute, ssh, winscp from 192.168.2.34 and from any server-side machines
- filezilla gives still an error
- openvpn information on the rut955 always empty


Thank you very much to Jorge and sindy !

What could I still test to be sure ?

Hello,
I installed ssh on 192.168.2.34, created an incoming rule for port 22
RUT955: lan to vpn accept masquerading=yes / vpn to lan accept masquerading=yes
Everything is ok: ping, traceroute, ssh, winscp from 192.168.2.34 and from any server-side machines
- filezilla gives still an error
- openvpn information on the rut955 always empty


Thank you very much to Jorge and sindy !

What could I still test to be sure ?

Hi Jean-Phillipe,

I think masquerading=yes on the RUT955 is causing some problems (and solving others), because you are doing a NAT to every incoming and outgoing connection replacing its origin.
The Filezilla problem should be the typical "FTP behind a NAT" problem with Active mode, can you confirm if you are using FTP Active or Passive mode? (good explanation on the difference here)
It would be great if you could disable masquerading on the RUT955, can you post your Mikrotik's "/ip firewall" configuration rules? Because maybe the problem is in the Firewall on the MK side.

About the RUT955 status information, I have the same problem and my VPN works great so I think it is a GUI bug that has to be addressed to our Lithuanian friends...

Regards.

Jorge.

Hello Jorge,

Filezilla: I am using SFTP, not FTP. FTP is in passive mode.

/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=established,related
add action=accept chain=input disabled=yes in-interface=ovpn-vers-eison
add action=accept chain=forward disabled=yes in-interface=ovpn-vers-eison
add action=accept chain=input comment="ICMP ping rule" dst-limit=30,30,dst-address/1m40s in-interface=combo1 limit=30,30:packet protocol=icmp
add action=accept chain=input comment="Allow rule for local network" src-address=192.168.1.0/24
add action=accept chain=input comment=established,related connection-state=established,related
add action=accept chain=input comment="Pour TV7" protocol=igmp
add action=accept chain=input comment="Pour TV7" in-interface=bridge1
add action=accept chain=input comment="allow IPsec NAT" dst-port=4500 protocol=udp
add action=accept chain=input comment="allow IKE" dst-port=500 protocol=udp
add action=accept chain=input protocol=ipsec-esp
add action=accept chain=input comment="Allow OpenVPN" dst-port=1194 protocol=tcp
add action=drop chain=input
add action=drop chain=forward comment="Drop Ransome Public IP" dst-address-list=ransome
add action=drop chain=forward comment="Drop SMB" disabled=yes dst-port=139,445,3389 protocol=tcp
add action=accept chain=forward connection-state=established,related
/ip firewall mangle
add action=mark-connection chain=forward connection-state=new dst-port=5060 new-connection-mark=sip-connection passthrough=yes protocol=tcp
add action=mark-connection chain=forward comment="exclure le port de deluge !" connection-state=new disabled=yes new-connection-mark=rtp-connection passthrough=yes
8000-30000 protocol=udp
add action=mark-packet chain=prerouting comment="Mark packets for deluge" dst-port=49160 in-interface=combo1 new-packet-mark=deluge-upload passthrough=no protocol=
add action=mark-packet chain=postrouting dst-port=49160 new-packet-mark=deluge-download out-interface=combo1 passthrough=no protocol=udp
/ip firewall nat
add action=accept chain=srcnat disabled=yes dst-address=192.168.2.0/24 src-address=192.168.1.0/24
add action=masquerade chain=srcnat out-interface=combo1
add action=dst-nat chain=dstnat comment="Deluge windows" dst-port=49160 protocol=tcp to-addresses=192.168.1.40 to-ports=49160
add action=masquerade chain=srcnat disabled=yes out-interface=ovpn-vers-eison

Other "problem": ssh from windows to linux with cmd.exe
Login correct but char coming from linux are strange.
In the log I have "console doesn't support the ansi parsing"
Note: ssh from linux to windows with a terminal is correct
http://192.168.2.34 does't answer

Jean-philippe