fulvion75 0 Posted ... Hi all, i'd like to share my problem with you in the hope that someone can help me make light on it because i'm really out of ideas... i have a ddwrt router configured with the open vpn client to connect to air vpn. it is connected to my isp adsl modem and it works great for browsing. i followed all the topics about forwarding port and ended up with the following iptables cmds: iptables -I FORWARD -i tun1 -p tcp -d 10.1.1.201 --dport 30389 -j ACCEPT iptables -I FORWARD -i tun1 -p tcp -d 10.1.1.201 --dport 30390 -j ACCEPT iptables -t nat -I PREROUTING -i tun1 -p tcp --dport 30389 -j DNAT --to-destination 10.1.1.201 iptables -t nat -I PREROUTING -i tun1 -p tcp --dport 30390 -j DNAT --to-destination 10.1.1.201 of course i checked the tun interface name. Anyway security check on air vpn web site shows them open with a yellow token. at the end of these ports there an ip camera. Everything works well if i try to connect to the camera via lan or wan interfaces. but it does not from the tun interface (for wan there were 4 other same commands associated to the correct interface for testing only). Thus if i use another computer with another adsl to connect to my device, it does not work at all. Just to be sure that port forwarding was working properly, i downloaded "Simple TCP listener" and made it listen at port 30391 to send a welcome message. I then added related iptables command and checked it out from the outside (yellow token). Always using another device/adsl i successfully receive the welcome message. So port forwarding should be well configured (except the yellow token). I know that camera should work because, previously, i was using another vpn service (liquid) and everything worked fine. Now i'm on air vpn and i just want to evaluate both services before choosing my own, but i'm not able to test the most important feature i need. Unfurtunately, my isp, nats my connection so i don't have any chance to connect to my device from the outside without such a service. Any help would really be appreciated thanks in advance Fulvio Quote Share this post Link to post
fulvion75 0 Posted ... A small update i used an online service to verify http headers of the web server running at the first forwarded port (30389). the check passes if i use the http 'head' method but fails (timeout) when using 'get' or 'post' methods. here's the response with the 'head' method: Raw HTTP Response Headers: HTTP/1.1 200 OK Server: thttpd/2.25b 29dec2003 Content-Type: text/html; charset=GB2312 Date: Sun, 16 Aug 2015 15:53:14 GMT Last-Modified: Thu, 19 Mar 2015 09:23:28 GMT Accept-Ranges: bytes Connection: close Content-Length: 16563 of course the web server works well when not queried from vpn Quote Share this post Link to post
go558a83nk 352 Posted ... you seem to know what you are doing so I hesitate to ask if you made sure the tun device really is tun1. and your personal LAN has subnet 10.1.x.x? Quote Share this post Link to post
fulvion75 0 Posted ... Hello! thanks for your response. yes i checked the tun interface with 'ifconfig' command and it shows my airvpn ip address associated to the tun1 interface. My LAN is 10.1.1.X. i really can't get out of this. the only thing, IMHO, that differs from my previous vpn are: 1) that Yellow token (i can't understand why it shows Yellow. my isp nats my connection and i've checked with an online tool that all the ports i use with air, are closed from my real ip). 2) with liquid vpn i was using a dynamic but dedicated public ip. here i have a shared one and thus another nat. Support was kind to dedicate some time but they are sure that this is not a kind of problem related to their service. the question remains. if it never worked, then i could say that my camera has problems with that, but i already made it work with liquid and that's is really strange. Today my Subscription to air ends, so i have to go back to liquid. but i'd really like to keep working on this (maybe with the help of someone of you) to uncover this matter. Thanks again Fulvio Edit: here's the dump of all iptables --------------------------------------------------IPTABLES--- Note for the FORWARD chain: you'll see that FORWARD chain rules are not correctly ordered and as a result they're not used. that's because packets are forwarded by the preceding rules in list and destination IP was set via the PREROUTING rule. i think that i can safely remove them but anyway i ask my self who actually added the first two rules in the forward chain. openvpn? anyway if remove them or change the order, nothing changes. ------------------------------------------------------------- Commands in 'Save firewall': iptables -I FORWARD -i br0 -o tun1 -j ACCEPT iptables -I FORWARD -i tun1 -o br0 -j ACCEPT iptables -I INPUT -i tun1 -j REJECT iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE iptables -I FORWARD -i tun1 -p tcp -d 10.1.1.201 --dport 3000 -j ACCEPT iptables -I FORWARD -i tun1 -p tcp -d 10.1.1.201 --dport 3001 -j ACCEPT iptables -I FORWARD -i tun1 -p tcp -d 10.1.1.202 --dport 3002 -j ACCEPT iptables -I FORWARD -i tun1 -p tcp -d 10.1.1.202 --dport 3003 -j ACCEPT iptables -I FORWARD -i tun1 -p tcp -d 10.1.1.201 --dport 30389 -j ACCEPT iptables -I FORWARD -i tun1 -p tcp -d 10.1.1.201 --dport 30390 -j ACCEPT iptables -t nat -I PREROUTING -i tun1 -p tcp --dport 3000 -j DNAT --to-destination 10.1.1.201 iptables -t nat -I PREROUTING -i tun1 -p tcp --dport 3001 -j DNAT --to-destination 10.1.1.201 iptables -t nat -I PREROUTING -i tun1 -p tcp --dport 3002 -j DNAT --to-destination 10.1.1.202 iptables -t nat -I PREROUTING -i tun1 -p tcp --dport 3003 -j DNAT --to-destination 10.1.1.202 iptables -t nat -I PREROUTING -i tun1 -p tcp --dport 30389 -j DNAT --to-destination 10.1.1.201 iptables -t nat -I PREROUTING -i tun1 -p tcp --dport 30390 -j DNAT --to-destination 10.1.1.201 --------------------------------------------------------------------------------------------------------------------------- DDWRT router iptables: root@TGW:~# iptables -vnL --line-numbers Chain INPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 61 13510 ACCEPT 0 -- tun1 * 0.0.0.0/0 0.0.0.0/0 2 0 0 REJECT 0 -- tun1 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 3 28606 3639K logaccept 0 -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 4 0 0 logdrop udp -- vlan2 * 0.0.0.0/0 0.0.0.0/0 udp dpt:520 5 0 0 logdrop udp -- br0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:520 6 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:520 7 0 0 logdrop icmp -- vlan2 * 0.0.0.0/0 0.0.0.0/0 8 18 504 logdrop 2 -- * * 0.0.0.0/0 0.0.0.0/0 9 3 192 ACCEPT 0 -- lo * 0.0.0.0/0 0.0.0.0/0 state NEW 10 716 41515 logaccept 0 -- br0 * 0.0.0.0/0 0.0.0.0/0 state NEW 11 8 1010 logdrop 0 -- * * 0.0.0.0/0 0.0.0.0/0 --------------------------------------------------------------------------------------------------------------------------- Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 8209 822K ACCEPT 0 -- * tun1 0.0.0.0/0 0.0.0.0/0 <-----Who added this line? 2 10603 1702K ACCEPT 0 -- tun1 * 0.0.0.0/0 0.0.0.0/0 <-----Who added this line? 3 0 0 ACCEPT tcp -- tun1 * 0.0.0.0/0 10.1.1.201 tcp dpt:30390 4 0 0 ACCEPT tcp -- tun1 * 0.0.0.0/0 10.1.1.201 tcp dpt:30389 5 0 0 ACCEPT tcp -- tun1 * 0.0.0.0/0 10.1.1.202 tcp dpt:3003 6 0 0 ACCEPT tcp -- tun1 * 0.0.0.0/0 10.1.1.202 tcp dpt:3002 7 0 0 ACCEPT tcp -- tun1 * 0.0.0.0/0 10.1.1.201 tcp dpt:3001 8 0 0 ACCEPT tcp -- tun1 * 0.0.0.0/0 10.1.1.201 tcp dpt:3000 9 0 0 ACCEPT 0 -- tun1 br0 0.0.0.0/0 0.0.0.0/0 10 0 0 ACCEPT 0 -- br0 tun1 0.0.0.0/0 0.0.0.0/0 11 5 370 lan2wan 0 -- * * 0.0.0.0/0 0.0.0.0/0 12 0 0 logaccept 0 -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 13 0 0 TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU 14 0 0 logaccept 0 -- br0 br0 0.0.0.0/0 0.0.0.0/0 15 0 0 logdrop tcp -- * vlan2 0.0.0.0/0 0.0.0.0/0 tcp dpt:1723 16 0 0 TRIGGER 0 -- vlan2 br0 0.0.0.0/0 0.0.0.0/0 TRIGGER type:in match:0 relate:0 17 5 370 trigger_out 0 -- br0 * 0.0.0.0/0 0.0.0.0/0 18 5 370 logaccept 0 -- br0 * 0.0.0.0/0 0.0.0.0/0 state NEW 19 0 0 logdrop 0 -- * * 0.0.0.0/0 0.0.0.0/0 --------------------------------------------------------------------------------------------------------------------------- Chain OUTPUT (policy ACCEPT 26937 packets, 5016K bytes) num pkts bytes target prot opt in out source destination --------------------------------------------------------------------------------------------------------------------------- root@TGW:~# iptables -t nat -vnL --line-numbers Chain PREROUTING (policy ACCEPT 1022 packets, 97894 bytes) num pkts bytes target prot opt in out source destination 1 1 60 DNAT tcp -- tun1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:30390 to:10.1.1.201 2 5 300 DNAT tcp -- tun1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:30389 to:10.1.1.201 3 0 0 DNAT tcp -- tun1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3003 to:10.1.1.202 4 0 0 DNAT tcp -- tun1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3002 to:10.1.1.202 5 0 0 DNAT tcp -- tun1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3001 to:10.1.1.201 6 0 0 DNAT tcp -- tun1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3000 to:10.1.1.201 7 0 0 DNAT icmp -- * * 0.0.0.0/0 10.1.0.100 to:10.1.1.253 8 6 874 TRIGGER 0 -- * * 0.0.0.0/0 10.1.0.100 TRIGGER type:dnat match:0 relate:0 --------------------------------------------------------------------------------------------------------------------------- Chain POSTROUTING (policy ACCEPT 20 packets, 2215 bytes) num pkts bytes target prot opt in out source destination 1 166 13201 MASQUERADE 0 -- * tun1 0.0.0.0/0 0.0.0.0/0 2 1 74 SNAT 0 -- * vlan2 10.1.1.0/24 0.0.0.0/0 to:10.1.0.100 3 0 0 MASQUERADE 0 -- * tun1 0.0.0.0/0 0.0.0.0/0 --------------------------------------------------------------------------------------------------------------------------- Quote Share this post Link to post
fulvion75 0 Posted ... i'm just writing my thoughts down.... please don't shoot at me! hahah that Yellow token puzzles me a lot... tech support said: Yellow token: reply received EVEN from the real public IP address of the client from the LOCAL remapped port of the remotely forwarded port. now the sentence is enough complex by itself but i imagine that i should have the same result (the one that turns to a Yellow token) if i check through my real ip all the ports i've forwarded in air (to be sure both remote and local). so i expect that using sites like 'yougetsignal' i'll find my ports open. but, in fact, this is not true. they're all closed. At this point i can't understand what gives me a Yellow token. maybe i misunderstood it's meaning. what do you think? but if it should work this way, will it be really impossible to think that the answer (to the original incoming packet) has something wrong in it so to make air think that it's coming from another source? this could explain why I can't get proper communication working, and that yellow token.... sure I know that once the input routing path has been "constructed" answers should travel in it too but this is not always true and it depends on many things. or maybe all of this thought is of nonsense! Quote Share this post Link to post
fulvion75 0 Posted ... Just to let you know that, thanks to wireshark, I realized that my openvpn udp connection was terrible (a lot of communication errors resulting in packets being retrasmitted). moving to TCP solved the problem but performance of camera is poor and almost unusable. Anyway this is another kind of problem. all of that time spent on it and at the end it was just a matter of connection quality.... sigh! Quote Share this post Link to post
Not connected, Your IP: 3.141.27.244
Online: 22830 users - 259347 Mbit/s total BW