top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

How to mark RTSP child connections with different value.

0 votes
375 views

I am trying to apply some QoS for RTSP traffic forwarded by an OpenWRT gateway (Attitude Adjustment + patches).

The RTSP helper is loaded and successfully expects the incoming streams, which arrive at the client in the NAT'ed lan. Multiwan is also active, this is using part of the marking bits (i.e. 0xF0000000 ) to select the appropriate routing table.

In this product, interface drivers sort outgoing frames in different queues based on part of the marking bits (i.e. 0x0F000000). Netfilter rules are present in the forwarding chain to mark streams destined at tcp port 554 with specific qos value (i.e 0x08000000). This mark is saved as connmark at the end of the forwarding chain, and restored at the start. If after restore, the mark is still 0, only then all qos rules are being evaluated.

When RTSP helper successfully predicts incoming streams, these childs automatically inherit the connection mark, and as such will be marked with the same mwan and qos bits as the parent connection. For mwan this is ok, but for qos a different (higher) value would be preferred (i.e. 0x0A000000). Ideally, the child streams should be assigned a specified connmark value when RTSP helper is predicting them.
A generic solution that would be applicable to parent-child connections handled by other helpers would be nice :-)

So ... what are my options ?

posted Jun 23, 2014 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+1 vote

What about matching the packets of the RTSP streams and MARK/CONNMARK them when they arrive ?

-m state --state RELATED : match the first packet of related streams
-m conntrack --ctstatus EXPECTED : match all packets of expected streams
-m helper --helper "rtsp" : match all packets related to the RTSP helper

answer Jun 23, 2014 by Daler
Similar Questions
0 votes

I have a setup* in which I have a server with multiple virtual network interfaces (vif1 .. vifX) that are connected (bridged) to one virtual machine each (vm1 .. vmX) which all have the same IP and MAC (let's say 192.168.1.100 resp. 00:11:22:33:44:55). In addition to that my server also has one regular network interface (eth0) connected to the rest of my network (10.0.0.0/16).

Now I would like to be able to provide NAT-like capabilities such that every packet coming from vm1 reaches the regular network as coming from 10.0.1.1, every packet coming from vm2 as 10.0.1.2 and so on. Of course, packets coming from the network destined towards 10.0.1.x should also be correctly translated by the server such that vmX will receive them.

From what I understand I could use ebtables with the snat-target to rewrite the MAC addresses for the vifX bridges, such that the remaining network would see at least a different MAC address per VM. However, I cannot see an easy solution to rewrite the IP. Using iptables nat-table and the snat-target will not work, since I would need to also filter on the source-mac or incoming device, but the snat-target is only available on the POSTROUTING chain.

One possible to solution would be to write a small program that listens on a rawsocket on every interface, rewrites packets and re-sends them on the correct interface, but I'd rather avoid that and use standard tools instead.

I would be very grateful for ideas/tips,

+1 vote

I'm looking at a strange phenomenon that occurs on an iptables firewall. There is a DNAT rule configured that maps a public IP to a private one where a web serve is listening. Normal request operate as expected that is the destination ip is modified to the private one when the request arrives at the firewall and on the response packet the private ip is mapped back to the public one.
What I noticed though is that for some response packets the source ip is *not* mapped back to the public ip and instead tcpdump shows that the packets are sent out with the private source ip. The thing all these packets have in common is that they have the RST flag set.

What could be the reason for this? Is there some particular iptables behavior that could explain this?

+1 vote

Recent versions of the Linux kernel and the libnftnl library define nft expression types with the names "match" and "target". However, I could not find any reference to these expression types in the code of the nft user space utility, but only in the code for iptables.

Is it possible to access iptables matches and targets from rules defined with nft, or is this not intended?

+1 vote

I wanted to make a white list using the settings below.

iptables -N wanout
iptables -I FORWARD -i `nvram get lan_ifname` -j wanout

iptables -I wanout -m mac --mac-source 01:26:f7:46:71:4b -j ACCEPT
iptables -I wanout -m mac --mac-source d2:37:b5:f2:39:f3 -j ACCEPT

iptables -I wanout -d gamepedia.com -j ACCEPT
iptables -I wanout -d toysrus.com -j ACCEPT

iptables -A wanout -j REJECT --reject-with icmp-proto-unreachable

So the boxes with the MACs specified are exempt from blocking. The domains "gamepedia.com" and "toysrus.com" are accesible to all.

But the problem is that those domains pulls stuff in from other domains using or something, which makes the IPTable block the loading of the website to complete.

How do I deal with that in the best way? I don't want to look up everything they pull in and white list that as well. Also it might change.

Isn't there a way to say "accept all from this domain, even unrelated stuff"?

+2 votes

I have some issue with module (owner) in iptables v1.4.14

Current rule fails:
iptables -t nat -A OUTPUT -o eth0 -p tcp -s x.x.x.x -m owner --gid-owner usergroup -j DNAT --to-destination x.x.x.x:80;
I tried to use numeric gid, it failed too..

But this rule works fine:
iptables -t nat -A OUTPUT -o eth0 -p tcp -s x.x.x.x -m owner --uid-owner user -j DNAT --to-destination x.x.x.x:80;

Is it a BUG or I am missing something?

...