Apache2 - RTSP stream redirection without ffmpeg processing - ffmpeg

I have IP camera on local network with address let say: 192.168.5.111:36121 (for rtsp conection)
So I can view real time video in local network for example with:
ffplay rtsp://admin:xxxx#192.168.5.111:36121/cam/realmonitor?.......
I can access my camera from any place as well from my linux VPS server with:
ffplay rtsp://admin:xxxx#xbox2.com:37021/cam/realmonitor?.......
To do this on my remote VPS linux server I have VPN server and locally DD-WRT router connected to this server as client:
So on the local router I have:
iptables -t nat -A PREROUTING -i tun11 -p tcp --dport 36121 -j DNAT --to-destination 192.168.5.111
And on VPS server:
iptables -t nat -A PREROUTING -d 176.123.123.123/32 -p tcp -m tcp --dport 37021 -j DNAT --to-destination 10.8.0.10:36121
and that is allowing me to connect my camera from global network with:
ffplay rtsp://admin:xxxx#xbox2.com:37021/cam/realmonitor?.......
or
ffplay rtsp://admin:xxxx#176.123.123.123:37021/cam/realmonitor?.......
Everything works fine - but I would like to avoid to use specific port number directly (and use only :443 for all my cameras) so for example instead of
using xbox2.com:37021 to use xbox2.com/cam1 with redirection from apache2, so to access the camera it would be: ffplay rtsp://admin:xxxx#xbox2.com/cam1/cam/realmonitor?.......
Was trying to use RedirectMatch, ProxyPass, ProxyPassReverse in the VirtualHost config but did not succeed.
So:
question nr.1 - is it at all possible to use apache2 to redirect the rtsp as described before?
question nr.2 - if yes so how?
Please note that I can redirect the stream with the node-rtsp-stream within apache2 (over port :443) using:
ProxyPass /wss1 ws://127.0.0.1:3001
ProxyPassReverse /wss1 ws://127.0.0.1:3001
and later to play it with jsmpeg on the web page but the problem is that ffmpeg processing on my VPS server makes big load to the processor, that's why I would like only to redirect the rtsp stream using apache2 without any ffmpeg processing.

Related

No IPV6 internet connectivity on client side of OpenVPN AWS EC2 server

I have an OpenVPN server I've set up on an AWS EC2 instance that is pulling an IPV6 address, and can traceroute6 and ping6 ipv6.google.com. The client can do neither and does not return an address when using online tests like ipleak, or testipv6. The server and client can ping6 and traceroute6 each other.
The client appears to pull the correct address locally, and via ip -6 route. IPV4 has always worked fine without issue. Everything appears good on the AWS side per their instructions here so the instance does have ipv6 enabled with the proper routing on the aws/vpc side. Security groups are pretty wide open for ipv6 as well.
I am assuming it's my routing, but I'm not really sure at this point as I'm no ipv6 or routing expert. Please help!
Relevant config info:
ipv6 addr of AWS instance:
aaaa:bbbb:cccc:dddd::/64
server.conf
local 172.31.44.1
port 443
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 1.1.1.1"
push "dhcp-option DNS 1.0.0.1"
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
verb 3
crl-verify crl.pem
explicit-exit-notify
server-ipv6 aaaa:bbbb:cccc:dddd:80::/112
push "redirect-gateway-ipv6 def1 bypass-dhcp-ipv6"
push "route-ipv6 aaaa:bbbb:cccc:dddd::/64"
push "route-ipv6 2000::/3"
push "route 172.31.44.1 255.255.255.255 net_gateway"
push "dhcp-option DNS6 2001:4860:4860::8888"
push "dhcp-option DNS6 2001:4860:4860::8844"
/etc/sysctl.conf
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.all.proxy_ndp=1
ip6tables:
-A INPUT -p udp --dport 443 -j ACCEPT
-A FORWARD -m state --state NEW -i tun0 -o eth0 -s aaaa:bbbb:cccc:dddd::/64 -j ACCEPT
-A FORWARD -m state --state NEW -i eth0 -o tun0 -d aaaa:bbbb:cccc:dddd::/64 -j ACCEPT
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
Don't use proxy NDP. It's a mess.
What you need is to delegate (=route) a prefix to the EC2 instance, then configure this prefix in the OpenVPN config (server-ipv6 keyword with the assigned prefix and mask, e.g. 2001:db8:dead:beef:1::/80), then assign connected users addresses from the prefix.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/work-with-prefixes.html
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/

