Community discussions

just joined
Topic Author
Posts: 3
Joined: Sat Aug 31, 2019 2:07 pm

ROS losing inbound packets from VPN

Wed Sep 11, 2019 3:06 am

I have remote VPS instance with OpenVPN 2.4.7 installed (Debian 9) and set.
Forwarding is set up and non-mikrotik clients can connect and route traffic through this tunnel without any additional setup.

Then, I am trying to hook up my hAP ac^2 (ROS 6.45.5) via VPN (not to forward everything by default).

OpenVPN server is configured to run in tun/tcp without compression and utilizing SHA1/AES256-CBC without ta-auth.
IPv6 is not set up too (mostly because I can't get it work on MT too).

I can ping remote server using its address in OpenVPN subnet and when I try to ping hosts from public network (e.g. tcpdump on VPS show outgoing traffic from MT client to and back to tunnel.
Packet sniffer from MT also show both tx and rx packets but ping show timeouts.

Before moving forward with configuration I must enlist some cloaked IP addresses:
REM.SRV.PUB.IP - public IP of remote server where VPN server is running
LOC.MTK.PUB.IP - public IP of MikroTik router (now it is dynamic but not NATed though my ISP can't guarantee it)
VPN.INT.SUB.0/24 - subnet which OpenVPN server uses
VPN.INT.SUB.1 - OpenVPN server internal address
VPN.INT.SUB.4 - MT client internal address
In ccd file of OpenVPN server I have this string to push static IP to OpenVPN client (since dynamic configuration messes up with routes on MT):
ifconfig-push VPN.INT.SUB.4 VPN.INT.SUB.1
OVPN client configured this way:
/interface ovpn-client
    add certificate=<crt_file_name> cipher=aes256 connect-to=REM.SRV.PUB.IP mac-address=XX:XX:XX:XX:XX:XX name=<vpn_name> port=1194 profile=<vpn_profile> user=<cert_cn> verify-server-certificate=yes
/ppp profile
    add name=<vpn_profile> use-compression=no use-encryption=yes use-ipv6=no use-mpls=no
After digging through documentation and forums I tried to mark VPN traffic using mangle rules and force default route using this mark:
/interface list
    add name=VPN
/interface list member
    add interface=<vpn_name> list=VPN
/ip firewall address-list
    add address=VPN.INT.SUB.0/24 list=ovpn-addr
/ip firewall mangle
    add action=mark-connection chain=prerouting connection-mark=!ovpn in-interface-list=VPN new-connection-mark=ovpn passthrough=yes
    add action=mark-routing chain=prerouting connection-mark=ovpn new-routing-mark=ovpn passthrough=yes src-address-list=ovpn-addr
/ip firewall nat
    add action=masquerade chain=srcnat out-interface-list=VPN routing-mark=ovpn src-address-list=ovpn-addr
/ip route
    add distance=1 gateway=<vpn_name> routing-mark=ovpn

Other firewall rules are left as is (except disabling access to for capsman).
Apparently, disabling fasttrack rule is helping but I don't want to completely disable it.

So, do I need to bypass FT somehow?
Also I understand how it should affect routing but I can't figure out why is it recommended to use PBR for VPN connection on MT?
Everyone does it but there's no viable explanation.

Thanks in advance.
Forum Guru
Forum Guru
Posts: 4631
Joined: Mon Apr 20, 2009 9:11 pm

Re: ROS losing inbound packets from VPN

Fri Sep 13, 2019 6:02 am

If disabling fasttrack rule solves the problem, then you just need to add some additional conditions to it. I'm too lazy to think about specific addresses right now, but some examples would be connection-mark=no-mark to skip marked connections, dst-address=!<VPN subnet> or dst-address-list=!<more VPN subnets> to exempt some destinations. Both combined should cover both directions and do what you need.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply.
just joined
Topic Author
Posts: 3
Joined: Sat Aug 31, 2019 2:07 pm

Re: ROS losing inbound packets from VPN

Sat Sep 14, 2019 9:32 pm

If disabling fasttrack rule solves the problem, then you just need to add some additional conditions to it.
I found out that issue wasn't with FT but because of
So, it was solved immediately when it is turned off though it doesn't seem to be secure.

All mangle rules aren't even necessary in this case and only route through VPN interface seem to be enough.

Who is online

Users browsing this forum: Google [Bot], MSN [Bot] and 18 guests