Firewall Mangle rule shows no traffic

RouterOS Beginner Basics
1

Hi,
I am reasonbly sure the problem is with me.

Setup a Firewall Mangle rule to mark connection and mark packet for ‘any port’ 1194. Make a call, no traffic shows. Tried adding src address and then dest address, still no traffic shows.

Tried again and used Packet Sniffer and there of course the traffic shows.


The rules are:

add action=mark-connection chain=prerouting comment=VPN connection-mark=VPN \
    new-connection-mark=VPN port=1194 protocol=udp
add action=mark-packet chain=prerouting new-packet-mark=VPN packet-mark=VPN \
    passthrough=no port=1194 protocol=udp

Also tried the above using port=1026

Looking at the packet in packet sniffer it shows SRC 192.168.10.11 port 1026 DST xx.xx.xx.xx Port 1194

Due to our SIP phones using OpenVPN it would not make sense trying to mangle port 5060.

But what I don’t either is if I add either the SIP Phone IP address in SRC or the DEST IP in DEST, it still shows no traffic.

Thanks for your help.

2

What interfaces are involved in the traffic flow? If it doesn’t leave a bridge or switch group I think you need to ensure it gets to the firewall, i.e. fix that in the bridge settings.

Adding a trailing mangle LOG target rule might be useful too - packets should show there.

3

You need to change protocol to tcp. OpenVPN can be either TCP or UDP, in RouterOS only TCP is supported.

4

There’s no evidence of TS running the server on RouterOS though, so I’d assume it’s a remote UDP OpenVPN instance.

5

Should it not be:

add action=mark-connection chain=prerouting comment=VPN \
    new-connection-mark=VPN port=1194 protocol=udp
add action=mark-packet chain=prerouting new-packet-mark=VPN connection-mark=VPN \
    passthrough=no

Matt.

6

Hi,
What I did now to retest was the following. On one SIP phone here, changed it to stop using VPN and just use normal insecure communications.

Even using the VoIP mangle rule doesn’t catch it. The reason seems to be RTP (the actual voice) because 5060 is NOT where voice goes, 5060 is for registration/authentication.

Since we use ports 10251-15000 for RTP I made the following Firewall/Mangle rules:

add action=mark-packet chain=prerouting comment="voip-out packet mark RTP" new-packet-mark=RTP \
    passthrough=no port=10251-15000 protocol=udp
add action=mark-packet chain=prerouting comment="voip-in packet mark RTP" new-packet-mark=RTP \
    passthrough=no port=10251-15000 protocol=udp

Now when I make a phone call I see the 90Kb stream showing up under RTP in Queue List.

The VoIP Mangle rule of:

add action=mark-connection chain=prerouting comment=VOIP log=yes new-connection-mark=VOIP passthrough=\
    no port=5060-5064 protocol=udp
add action=mark-packet chain=prerouting new-packet-mark=VOIP passthrough=no port=5060-5064 protocol=\
    udp

shows nothing in the Queue List. Also tried to change the VoIP Mangle rule to

ports any 5060-5064,10251-15000

But for some reason, see nothing in Queue List. As if it won’t look at anything past the comma.

It would be nice if the Firewall Mangle Rule could include both 5060-5064 and 10251-15000 so the Queue List can be shortened a bit.

7

Did you activate the connection tracking ?

8

Hi,
Where is the connection tracking?

9

Ip firewall connections.

10

Hi,
I think you are wrong. I write this because of the following from the /log

oct/14 23:34:56 firewall,info vpn prerouting: in:ether2 out:(none), src-mac 00:15:65:33:ba:d0, proto UDP, 192
.168.10.11:1024->xxx.xxx.xxx.xxx:1194, NAT (192.168.10.11:1024->99.238.86.174:1024)->xxx.xxx.xxx.xxx:1194, len 409
oct/14 23:34:57 firewall,info prerouting: in:ether1-gateway out:(none), src-mac 00:14:f1:eb:ec:d9, proto UDP,
xxx.xxx.xxx.xxx:5060->99.238.86.174:1025, NAT xxx.xxx.xxx.xxx:5060->(99.238.86.174:1025->192.168.10.8:5062), len 5
85

What I do find strange is it picks up on the 192.168.10 subnet, but in the phone the setup for the SIP server is 10.8.0.1. I must presume that the ovpn setup file that is in the phone has a lot to do with this.

11

I think your problem is the passthrough=no on the prerouting chain. Put the second part (to mark the packets) in the postrouting chain. You could also change the passthrough to be yes.

I’d also remove the port= part as its not required.