New answers tagged

0

You need to use the iptables nat table REDIRECT operation: iptables -t nat -A PREROUTING --proto tcp --dport 80 -j REDIRECT --to-ports 90 This will redirect any incoming packets (coming in on a network interface from another system) to tcp port 80 to localhost port 90. That's fine for incoming packets, but for locally generated packets (on the same system)...


0

Check the filter/INPUT chain. Better use iptables-save -c command to list the full rule set. The packets to tcp://127.0.0.1:90 should be accepted. Then check the counters of the DNAT rule. It should be incrementing when you run the curl. The DNAT to the localhost (127.0.0.1) requires enable of the route_localnet sysctl variable. Edit the /etc/sysctl.conf ...


0

Likely these packets have the INVALID conntrack state. Try to add a rule into the filter/FORWARD chain to drop it. iptables -I FORWARD -m conntrack --ctstate INVALID -j DROP Also, the nat targets handle connection only from first to last packets. It means, if you add or remove the nat rule, this rule will affects only for new connections, but the existed ...


0

You use the ip route get command wrongly. The correct command is ip route get <dst> from 192.168.1.113, where <dst> is an ip address of some external host (better run the tcpdump and take the ip from the dump). Your rule is correct, and the command should return the route 192.168.1.255 dev enp5s0 from additional table.


0

I have just figured out the problem myself. While I was writing a support ticket to my hosting provider, I thought about the additional firewall they offer. I assumed it only covered the public IP and not the private subnet on the VLAN. However, after turning that firewall off, everything now works as expected!


0

When you need to match more than what a single iptables rule will allow, you can use multiple rules. The first rule contains the first match and jumps to a chain with the second rule in it, then the second rule contains the other match and the actual target action.


0

I found the solution here: https://superuser.com/questions/1286555/iptables-port-forwarding-with-internal-snat Hope it helps someone else.


0

Try adding iptables rules with conntrack states for ex: iptables -A INPUT -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT It worked for me.


0

The nat OUTPUT chain is used for locally-generated packets: -A OUTPUT -d 95.84.164.43/32 -p tcp -m tcp --dport 80 -m comment --comment "!fw3: http@stratofortress (reflection)" -j DNAT --to-destination 10.196.254.2:80


0

The container is an isolated environment. If you aren't running some services like DNS and NTP on the host itself, there aren't reasons to allow containers access to it. Allow only forwarding traffic to grant access to external networks. Define a list of services on the host, to which containers are allowed the access. And use the input interface match (-i ...


0

I managed to implement this by: 1) adding all iptables rules i wish to apply on a bash script . 2) Copy the bash to the container using the Dockerfile 3) Use again Dockerfile to run the iptables bash script within the container. For example: iptables script #!/bin/bash iptables -I FORWARD -i tun+ -j ACCEPT iptables -I OUTPUT -o tun+ -j ACCEPT iptables ...


0

Because I'm using nftables 0.9.0, and this bug wasn't fixed until 0.9.1.


0

iptables rules are not persistent across reboots. You should try something like the iptables-persistent package in Ubuntu. apt install iptables-persistent mkdir -p /etc/iptables iptables-save > /etc/iptables/rules.v4 ip6tables-save > /etc/iptables/rules.v6 service iptables-persistent start Here is an handy how-to: http://www.microhowto.info/howto/...


0

Turns out that private address is what Digital Ocean calls an "Anchor IP", used internally for routing traffic from Floating IPs. Somebody else had added a floating IP to that Droplet, and I didn't realise. /facepalm Well at least I've learnt something new, and maybe this will help some other confused syadmin some day. Possible solutions: Get rid of ...


0

if you would have checked your /var/log/fail2ban.log or wherever you placed it, and you would see something like this probably 2019-08-01 08:16:14,509 fail2ban.utils [11727]: #39-Lev. 3ef3cd40 -- exec: ipset create f2b-apache-myadmin hash:ip timeout 2160000 firewall-cmd --direct --add-rule ipv4 filter INPUT_direct 0 -p tcp -m multiport --...


0

Run the following command to redirect all traffic headed to (from local processes) port 80: sudo iptables -t nat -A OUTPUT -p tcp \ -m owner ! --uid-owner root --dport 80 \ -j REDIRECT --to-port 8080 Then make sure your local proxy process is running as root. This is so the proxy doesn't have its traffic redirected to itself. If you don't want to run ...


0

tl;dr Your command is very close. You need to remove the -d 127.0.0.1 fragment and ensure you run your proxy process as a different user and exclude that user from the filter with -m owner ! --uid-owner <other-username> so the proxy doesn't have its traffic redirected to itself. More detail I found that most of the suggestions for configuring ...


1

In order to meet your goal, just specify the interfaces where the port should be allowed. In your case limiting 32400 to loopback interface by adding -i lo should do the trick: iptables -I INPUT -i lo -p tcp --dport 32400 -j ACCEPT Please take into account that you are adding rules with -I and you didn't paste a whole ruleset, and it might be relevant. ...


0

