When I try to connect from 192.168.1.150 to 213.206.94.83, I see in ConnTrack, that the connection is marked ‘dip_kav’ and TCP State is ‘syn received’. Then my program says ‘Connection timeout’. But when
Oh, thank you But what’s wrong with that settings? I don’t want type IPs everywhere, I have more complicated structures, and I’d like to write them using connection and packet marks
What actually doesn’t work, or rather works too good, is the rule translating the connection-mark to routing-mark. You’ve only got a single (default) route in the routing table dip-kav, and your action=mark-routing rule doesn’t care about in-interface. So since the response packets for 192.168.1.150 arriving via WAN get routing-marked with dip_kav, they are also routed via the WAN gateway. The connected routes (distance=0) do not override the routing-mark.
So as you expressly don’t want to match on IP addresses, use something like in-interface-list=!WAN in the action=mark-routing rule.
@nichky, in your case, is the Mikrotik with these rules the OpenVPN client or server? Or none of the two and it just forwards someone else’s OpenVPN connections? In any case, assigning a connection-mark alone has no effect on routing, you have to translate the connection-mark to a routing-mark at some point. If the Mikrotik itself is a client or server for OpenVPN, you may have to assign the connection-mark, and you definitely have to assign the routing-mark, in chain output in mangle, not in chain prerouting.
The MT that has this rules is OVPN -Server.
What is my goal here:
by using this rules i want to masq the traffic going to the ovpn clients, so i what that to allow me to get access to them, without adding any routes from the client perspective.
OK, so you need to src-nat the payload traffic (sent inside the tunnel). But your action=mark-connection rule matches on protocol=tcp src-port=1198, which seems to refer to the transport packets of the OpenVPN (those forming up the tunnel). As the IP firewall has no knowledge about the relationship between the payload packets and the transport ones, this idea fails. On top of that, the action=mark-connection rule itself actually never matches because the transport packets are sent by the router itself, not forwarded from ether9, and because packets sent by the router itself never get to chain prerouting. That’s why I was asking about the role of the router in the overall OpenVPN topology.
So to get what you actually want, forget about connection marking, and do the following (in exactly this order):
/interface list add name=ovpn-client
create an action=masquerade rule matching on out-interface-list=ovpn-client just before or just after the current individual rules matching on out-interface=
__
/ppp profile add copy-from=[/interface ovpn-server server get default-profile] name=ovpn-profile interface-list=ovpn-client
at a time when a short-time disconnection of all clients is acceptable: /interface ovpn-server server set default-profile=ovpn-profile (if you refer to customized /ppp profile rows from the /ppp secret rows, add interface-list=ovpn-client to these customized profiles instead).
As you change the OpenVPN server setting, the server terminates all connections and the clients reconnect (pity but that’s how it is currently implemented). Each time a client connects, the dynamically created interface will be added as a member to the interface list indicated in the profile, so the new action=masquerade rule will handle connections established via this dynamic port. I’m not sure whether this works also if you have manually created static /interface ovpn-server rows for the clients, you have to try - if it doesn’t, add these static interfaces as members to the interface list manually, or just remove the static items if they had no other purpose than the masquerade rule.
I didn’t need to touch this one “/interface ovpn-server server set default-profile=ovpn-profile”.
As fas as i know /ppp profile has priority than
/interface xxx-server,
is that corect?
ne znam od koju dizavu si tachno,ali kad idem na balkanu pozvachute, svaka chas majstore!!
more precisely, the profile value from /ppp secret overrides the default-profile value from /interface xxx-server server. So yes, if you specify a profile on each /ppp secret row, no need to change the “last resort” profile associated to the server.
To što malo pričam jezik još ne znači da sam iz Balkana Ali imam ga bliže nego sada ti.
I just came to say thank you. In the past couple of years, whenever I ran into issues with MikroTik configurations, very often the solutions are found in your replies. You, as well as a very few other gurus on this forum, can always explain complicate issues in a way for newbies like me to not just get something to work, but to understand exactly why. This particular example of connection marking in mangle rules had been bothering me for days. I read a lot of online discussions and watched a lot of videos; it only clicked when I saw your explanation.
Really appreciate it.
But what’s wrong with that settings? I don’t want type IPs everywhere, I have more complicated structures, and I’d like to write them using connection and packet marks