I’m trying to configure my new RB201 and I’m new to MicroTik. What should be something relatively simple has me scratching my head.
I have an OpenVPN server to allow offsite users to connect back to the local network. The OpenVPN server has two NICs – one is internet-facing and one is connected to the local network. As I’m sure many of you are familiar with, OpenVPN assigns a (default) 10.8.x.x address as well to devices connecting via VPN..
With the previous lower-end gateway device I was using, I just added a static route to send VPN traffic from the local network to the 10.8.x.x network using the IP of the local network NIC on the OpenVPN server (eg. 192.168.75.100) as the gateway, and VPN connections to devices on the local network worked fine.
I’m attempting to do the same on the RB201, but it doesn’t seem to be routing that traffic properly. I’m very new to MicroTik and I’m probably missing something obvious, but I can’t quite figure out what it is. What am I missing?
You may be missing the need to add a dedicated route to the OpenVPN server which overrides the default one. Because depending on how your /interface ovpn-client is configured regarding add-default-route or how you have configured the defaut route manually, it may happen that as soon as the VPN interface goes up, also the transport packets of the OpenVPN take the default route through it, so they die on TTL expiration.
If my guess is wrong, follow the suggestion in my automatic signature.
Other products often try to relieve the users from the burden of logical thinking so they silently add the exception route to the routing table. WIth Mikrotik which people willingly choose because it gives them manual control over almost every aspect, doing the same would be counter-productive in some cases.
Regarding the routes on the VPN server, it's the same machine with no config changes. Everything works with the old gateway device.
Below are the exports with relevant IPs obfuscated. I added the route via WebFig, although I had the same result (which is to say that it didn't seem to work) when adding the route via Terminal as well.
Sorry, I’ve misunderstood your OP as if the RB was an OpenVPN client in the whole setup.
So looking at it one more time - are the other devices you want the ovpn clients to talk to also in 192.168.1.0/24?
Because the point is that if they are and they themselves don’t have routes to 10.8.0.0/24 via 192.168.1.2, they send packets for 10.8.0.0/24 to the 'Tik, and the 'Tik finds out that it has to send them to another router in the same subnet from which they came. So it normally does forward the packets but for each of them it should send an icmp redirect, informing the sender that the network is better reachable directly using that other router, and some devices behave funny when they receive the redirects.
So a fast remedy could be to disable sending redirects in IP settings on Mikrotik, but it is a general setting, so if it helps it might need something better as a final solution.
The entire 192.168.1.0/24 network should be able to send to the 10.8.0.0/24 network. The goal is to have the “road warriors” coming in over the VPN able to access to the devices on the local 192.168.1.0/24 network. Apparently the previous gateway device made a lot of assumptions for me without telling me.
I appreciate your assistance with this very much. I love the fine-grained control, but I’m still new to it and there’s a bit of a learning curve. Other than this particular issue, I very much like the device.
I’m missing the information whether disabling of sending redirections in the IP → Settings has made it work for you or not.
If not, I suppose you can remove one Ethernet port on the Mikrotik from the LAN bridge, connect it to the VPN server, and attach to it another IP subnet (e.g. 192.168.2.0/24) by assigning the 192.168.2.1/24 to that interface on the 'Tik, change the OpenVPN server’s address to 192.168.2.2, tell the OpenVPN server that 192.168.1.0/24 is available via 192.168.2.1 and tell the Mikrotik that 10.8.0.0/24 is available via 192.168.2.2?
Sorry, I should have just exported from the root the first time. Here's the entire configuration (again, relevant values obfuscated) before disabling redirects. Disabling the redirect as you suggested seems to have had no effect.
[admin@MikroTik] > export
jul/26/2018 12:17:44 by RouterOS 6.42.6
software id = PTY0-WSW1
model = 2011UiAS
serial number = XXXXXXXXXXXX
/interface bridge
add admin-mac=xx:xx:xx:xx:xx:xx auto-mac=no comment=defconf fast-forward=no name=bridge
/interface ethernet
set [ find default-name=ether2 ] name=ether2-master
set [ find default-name=ether6 ] name=ether6-master
/interface list
add exclude=dynamic name=discover
add name=mactel
add name=mac-winbox
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=dhcp ranges=192.168.1.100-192.168.1.149
/ip dhcp-server
add address-pool=dhcp authoritative=after-2sec-delay disabled=no interface=bridge name=defconf
/snmp community
set [ find default=yes ] addresses=0.0.0.0/0
/interface bridge port
add bridge=bridge comment=defconf interface=ether2-master
add bridge=bridge comment=defconf interface=ether6-master
add bridge=bridge comment=defconf hw=no interface=sfp1
add bridge=bridge interface=ether3
add bridge=bridge interface=ether4
add bridge=bridge interface=ether5
add bridge=bridge interface=ether7
add bridge=bridge interface=ether8
add bridge=bridge interface=ether9
add bridge=bridge interface=ether10
/ip neighbor discovery-settings
set discover-interface-list=discover
/interface list member
add interface=sfp1 list=discover
add interface=ether2-master list=discover
add interface=ether3 list=discover
add interface=ether4 list=discover
add interface=ether5 list=discover
add interface=ether6-master list=discover
add interface=ether7 list=discover
add interface=ether8 list=discover
add interface=ether9 list=discover
add interface=ether10 list=discover
add interface=bridge list=discover
add interface=bridge list=mactel
add interface=bridge list=mac-winbox
/ip address
add address=192.168.1.1/24 comment=defconf interface=ether2-master network=192.168.1.0
add address=aaa.bbb.ccc.ddd/24 interface=ether1 network=aaa.bbb.ccc.0
/ip dhcp-client
add comment=defconf dhcp-options=hostname,clientid interface=ether1
/ip dhcp-server network
add address=192.168.1.0/24 comment=defconf gateway=192.168.1.1 netmask=24
/ip dns
set allow-remote-requests=yes servers=vvv.www.xxx.yyy,vvv.www.xxx.zzz
/ip dns static
add address=192.168.1.1 name=router
/ip firewall filter
add action=accept chain=input comment="defconf: accept ICMP" disabled=yes protocol=icmp
add action=accept chain=input comment="defconf: accept established,related" connection-state=established,related
add action=drop chain=input comment="defconf: drop all from WAN" in-interface=ether1
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related" connection-state=established,related
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=ether1
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface=ether1
/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set irc disabled=yes
set h323 disabled=yes
set sip disabled=yes
set pptp disabled=yes
set udplite disabled=yes
set dccp disabled=yes
set sctp disabled=yes
/ip route
add distance=1 gateway=aaa.bbb.ccc.1
add check-gateway=arp distance=2 dst-address=10.8.0.0/24 gateway=192.168.1.2
/system clock
set time-zone-name=xxxxxxxxxxxxxxxx
/system routerboard settings
set silent-boot=no
/tool mac-server
set allowed-interface-list=mactel
/tool mac-server mac-winbox
set allowed-interface-list=mac-winbox
[admin@MikroTik] >
I did manage to make some progress and get traffic flowing properly by disabling the “Drop Invalid” rule on the firewall. I can’t think that this would be good to leave turned off permanently, and I realize that it’s typically a good thing to drop invalid packets. Is there a way to allow just the “invalid” packets for the VPN and drop the rest?
I didn’t think about the firewall but yes, it clarifies the behaviour. The point is that the firewall monitors the connections and evaluates whether a given packet fits into the connection state, and action=drop connection-state=invalid causes packets which do not fit the expected connection state to be dropped. Now what happens is that the packets from the client device to the VPN gateway go through the Mikrotik’s L3 handling, but the responses don’t because the VPN gateway and the client device are in the same IP subnet. So the initial SYN packet establishes a connection, but until the connection tracker can see a (SYN, ACK) response to it, any further packet from the client otherwise fitting that connection (same src address&port and same dst address&port like the SYN one) except a retransmission of the SYN is considered invalid. Which BTW also tells us that the sending device ignores the redirects when they are sent because instead of sending the further packets directly via the VPN gateway, it sends them to Mikrotik’s MAC address again, otherwise Mikrotik would be unable to drop them.
So by selectively disabling the “drop invalid” rule you get the traffic between the clients and the VPN gateway work while the firewall will act normally on other traffic, but for this VPN traffic the firewall will be completely bypassed. Depending on whether the purpose of the VPN is the “real” one (to interconnect LANs on various sites of the same company) or the “popular” one (to access some services in the internet from other than your ISP’s address and/or hide the contents and real destination of that traffic from your ISP), bypassing the firewall may or may not be what you actually want.
If you don’t mind bypassing the firewall, you can add a rule action=accept chain=forward dst-address=10.8.0.0/24 in-interface=ether2-master right before the action=drop connection-state=invalid one. If you want the packets from the VPN gateway to the client devices to be inspected by the firewall, use my suggestion from one of the previous posts, to set up a separate subnet for communication between the Mikrotik and the VPN gateway on a separate physical connection. But again, depending on the purpose of the VPN, you’ll have to configure the firewall rules accordingly.
It’s a case where VPN users need to access the local network behind the firewall.
I did attempt to add the rule that you suggested, however the router didn’t like it because the source port (ether2-master) was a slave. So I changed the rule to this
It’s not the same but it is similar enough to serve the purpose I didn’t have a look at the version you use so I got off-track by the ether2**-master** name suggesting that you still run a pre-6.41 version. So instead of in-interface=ether2-master, you could use in-interface=bridge, but you may as well keep your version of the rule.
I didn’t have a look at the version you use so I got off-track by the ether2**-master** name suggesting that you still run a pre-6.41 version. So instead of in-interface=ether2-master, you could use in-interface=bridge, but you may as well keep your version of the rule.