Exclude localhost from bind redirect

I'm using WFPSampler to redirect all traffic to a specific interface by using command:
WFPSampler.exe -s PROXY -l FWPM_LAYER_ALE_BIND_REDIRECT_V4 -pla 10.0.2.15 -v -in
This works just fine, traffic from all of the processes is redirected as expected. The only problem is that it binds 127.0.0.1 to 10.0.2.15 as well and then some applications fail to connect.
For example, I've created simple Python HTTP server on 127.0.0.1:8000 and I can not access it over the browser using this address.
I know that on FWPM_LAYER_ALE_BIND_REDIRECT_V4 it is only possible to filter by local address, but I have somehow to filter by remote address at this point to avoid binding localhost to 10.0.2.15
You could redirect the outgoing traffic from 10.0.2.15 to 127.0.0.1 at the same time, with the command like:
WFPSampler.exe -s PROXY -l FWPM_LAYER_ALE_CONNECT_REDIRECT_V4 -ipra 10.0.2.15 -pra 127.0.0.1 -v -in
The comments of this answer has metioned it.

Spring Boot port forwarding 80 to 8080

I recently created a spring boot app and launched it to my remote server. I am running centos7 and I have modified iptables to send port 80 to 8080 but that seemed to do nothing. I also currently have this in a .htaccess file to make it work:
RewriteCond %{SERVER_PORT} 80$ [NC]
RewriteRule index.html$ http://%{HTTP_HOST}:8080/ [P,S=1]
RewriteRule (.*) http://%{HTTP_HOST}:8080%{REQUEST_URI} [P]
My problem with the current solution is that It works great for the base url blah.com but any subsequent link of of that page will have blah.com:8080/page.html. Thus how do I better manage URL's that are displayed to the client so they dont have the port.
I think the real problem is hepsia is running and appears to have installed httpd on port 80 already. Does anyonke know where i can add a veirtualhost to hepsia's implementation of httpd?
Thanks in advance for any help
The above answer will not work unless your application is running as root on many Linux distributions. The standard way to bypass this is to run your application behind a webserver (which runs on port 80), and forward those web server requests to your app.
If this is overkill for your purpose you can set up iptables routing / redirect.
First make sure your ports are open
sudo iptables -I INPUT 1 -p tcp --dport 8080 -j ACCEPT
sudo iptables -I INPUT 1 -p tcp --dport 80 -j ACCEPT
Then the redirect as follows
sudo iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
Change the Boot app to listen on port 80.
In application.properties...
server.port=80
Good luck.

Video streaming fails over rtp protocol

