I was looking for an answer on my question on google and also here, but a didn't find a proper answer.
So here is the context:
I have a software running on some server (without firewall) in one subnet.
There is another software running on some PC in a different subnet.
Both subnets are connected to a gateway server. All computers are running CentOS or RHEL.
On the gateway server, there is a firewall, preventing multicast traffic from leaving the one subnet and allow clients from outside to connect to computers inside this subnet. Therefore xinetd is used. The computer from outside needs to send a packet to a specific port, the computer on the inside answers to another specific port depending on the sender. So there is no need for the gateway to keep track of sender-receiver relations. It just needs to forward UDP on specific ports to specific computers from one subnet to another.
So I added one service in /etc/services (for one direction):
udp-gateway 6000/udp
And created the according configuration file in /etc/xinetd.d/gateway like:
service udp-gateway
{
disable = no
socket_type = dgram
protocol = udp
wait = no
user = root
redirect = 192.168.1.1 6000 #Server inside the 192.168.1.0 subnet
}
Now the problem is, that the server doesn't open an UDP-port to listen on ('netstat -nulp' says). When I change the protocol to TCP and the socket_type to stream, it works. But I need this for UDP.
Is it possible that this is not possible for UDP? Or is netstat just not showing the ports? Or is my xinetd-configuration missing something?
Thanks in advance, every hint is appreciated.
Benny
redirect = 192.168.1.1 6000 #Server inside the 192.168.1.0 subnet
from the man page of xinetd:
redirect
Allows a tcp service to be redirected to another host.
This means usage of redirect for udp is not possible. And I don't see any other way to do this with xinetd.
Related
Through tcpdump in dhcp-server, it shows the server can receive the DHCPDISCOVER package and send the DHCPOFFER package, but can not receive the DHCPREQUEST package from the dhcp-client, so the client can not get IP address and always in send DHCPDISCOVER package.
But the dhcp-server which runs in VMWARE's instance can send DHCPACK to client and the same client will get the IP success. The dhcp-server using the same configure as in Openstack's instance.
And, if I configure the static IP address in the client instance, it will ping the dhcp-server's IP successful.
One more thing, the server and client are in the same vlan.
Is there any limit rule in Openstack's instance? How can I resolve this problem, THX.
The essential reason is that the traffic of port is limited by the security groups in openstack.
By default, all security groups contain a series of basic (sanity) and anti-spoofing rules that perform the following actions:
Deny egress DHCP and DHCPv6 responses to prevent instances from acting as DHCP(v6) servers.
Resolution:
disable security groups (no recommend)
set dhcp-relay to the dhcp server in router (recommend)
security groups limited the traffic by hypervisor's iptables which will drop the packets which's src port is 67 and dst port is 68.
DHCPOFFER packets will send to router by src and dst port 67, and it will works to all vlans.
For DHCP relay and DHCP proxy, packets sent to the DHCP server from the router have both the source and destination UDP ports set to 67. The DHCP server responds using the same ports.
Maybe there are some methods but I can't find out until now ?
I need to access company's internal network without using their OPENVPN server directly (My ISP blocks it). So I used an instance with a public IP, where my company is located, and have configured a OPENVPN client then used it to connect to the company's OPENVPN server.
(public IP instance) ===OPENVPN===> (Company)
Now, I need to achieve a further thing, which is working from my local machine by using VPN over SSH tunnel using sshuttle, such that the topology becomes:
(local) ===SSHUTTLE===> (public IP instance) ===OPENVPN===> (Company)
Note that public IP instance has two network adapters; eth0 (it has public IP) and tun0 (which belongs to OPENVPN)
I installed sshuttle, and tested the next command:
sshuttle --dns -r <user>#<public IP instance address> 0.0.0.0/0
It says connected after then but I still cant access anything. I tested dig and it returned results showing addresses of company's internal services. However, I still can't ping them. I tested using traceroute and it stops at some point after displaying some hops.
One important point is that I can't ping the tun0 address (on public ip instance) from my local machine.
I suspect that I need to add some routes on the intermediate public IP instance, but I am not sure.
I would appreciate any help
Thanks in advance
your setup is right but your assumptions are wrong.
Initially, check that your vpn is working fine on the jump box , if linux just check
route -n
Wrong assumptions:
sshuttle will route your dig commands , sshutle only route TCP and DNS queries are UDP
using --dns in your sshuttle meanless as you wont gain dns of vpn but of the jump box and that wont work
you should add the DNS of local vpn in your /etc/resolv.conf with target domain for local discovery
like : < call tech support to provide you with right DNS , you can find it in vpn log on jump box
search companydomain.internal
nameserver 10.x.y.z
its better to split the traffic and only target your company CIDR over sshuttle , most of them use parts of 10.0.0.0/8 instead of all traffic 0.0.0.0/0
important note: that may be your company block egress traffic to the internet over VPN access
I want to make an http request via the fetch() method in React Native, and I need the IP address of the machine I'm sending the request to. I have access to the machine, and googled "what's my IP" on it. It said my public IP was 162.250.198.98, but when I googled it on another computer nearby, it gave the same address. Is this the right IP to use in a fetch request like this? If not, how do I find the right one to use?
If you have multiple machines connected to the internet via a NAT-enabled router, they will all share the same public IP address. You need to forward a specific port to the machine you want to connect to in the router's configuration e.g. to send your request on port 5000, add a rule to the router to forward port 5000 to your desired machine, then send the request to 162.250.198.98:5000
For your application to work you need a "server" with a public ip address. Later you assign a domain name to that server/ip address ex. api.domain.com
Since you don't have a server and you are using your computer to test your development, you can do this 2 options:
Use your computer IP address usually 192.168.x.x , 10.x.x.x or 172.16.x.x This will allow you to test it if your phone is connected wireless to the same network.
Since you are behind a NAT you can do a port forward to send the traffic to X port to your desired host(ip/port) behind the nat. Usually we create API's that run on port 80 or 443 do a port forward in your router to pass the traffic from this port to your computer ip/port.
I am trying to set up a STUN/TURN server on my local computer for a webrtc application of me. I decided to use coturn. Note that my server is running behind a NAT.
So i fired up my Ubuntu VM and installed it. After reading through the wiki I got it working, atleast on my local network. For testing purposes, i use this site. Therefore, when i try it there with 192.168.178.25:3478, it works. When i try it with "public-ip":3478, it doesnt.
This told me, it is working locally and it should be a port/NAT issue. What i did:
1) I set the VM to Bridging
2) I opened the port 3478 on my router. To test if this is really working, i used telnet on a remote machine and it worked. Another test was that i set up a quick apache server on my local machine on port 3478 and it could be accessed from the outside. This told me that there is, or should be, not port/NAT issue and my turn server should be working.
Any ideas?
I am running my server with the following command:
"sudo turnserver -X "public-ip" -listening-port=3478 -v
The turnserver.conf looks something like this:
fingerprint
realm="myRealm"
lt-cred-mech
user=test:test
As telnet and apache server are both working, i am pretty sure i have a configuration issue. I basically spent the weekend trying and im really lost on what could be wrong.
Thanks for any help!
From the documentation of turnserver
-X, --external-ip <public-ip>[/private-ip] TURN Server public/private address mapping, if the server is behind NAT. In that situation, if a -X is used in form "-X " then that ip will be reported as relay IP address of all allocations. This scenario works only in a simple case when one single relay address is to be used, and no CHANGE_REQUEST STUN functionality is required. That single relay address must be mapped by NAT to the 'external' IP. The "external-ip" value, if not empty, is returned in XOR-RELAYED-ADDRESS field. For that 'external' IP, NAT must forward ports directly (relayed port 12345 must be always mapped to the same 'external' port 12345). In more complex case when more than one IP address is involved, that option must be used several times, each entry must have form "-X ", to map all involved addresses. CHANGE_REQUEST NAT discovery STUN functionality will work correctly, if the addresses are mapped properly, even when the TURN server itself is behind A NAT. By default, this value is empty, and no address mapping is used.
So, it is not enough that you expose only the listening port from the inside LAN to the public network but all ports that you are going to use to relay. Please, note what is said in the same documentation:
--min-port <port> Lower bound of the UDP port range for relay endpoints allocation. Default value is 49152, according to RFC 5766.
--max-port <port> Upper bound of the UDP port range for relay endpoints allocation. Default value is 65535, according to RFC 5766.
You should choose a range of ports in the server, configure with them the options --min-port and --max-port and create a NAT rule to expose those ports to the public side of the router without change.
It's not that much of a question, rather a confirmation that what I did is right or not and if it is safe or not.
Until now what I have found googling around is that you cannot run rtorrent through a proxy. You can either put the http request through a proxy, or tsocks, in both cases either the actual transfers are done directly or not done at all. Therefore until now the only proposed viable solution is a VPN which I wanted to avoid.
What I did was use an http proxy for the http part and a port forwarding for the actual download part. For example, lets assume the following:
192.168.1.10 --> Local machine with the actual rtorrent
remote.machine.com --> The remote machine used as a proxy
Procedure:
I created 2 ssh tunnels
ssh -N -D 9090 user#remote.machine.com
ssh -R 9091:localhost:9091 user#remote.machine.com
From the local machine I installed polipo as the html proxy and configured it to use a socks proxy in the remote.machine.com.
I edited the following lines in /etc/polipo/config so that I can get the socks proxy.
socksParentProxy = "localhost:9090"
socksProxyType = socks5
I also changed the html proxy port for extra security, again in /etc/polipo/config
proxyPort = 9080
On the local machine I changed the ~/.rtorrent.rc as following:
#Proxy of the http requests through polipo
http_proxy=localhost:9080
# The ip address reported to the tracker.
#Really important, in order to get connections for downloads
ip = remote.machine.com
# The ip address the listening socket and outgoing connections is
# bound to.
bind = 192.168.1.10
# Port range to use for listening.
port_range = 9091-9091
# Start opening ports at a random position within the port range.
port_random = no
The system seems to work. I connect to the trackers and I have up and down traffic. So the questions are:
Am I safe that all the traffic concerning rtorrent is done through the remote.machine.com?
Did I miss something?
Are there any problems or concerns regarding this method?
As far as I see, you have covered inbound connections, as well as outgoing HTTP traffic, but any outbound peer-to-peer connections will be created directly, not through any tunnel. Currently, rtorrent does not appear to support passing outbound P2P connections through a tunnel or proxy of any kind, so in order to handle these, you'll need some other mechanism.
You mentioned tsocks and that it does not work – not even in addition to the rtorrent configuration you have set up above? (Although with tsocks you should be able to drop the HTTP proxy part.)
If that fails, there are alternatives to tsocks mentioned on the tsocks project page. A slightly more involved alternative would be to create a new loopback interface (lo:1 with IP 127.0.0.2), bind your rtorrent to that one and use something like sshuttle to direct all traffic originating on that interface through an SSH tunnel. Unfortunately, sshuttle doesn't let you restrict its operation to a specific interface at the moment, though, so you'd have to fiddle with the iptables rules it creates to make them match your needs. I assume a patch adding this feature to sshuttle would be welcome.
As a side note, you can create multiple port forwards and SOCKS proxies in a single SSH connection, like this:
ssh -N -D 9090 -R 0.0.0.0:9091:localhost:9091 myself#my.example.com