Scheduled inbound nat
-
Hi mates,
Ihave a trouble with nats.
I have 3 webcams (broadcasting with RTSP) inside my lan and I want them to stream through the same external port (1555) in different hours. I think I need to schedule the outbound nat rule but I can't find how.This is exactly what I need:
from 09:30 to 10 external port 1555 must point to lan address 192.168.1.21
from 10 to 10:30 external port 1555 must point to lan address 192.168.1.23
from 10:30 to 11 external port 1555 must point to lan address 192.168.1.25It's mandatory to use the same external port. How can I solve this?
Thanks in advance!
-
Firewall rules can have schedules applied to them, but I know of no firewall which can re-apply NAT rules to a schedule.
Perhaps it might help if you explained what you were trying to do exactly instead of asking for a supposed solution?
-
Well, it's easy.
I Have hired and external streaming service which broadcast my emission and I need to rotated my 3 webcams signal (inside lan) in a schedule. (swap to the next each half hour).
I cannot change the url or port in the streaming service, must be always the same.
So, I wanted to solve this through scheduled nat changes. :(
any better idea?Thanks in advance.
Firewall rules can have schedules applied to them, but I know of no firewall which can re-apply NAT rules to a schedule.
Perhaps it might help if you explained what you were trying to do exactly instead of asking for a supposed solution?
-
What about using a reverse proxy or load balancer? You could set a cron job on a proxy forwarder to target each webcam every half hour. The port forward would only have to point to the proxy and the re-targeting could be done from the proxy server itself.
-
Seems a good idea but RTSP seems a tricky protocol and I dont really know if its possible.
which kind of proxy should I use? must be an specific one for rtsp?
-
This seems like pretty stupid setup, why would you not want access to all your webcams at any time?? And be able switch to them when you wanted??
I would think if you forwarded to an alias that pointed a dns name that changed you could just have it change by setting how often the alias updates. With a cron job you would have to look into how to edit the rules from cmd line and setup your cron to do it. AFAIK there is no current way in the gui to do such a thing.
But still don't understand the purpose.. If I had 3 webcams I would want to be able to access all of them, not just 1 and have to wait 30 mins to see the next one..
-
Hehe it sounds pretty stupid if you dont know the reason xD
Each camera is in a different classroom and we only do activities in that schedule, half hour in each room.
We just want to stream that activities.
So we think theres no reason to hire 3 external streaming services when we can do it with just one because the schedule casually correspond in time.So which method seems better?
try to proxify it?
dns change?
or what about a virtual ip?
-
virtual ip gets you what? Do you have more than 1 public IP? Can you not just setup the streaming service to go to different public IPs at a specific time… Which streaming service are you using ustream?
Ok thinking about this for a few seconds. Why don't you just edit the config and then do a reload in your cronjob.
so you could setup a edit of /cf/conf/config.xml to change what you want be it the IP your pointing to in your nat.. Be it the alias IP that was used in your nat rule, etc.
Then just remove the cache /tmp/config.cache and then you can reload it with /etc/rc.filter_configure I do believe
-
Seems a good idea but RTSP seems a tricky protocol and I dont really know if its possible.
which kind of proxy should I use? must be an specific one for rtsp?There are plenty of proxies if that's the route you want to take. HAProxy and Pen are two I can think of off the bat. Or there's ZenLoadbalancer if you don't want to do too much command-line work. I've used proxies for web traffic, ftp and even SMTP traffic so I would think it could handle RTSP, though I haven't tried it with that specific protocol before myself.
