Hi, I've configured the mangle as source LAN addresses and WAN as destination, then mark connection, so I've created a source nat for marked packets with action masquerade. This work for videosurveillance and oher things, but doesn't work for Rustdesk, I can't understand why. The packet is mangled (I can see from counters), but NAT doesn't process it, it still on 0.
Yes PC hosts are ok, I can open connection if I use the LAN address, but I want to use the WAN address. Thank you for help
I've logged the mangle packets, it looks Rustdesk ask to connect by TCP and UDP, I've no idea then what it chose to use, but strange I have 0 counters on NAT.. NAT is not processing the TCP
SO I've created a second mangle for the UDP connection, and I market the packets, so I've add a NAT for marked packets, it didn't work and counters on magle to 0.
I needed to stop it because ether1 WAN starts to suffer for too many packets (loop)
You are (poorly) describing the settings you believe you made.
If you want assistance, post your actual configuration, so that willing helping mambers can see what you actually did, instructions here:
Forum rules - #5 by gigabyte091
Besides the config, please describe the requirements for traffic flow without any talk of the configuration, aka masquerade nat etc… Just what devices or users need to do what in terms of practial data flow.
ex client A coming in from the internet needs to see live video stream from camera A, on vlan X……..
Sorry mates to don't report, this is a classic configuration for hairpin, nothing special:
add address=192.168.1.0/24 list=LAN
add address=x.x.x.x list=WAN
add action=mark-connection chain=prerouting comment=Hairpin dst-address-list=WAN log=yes \
new-connection-mark="Hairpin TCP" passthrough=no protocol=tcp src-address-list=LAN
add action=mark-packet chain=prerouting disabled=yes dst-address-list=WAN new-packet-mark=\
"Hairpin UDP" passthrough=no protocol=udp src-address-list=LAN
add action=masquerade chain=srcnat comment="Hairpin TCP" connection-mark="Hairpin TCP"
add action=masquerade chain=srcnat comment="Hairpin UDP" disabled=yes packet-mark="Hairpin UDP"
The UDP is disabled. THis hairpin works for every program I've tested, but not working for Rustdesk, the strange thing is that I can see counters going on mangle, but no counters on the NAT, while other programs increase both. Rustdesk tries to connect by TCP and UDP, I've also post them on github to mae a test with Mikrotik
Sorry without seeing config, its only your opinion and I only work from facts.
1 Like
Leaving aside that it makes no real point to use connection marking in your case as only the initial packet of each connection is matched against the srcnat and dstnat chains of the firewall and the rest of the packets belonging to the same connection inherits the srcnat and dstnat treatment, you’ve said it yourself - as it is only Rustdesk traffic that is handled differently, there must be something specific in how you handle the Rustdesk traffic, or how the Rustdesk client memorizes the outcome of previous connection attempts.
As others have stated, you’ve only posted the part of configuration you assume to be relevant, but the issue is 99% hidden in the part of configuration you assume to be unrelated.
The contents of the initial packet of any TCP session does not depend on the application that is going to use that TCP session as a transport, so there can be no difference in the initial SYN packet between the Rustdesk ones and the other ones, except the addresses and ports used. So if the Rustdesk SYN packets do hit the mark-connection rule in mangle/prerouting but do not hit the masquerade rule in srcnat, the only possible explanation is that they get lost somewhere on the way between them. The candidates are dst-nat rules intended for other traffic to divert them elsewhere or filter rules dropping them.
Ahh so winter is over, the owl is out of hibernation. 