Video streaming between Unix Server (ffmpeg) and Windows client (vlc) completed without errors.
Server side:
ffmpeg -f v4l2 -r 25 -i /dev/video0 http://192.168.1.114:27018/feed1.ffm
Client side:
vlc player: Media -> Open Network Stream: http://192.168.1.114:27018/test.swf
However, video streaming has approximately 10 s. delay. For this reason, I tried using rtp instead http, but without result. Specifically, on server side I run:
ffmpeg -f v4l2 -r 25 -i /dev/video0 rtp://192.168.1.114:27018/feed1.ffm
After the stream begun, on client side I typed: rtp://#:27018 but it doesn't respond.
What I am missing? Is there any other way I could avoid delay?
Short (incomplete) solution for the problem with the RTP stream:
Setup FFMPEG with the command line:
ffmpeg -f v4l2 -r 25 -i /dev/video0 rtp://<client_ip>:<client_port>
where <client_ip> and <client_port> need to be replaced with the client's IP address and port number, respectively.
Description of the problem with the RTP stream and the solution:
Generally, when setting up an HTTP server (in this case, namely HTTP multimedia server), on the server's side, the local port and the local IP address that the server needs to listen on are specified. So when you set up FFMPEG to stream on http://192.168.1.114:27018/, it probably means that FFMPEG (the server) will listen on its one interface that has the IP 192.168.1.114 and on the port 27018. Then the client needs to connect to http://192.168.1.114:27018 to get the streams.
However, when setting up an RTP FFMPEG server, the client address(es) and port(s) are specified on the server's side, meaning (inaccurately) that the server sends the packets to the desired addresses and the clients need to listen on their ports if they want the available streams. So the FFMPEG server needs to be setup with the URL rtp://<client_ip>:<client_port> and not the URL rtp://<server_ip>:<server_port>, for the <client_ip> to be able to access the stream on his local port <client_port>.
For more info on the FFMPEG's RTP URL format and a starting point for some intriguing concepts in RTP streaming (like multicasting), visit here.

IPTables configuration for Transparent Proxy

I am confuse why my IPTable does not work in Router. what I'm trying to do is redirect any packets from source ip destined to port 80 and 443 to 192.168.1.110:3128. however when I tried this:
iptables -t nat -A PREROUTING -s 192.168.1.5 -p tcp --dport 80:443 -j DNAT --to-destination 192.168.1.110:3128
does not work. however when I add this,
iptables -t nat -A POSTROUTING-j MASQUARADE
it works. but the problem with masquarade is I do not get the real ip but instead the ip of the router. I need to get the source ip so my proxy server could record all ip connected to it. can some one tell me how to make it work without making POSTROUTING jump to Masquarade?
For real transparent proxying you need to use the TPROXY target (in the mangle table, PREROUTING chain). All other iptables-mechanisms like any NAT, MASQUERADE, REDIRECT rewrite the IP addresses of the packet, which makes it impossible to find out where the packet originally was intended to.
The proxy program has to bind() and listen() on a socket like any other server, but needs some specific socket flags (which requires some Linux capabilities (type of permission) or root). – Once connected, there is some way to get the “intended server” from the OS.
Sorry, I’m a little lazy about the details, but searching for “TPROXY” as keyword will get you going quickly!
If I am not wrong, the correct syntax of the rule would be:
iptables -t nat -A PREROUTING -s 192.168.1.5 -p tcp -m multiport --dports 80,443 -j DNAT --to-destination 192.168.1.110:3128
--dport 80:443 will forward all ports from 80 to 443
--dports 80,443 will forward port 80 and 443 only.
If you want traffic hitting 192.168.1.5 on port 80 and 443 to be forwarded to 192.168.1.110's 3128 port then you should use the below rule:
iptables -t nat -A PREROUTING -d 192.168.1.5 -p tcp -m multiport --dports 80,443 -j DNAT --to-destination 192.168.1.110:3128
You should also make sure the gateway on 192.168.1.110 is pointed to your router ip.
Finally you can use the masquerade rule as below.
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 -j MASQUERADE
eth1 should be your outgoing interface.
I had the same issue and the solution was to tell the transparent proxy to forward the source ip in the right header fields.
In case of my nginx proxy the rules were close to:
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
proxy_set_header X-NginX-Proxy true;
proxy_pass http://name_of_proxy;
proxy_redirect off;
}
i used the iptables -t nat -A PREROUTING -p tcp -s foreign ip to your device --dport 80:443 -j DNAT --to-destination your application or local ip:port.i think you did the prerouting the packet in your device out which never connect to port 80 or 443,these is for web server connect to device.192.168.1.5 is like my local address.
and remember to configecho 1 > /proc/sys/net/ipv4/ip_forward
I think you are doing NAT in both directions by not specifying an interface. Try adding -o eth0 to your -j MASQUERADE line. (Substitute whatever your "external" interface is, instead of eth0, depending on your setup.)

Resources