Just remove the additional routing rules to use the main routing table with default route through the eth0 interface. Use the ip rule del to do it: ip rule del pref 32758 ip rule del pref 32759 ... ip rule del pref 32765 Also remove inserting of the rules from the network configuration scripts, otherwise these rules will appears again after network ...


1

I've done something similar recently. But as I have to choose between redirecting all traffic and only the vpn traffic. I have configured it in the client.ovpn file. So I have 2 files. One to redirect all traffic through VPN (unsecured networks) And another for split tunneling (secure networks). I only add follow lines in client.ovpn Method 1: Add this ...


0

Okay. So, I thought that the firewall was disabled on the web server VM, but it turns out, it in fact wasn't even though I did stop the service. I stopped it one more time, and now it works with no problems.


2

The rules you've added are good example of "Cargo cult". Anti-spoofing measures are to be taken at gateways (routers); gateways are proper devices because they actually have routing information. Servers don't have this info typically. Often servers have just a single channel and default route towards it. If they happened to get a request they should serve ...


1

The only plausible explanation how it could work is, that the offending UDP datagrams somehow pass --state ESTABLISHED,RELATED. Given that UDP is a stateless protocol, I doubt that the state module has effective tracking over it. To sort out the issue, I'd limit the state check to the TCP protocol by: -A INPUT -m tcp -m state -p tcp --state ESTABLISHED,...


0

The issue turned out to be that Docker was making interfaces with networks that overlapped the source address of the packets. Even though I had cleared out all of the rules docker made in IPtables, I ended up having to change /etc/docker/daemon.json to start networks at a different IP range. I then removed all my containers and deleted all the networks that ...


0

Awesome job, this helped me go down the right path, I appreciate the post. The only thing I noticed is that I believe that the location for LogDenied=all should be /etc/firewalld/firewalld.conf since /etc/sysconfig/firewalld is for startup command line options. Additionally the file for rsyslog might be better named with a .conf, sometimes default include ...


1

You need to run the ssh command on A ssh -N -D 1337 b_username@ip_of_b You can then configure your web-browser or set environment variables to point at this proxy: 127.0.0.1:1337 If you want to use redsocks so that all TCP traffic destined for port 80 or 443 is directed to the proxy then you can update the config: redsocks { local_ip = 127.0.0.1; ...


0

You should add the directly connected routes into your additional routing tables. In the current configuration, when you ping the addresses of the bridge interfaces, replies are routed through gateways (10.10.50.254 and 10.10.99.254) to outside. You can verify the routing with commands: ip route get 10.146.233.2 from 10.10.50.1 ip route get 10.146.233.2 ...


0

The flushing of the iptables rules doesn't affect on already established connections those has been redirected with DNAT. It's related because the conntrack entry for UDP packets contains the redirecting information, that is used aside the iptables rules. Check the existed conntrack entries with the conntrack -L and monitor the conntrack events with the ...


0

Your script to clear iptables rules is enough to flush and all rules and set default policy to ACCEPT. This effectively disables the firewall as there are no rules and everything is allowed. We know, from your comments, you are sending UDP packets. You can feel like the old rules are still active for a while especially when there is a continuous stream of ...


0

sudo ufw status verbose; sudo iptables -L; Maybe there is ufw running on? Try to stop. Could you tell a littlem bit more about your system, network and which traffic is still routed? 1-2 examples are ok incl. the initial firewall rule. EDIT: Checked by some of my scripts..... Also flush the chains. sudo iptables -F INPUT sudo iptables -F FORWARD sudo ...


0

The limit module does not limit based on number of connections but rather on the number of ip packets (even jumbo-packets). So if a single connection takes roughly 20.8 packets then you would see a burst of 500/20.8~=24 connections. see the output of the command man 8 iptables-extensions|grep -e '^ *limit$' -A 18 for more info, specifically the phrase "...


0

Other rules is very important. And the order of rules is too. So, check the output of the iptables-save -c command. Investigate the rules above those, you have created. Between the nat/PREROUTING and filter/FORWARD chains the routing decision is made. Check the routing with ip route get 10.0.1.1 from <src> iif eth0. It should return the valid route. If ...


1

Now - by accident - I've found a solution: sudo sysctl -w net.ipv4.ip_forward=1 sudo iptables -t nat -A OUTPUT -p udp -d 192.168.178.10 --dport 4000 -j DNAT --to-destination 192.168.178.22:4000 sudo iptables -t mangle -A POSTROUTING -p udp -d 192.168.178.22 --dport 4000 -j TEE --gateway 192.168.178.10 This works well, however it seems to be unnecessarily ...


1

The custom chains is bound to a table. It means you cannot use a chain, that has been created in the mangle table, in rules of the filter or the nat tables. The iptables -L command shows only the filter table chains. Check the output of iptables -t nat -L. But better use the iptables-save -c command to list the full rule set with counters.


0

You should use the length match. It supports the range of length. To drop all udp packets with length 1006 bytes: iptables -I INPUT -p udp -m length --length 1006 -j DROP P.S. The iptables -m length --help shows the brief help of the length match. Read the iptables tutorial to understand of the basics. Other rules and order of the rules are very ...


Top 50 recent answers are included