Community discussions

MikroTik App
 
rplant
Member Candidate
Member Candidate
Topic Author
Posts: 282
Joined: Fri Sep 29, 2017 11:42 am

Possible Feature Request Output NAT Reconnect

Wed Sep 23, 2020 10:12 am

One issue with wireguard.
...
Actually, on further review, its only when the output needs to go via a non default route.
(route marking needed), and also happens with Openvpn (and perhaps others)
sstp (tcp) using the same connection and route marking works correctly.

Perhaps an alternative to changing the vpn(s) code might be to create a
new Action for output. It is similar to a source NAT action, probably
only useful with UDP, maybe GRE. It would also run very early on the
output (In mangle or maybe raw).

Action = Reconnect
connection Mark = MyMark
Source IP Address = 192.168.45.2
[Optiona] Source Port=13235

The action is a test and optionally set action.
It's function would be for this case something like:

If by changing the selected Output Chain packet Source IP address to
192.168.45.2 and port to 13235, the resulting packet would match an existing
connection having a connection mark of MyMark, then make that change.

Following output chain items could then process based on it's newly
reattached connection mark.
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: Possible Feature Request Output NAT Reconnect

Wed Sep 23, 2020 4:19 pm

You should probably explain in more details what's the problem. I'm trying to understand it, but no luck so far.
 
rplant
Member Candidate
Member Candidate
Topic Author
Posts: 282
Joined: Fri Sep 29, 2017 11:42 am

Re: Possible Feature Request Output NAT Reconnect

Sat Sep 26, 2020 1:58 pm

You should probably explain in more details what's the problem. I'm trying to understand it, but no luck so far.
Yes, fair enough.
Hopefully the following makes some sense.

With reference to the image below which is similar (simplified) to the one I am using.
If the client attempts to connect via a VPN to R1 via RMain 1.1.1.1 it works ok with SSTP,
The connection marking, and route marking cause the packets to exit the same way they came in.
(via RMain)

However with OpenVPN and Wireguard it doesn't work. Logging the output packets shows them in the routeros output chain with an IP address of 192.168.1.20, and they head out via R4G (and will get blocked at the client firewall) This sort of makes sense, as routing like this is likely to be somewhat uncommon for most cases where wireguard and openvpn are used.
I think that to get it to work properly the VPN's would have to keep (additional) state and remember which IP address to attach to specific outgoing packets rather than just letting the operating system take care of it.

I was thinking a short term fix that might be good enough (it still has issues), would be to create a mangle action that would change the output Source IP address and reconnect the packet to the existing connection.

For the drawing below a rule something like:

chain=Output, connection-mark=no-mark, source ip-address=192.168.1.20
action=attempt reconnect source-ip=192.168.2.10 connection-mark=from-2

It would test to see if changing the source ip address of the packet to 192.168.2.10 would cause it to match a connection with mark from-2
  • If it did match, it would change the source-ip of the packet to 192.168.2.10 and do whatever is required to connect it to from-2, Which is used by a later mangle rule to cause the route mark to be changed to via-2 so the packetgoes out via RMain.
  • if not match, it would not change the packet.
Actually looking at the routeros packet flow, maybe this would be better in the raw chain??

Note: It is quite possible I have just messed up my routing somewhere, but the fact that SSTP works correctly gives me some small amount of confidence.

Thanks
DualWan3.png
You do not have the required permissions to view the files attached to this post.
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: Possible Feature Request Output NAT Reconnect

Sat Sep 26, 2020 10:38 pm

Such behaviour could happen if R1 would try to send something to client as not part of established connection. So it can't happen with SSTP or TCP OpenVPN, because they use actual connection established from client to server.

It could happen with UDP (with both OpenVPN and Wireguard), if conntrack's entry for "connection" times out and server sends something to client after that. So if there's some traffic in tunnel, it should be ok. If not, then it's up to keepalives. It would fail if they are disabled or if time between them is longer than conntrack's timeout for UDP.

If it's not this, then it looks like either weird bug or some misconfiguration. In any case, you shouldn't need new action for this, new connections (as conntrack would see them) from server to client can be handled with existing mangle output or srcnat.

Who is online

Users browsing this forum: Google [Bot] and 22 guests