I've been trying to set up a Wireguard VPN on my Dedibox at Scaleway for the past few days now, with limited success. First of all, IPv4 is working, so at least I am not hopelessly lost. Currently my peers are using private IPv4 addresses to talk to the server, which then nats them onto it's own public IP using iptables. Works great. Now I want to set up IPv6 too, but not using nat. I want to forward public IPv6 addresses assigned on my peers using ip6tables and use those to go over the internet, rather than using the Masquerade option like with IPv4.
I have so far had limited success in that field. I set up a little test environment in GNS3 and without Wireguard it's definitely possible to route IPv6 addresses using ip6tables (just to find out what rules to make, I am kind of new to iptables). Now I tried to do the same thing on my wireguard equipped server, but to no avail. My PostUp and PostDown are currently as follows (censoring out my IPv6 addresses):
PostUp:
iptables -A FORWARD -o wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o enp0s20 -j MASQUERADE
ip6tables -t filter -I INPUT 1 -s 2001:db8:abcd:100::/56 -j ACCEPT
ip6tables -t filter -I INPUT 2 -s 2001:db8:abcd:101::/64 -j ACCEPT
ip6tables -t filter -I FORWARD 1 -o wg0 -j ACCEPT
ip6tables -t filter -I FORWARD 2 -i wg0 -j ACCEPT
PostDown:
iptables -D FORWARD -o wg0 -j ACCEPT
iptables -t nat -D POSTROUTING -o enp0s20 -j MASQUERADE
ip6tables -t filter -D INPUT -s 2001:db8:abcd:100::/56 -j ACCEPT
ip6tables -t filter -D INPUT -s 2001:db8:abcd:101::/64 -j ACCEPT
ip6tables -t filter -D FORWARD -o wg0 -j ACCEPT
ip6tables -t filter -D FORWARD -i wg0 -j ACCEPT
The public IPv6 range assigned to my main interface (enp0s20) is 2001:db8:abcd:100::/56, while I want to use 2001:db8:abcd:101::/64 for my Wireguard peers.
Another curious thing is that for some reason it appears as though I can ping between peers on this network, but that might be a fluke here, not exactly sure. I currently have both my workstation and smartphone on this network, and pinging between my workstation and smartphone works fine using the following command on Windows:
ping -6 -S 2001:db8:abcd:101::2 2001:db8:abcd:101::3
Where my workstation ends in 2 and my smartphone ends in 3.
I am at a total loss, anyone who could help me with this?
Related
I am running the traffic from my docker container through sshuttle to a remote server, which is working great with this command:
sshuttle -l 0.0.0.0 -r user#server 0/0 -v
The problem is that I need incoming connections to be allowed to reach my local server via the remote server's ip address and a specific port. I've tried creating an additional ssh tunnel via
ssh -NR 0.0.0.0:43523:localhost:43523
This almost works, as the incoming connections show up in the sshuttle verbose logs, but the connection never establishes (connection timed out from the client side).
Here are the iptables rules created by sshuttle at runtime:
iptables -t nat -N sshuttle-12300
iptables -t nat -F sshuttle-12300
iptables -t nat -I OUTPUT 1 -j sshuttle-12300
iptables -t nat -I PREROUTING 1 -j sshuttle-12300
iptables -t nat -A sshuttle-12300 -j RETURN -m ttl --ttl 63
iptables -t nat -A sshuttle-12300 -j RETURN -m addrtype --dst-type LOCAL
iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 0.0.0.0/0 -p tcp --to-ports 12300
So my question is: What is causing the incoming connections to not work? And how can I fix it?
I have a server (openvpn) which is not multithreaded and hence does not take advantage of the multiple cores in the box. I'm trying to solve the problem by running multiple servers, each on a different port, e.g. 127.0.0.1:8000, 127.0.0.1:8001, ... then load balancing the exterior 1194 port based on the source IP -- openvpn uses UDP but all packets for a client must arrive at the same server.
Issue I'm running into is how to load balance. I tried IPVS, but it seems like it doesn't work with servers on the same host. Then tried nginx's new udp feature, but again no dice. Any ideas on how to achieve this?
I discovered that plain old iptables can create such a load balancer, using the HMARK target extension (see man 8 iptables-extensions).
Essentially the HMARK target can mark a packet based on a hash of specific IP tuple parameters, source IP and source port in my case, as these will be unique per client, even behind a NAT. Then I can route the packets to the appropriate localhost server based on the mark:
iptables -A PREROUTING -t mangle -p udp --dport 1194 -j HMARK \
--hmark-tuple src,sport --hmark-mod 2 \
--hmark-rnd 0xcafeface --hmark-offset 0x8000
iptables -A PREROUTING -t nat -p udp -m mark --mark 0x8000 \
-j DNAT --to-destination 127.0.0.1:8000
iptables -A PREROUTING -t nat -p udp -m mark --mark 0x8001 \
-j DNAT --to-destination 127.0.0.1:8001
Remember to enable routing packets to localhost:
sysctl -w net.ipv4.conf.eth0.route_localnet=1
I am trying to configure iptables for my Centos6 server.
I am encountering problem with NewRelic ips.
This is my iptables file:
*filter
#new relic
-A INPUT -s 50.31.164.0/24 -j ACCEPT
-A INPUT -s 103.21.244.0/22 -j ACCEPT
-A INPUT -s 103.22.200.0/22 -j ACCEPT
-A INPUT -s 103.31.4.0/22 -j ACCEPT
-A INPUT -s 104.16.0.0/12 -j ACCEPT
-A INPUT -s 108.162.192.0/18 -j ACCEPT
-A INPUT -s 141.101.64.0/18 -j ACCEPT
-A INPUT -s 162.158.0.0/15 -j ACCEPT
-A INPUT -s 162.247.240.0/22 -j ACCEPT
-A INPUT -s 173.245.48.0/20 -j ACCEPT
-A INPUT -s 188.114.96.0/20 -j ACCEPT
-A INPUT -s 190.93.240.0/20 -j ACCEPT
-A INPUT -s 197.234.240.0/22 -j ACCEPT
-A INPUT -s 198.41.128.0/17 -j ACCEPT
-A INPUT -s 199.27.128.0/21 -j ACCEPT
-A OUTPUT -d 50.31.164.0/24 -j ACCEPT
-A OUTPUT -d 103.21.244.0/22 -j ACCEPT
-A OUTPUT -d 103.22.200.0/22 -j ACCEPT
-A OUTPUT -d 103.31.4.0/22 -j ACCEPT
-A OUTPUT -d 104.16.0.0/12 -j ACCEPT
-A OUTPUT -d 108.162.192.0/18 -j ACCEPT
-A OUTPUT -d 141.101.64.0/18 -j ACCEPT
-A OUTPUT -d 162.158.0.0/15 -j ACCEPT
-A OUTPUT -d 162.247.240.0/22 -j ACCEPT
-A OUTPUT -d 173.245.48.0/20 -j ACCEPT
-A OUTPUT -d 188.114.96.0/20 -j ACCEPT
-A OUTPUT -d 190.93.240.0/20 -j ACCEPT
-A OUTPUT -d 197.234.240.0/22 -j ACCEPT
-A OUTPUT -d 198.41.128.0/17 -j ACCEPT
-A OUTPUT -d 199.27.128.0/21 -j ACCEPT
# Default chain policy
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
COMMIT
Now the problem is that new relic is blocked, although all of it's ips are opened.
If I change the default policy to:
-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
Which is practically disabling iptables, everything works.
Do you have any suggestions?
Jane,
I would start by reviewing the output of
iptables -nL
to ensure that what is currently running is the same as the file that you think is being loaded (Which I assume is /etc/sysconfig/iptables).
If they match, I would add some logging, either from the command line by
iptables --append INPUT --jump LOG --log-prefix Input____ --log-level=$LOG_LEVEL
iptables --append OUTPUT --jump LOG --log-prefix Output____ --log-level=$LOG_LEVEL
or modifying your file and adding
-A INPUT -j LOG --log-prefix "Input____" --log-level 6
-A OUTPUT -j LOG --log-prefix "Output____" --log-level 6
immediately before the # Default chain policy line and reload the firewall.
I would choose the command line option, so as to not make the changes permanent.
The output from the log will usually go to /var/log/messages. (You can check /etc/syslog.conf to find out where kern.* is logging.)
You can easily find the logged output by
tail -f /var/log/messages | grep put____
and then trying to access one of the NewRelic ips.
If you need some more help, post the output of iptables -nL and tail -f /var/log/messages | grep put____
It appears as though these rules are intended to make certain your system can communicate with the list of IP addresses listed on New Relic's doc site:
https://docs.newrelic.com/docs/apm/new-relic-apm/getting-started/networks
The rules you have now are a good start for allowing communication between your system and New Relic. I can help get the connectivity to New Relic working but I cannot advise you as to what your complete firewall rules should be. Firewalls are a complex subject and certainly not one size fits all.
Please do not consider my additions as making the above list of rules comprehensive.
Now that the disclaimer is out of the way, the likely reason the agent/monitor isn't able to report data to New Relic is likely because these rules are blocking all DNS lookups.
For any of the application monitors (meaning the Java agent, Ruby agent, etc) or the Linux Server Monitor to send data to New Relic a DNS lookup for 'collector.newrelic.com' must be performed. This 'collector' actually redirects the agent or monitor to another system that is the "real" collector.
With the rules listed above, when the application agent or server monitor tries to perform a DNS lookup for 'collector.newrelic.com', it will fail. This failure will prevent the agent or server monitor from reporting any data to New Relic.
You can allow DNS lookups by adding something general like so:
-A OUTPUT -p udp --sport 1024:65535 --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
-A INPUT -p udp --sport 53 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT
You might further refine this rule by including the IP address(es) of your DNS server(s) explicitly.
Adding those lines and restarting the firewall should solve the New Relic reporting issue.
One final comment, the iptables rules shown here also prevent all incoming web requests. If you have a website or web application, these rules will prevent anyone from reaching your site. This should also be addressed in your revised list of firewall rules.
Here is a little picture
Asterisk eth1 10.254.254.2/28------------- Many Good Guys
eth1:1 192.168.83.5/32----------- 192.168.59.3 Bad Guy Peer
I have an Asterisk which is connected with several peers. Some of them are connected through
eth1 and one the badest through alias eth1:1.
Then my asterisk send invite to peers it goes with the eth1 source. So for the bad guy I need to change my source ip to 192.168.83.5 As far as I know it can be done with iptables.
So I tried the rule
iptables -t nat -A POSTROUTING -s 10.254.254.2 -d 192.168.59.3 -j SNAT
--to 192.168.83.5
nothing happens.
When I log I can see send packets in INPUT and OUTPUT chains with :
iptables -t filter -A OUTPUT -o eth1 -s 10.254.254.2 -d 192.168.59.3
-j LOG --log-level 7 --log-prefix "OUTPUT"
iptables -t filter -A INPUT-i eth1 -s 192.168.59.3 -d 192.168.83.5 -j
LOG --log-level 7 --log-prefix "OUTPUT"
but I don’t see any in POSTROUTING chain with:
iptables -t nat -A POSTROUTING -s 10.254.254.2 -d 192.168.59.3 -j LOG
--log-level 7 --log-prefix "POSTROUTING"
That is I have nothing to SNAT(((
At the same time the traffic from other peers is visible in POSTROUTING log. What can it be?
Any thoughts, wishes, kicks would be very appreciated!
The solution has been found!!
I didn' t find a way to make my iptables work. But know i know how to do it without iptables at all.
So generally speaking my task was to modify|mask|replace my source ip of eth1 with eth1:1 ip.
By the way i use CentOS 5.8
And there is a command:
ip route add
which gives you ability to point scr address unlike the route command.
so
ip route add 192.168.59.3/32 via 10.254.254.1 dev eth1 src
192.168.83.5
is doing just what i need.
Thank you for attention!
That will not work. Reason is simple, asterisk will set in packet source addres=address of eth1.
You can start enother asterisk same host(with other config dir). I am sorry, i not know other simple variants.
I am working on Holepunching using UDP and UDT. For the final testing I need to test the application on different NAT types (Symmetric,full cone,restricted cone, port restricted NATs).
Is there any method I can simulate these? What I expect here is some kind of virtual-Box setup. Can I use PC as a router so that I can configure according to my needs?
In general how do we test applications for different network conditions?
Just in case someone else is looking to do this, this website explains how to set up the different NAT environments using IPTables.
Update
It has been a few years since I did this, given that the link was placed behind a login, and the rewind was also placed behind a login, I went through my notes from back than and found the following. Please note these are untested.
Full Cone NAT;
iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source "public IP"
iptables -t nat -A PREROUTING -i eth1 -j DNAT --to-destination "private IP"
Restricted Cone NAT;
iptables -t nat -A POSTROUTING -o eth1 -p udp -j SNAT --to-source "public IP"
iptables -t nat -A PREROUTING -i eth1 -p udp -j DNAT --to-destination "private IP"
iptables -A INPUT -i eth1 -p udp -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth1 -p udp -m state --state NEW -j DROP
Port Restricted Cone NAT;
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source "public IP"
Symmetric NAT;
echo "1" >/proc/sys/net/ipv4/ip_forward
iptables --flush
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE --random
iptables -A FORWARD -i eth1 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
I think you already answered your own question, use VirtualBox (or VMware, Xen, etc..).
I've done this very thing successfully by setting up mini-lans of VM's. If you're looking for software to act as your router inside a VM, I'd start off at http://www.pfsense.org/ and see if that meets your needs. It's a FreeBSD distribution tailored for being an easy to install router/firewall with a nice web management UI and all of that.
If pfsense doesn't fit your needs, there are plenty of other linux/bsd distributions out there that are tailored for this kind of stuff and that you can install in a VM: http://en.wikipedia.org/wiki/List_of_router_or_firewall_distributions for a good list :) (I've heard good things about OpenWRT and ClearOS as well.)