New answers tagged

1

had the same question and found Zoredache pointing to TRACE / ipt_LOG was the solution! Additionally I found a script which inserts/removes LOG-rules preceding all currently active iptables rules. I tried it out and found it to be a really nice tool. - Output is similar to the TRACE solution - Advantage: it works on the active iptables configuration, no ...


1

Is there a reason for these?: -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP -A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP It looks like you're blocking all new (SYN) connections? I'm surpised anything ...


0

thank you for explanations. i thought it needed to be done with marking packets. i figured out by using mangle # iptables -t mangle -L PREROUTING -nv CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK restore MARK all -- eth4 * 0.0.0.0/0 0.0.0.0/0 MARK set 0xc8 MARK all -- eth1 ...


0

When packets come in via interface X, and are responded to immediately by the same machine, then your source-based routing rule can catch the response because its source IP address will necessarily match the rule. When these packets are subsequently forwarded via interface Y to another IP, that first part of the communication will work. But as soon as the ...


0

So, for anyone reading, i have managed to solve this. Zebra's Static Routes which allows me to have 2 routes for the one subnet. I had to remove the original route on the cloud box, and then zebra took over and all traffic is sent between those 2, equally... happy days!


0

I. iptables Did you add the log line after your existing rules ? If you did, there is what I think about your issue. -j ACCEPT end the path of the packet in the rule. So a log line means your 6 rules didn't match. The FORWARD default policies is ACCEPT, so packets are accepted anyway when they hit the end of the FORWARD chain. You should change this ...


1

The problem is now at least partly solved (I'm fine with this). I was testing the network with Windows clients in the beginning, and both PCs had got the Windows 10 upgrade lately. The problem itself was really stupid: Windows didn't response to pings since there is some new security enabled by default in Windows 10. When I added one Linux laptop to the ...


1

First, your default policy in the FORWARD chain is ACCEPT, so you're not actually denying any traffic. This explains why the 20 -> 50 forwarding works. You can fix this with iptables -P FORWARD DROP. As far as the other pings, notice that in your log entries, the TTL is either 127 or 63, indicating the firewall has already made its routing decision and ...


1

It seems that: iptables -A PREROUTING -t mangle -i eth0 -m cluster --cluster-total-nodes 2 --cluster-local-node 1 --cluster-hash-seed 0xdeadbeef -j MARK --set-mark 0xffff iptables -A PREROUTING -t mangle -i enp1s0 -m cluster --cluster-total-nodes 2 --cluster-local-node 1 --cluster-hash-seed 0xdeadbeef -j MARK --set-mark 0xffff helped to get it running.


0

Per redhat.com - 9.7.3 Running NFS Behind a Firewall - Procedure 9.1. Configure a firewall to allow NFS Allow TCP and UDP port 2049 for NFS. Allow TCP and UDP port 111 (rpcbind/sunrpc). Allow the TCP and UDP port specified with MOUNTD_PORT="port" Allow the TCP and UDP port specified with STATD_PORT="port" Allow the TCP port specified with ...


1

Following the suggestion of user228273 i could find configuration that solved the problem: First I created a tap interface named tap0, and I brought it up: ip tuntap add mode tap tap0 ip link set tap0 up if one of the previous command fails, it is probably because you already have a tap0 interface. Use the command ip link show to assess the situation, ...


0

I have taken a very quick look at your last capture file. We can immediately see that the RTT on the end-to-end TCP session is around 50ms or worse. Your client is advaertising a window around 3MB (not 300MB as I originally typed). Put those together and you have an absolute maximum 480Mbps assuming infinitely fast hardware at each end of the TCP ...


0

After analyzing the packet, it ended up being a UPnP call from the box to all attached devices. Disabling UPnP fixed the problem (no more packets detected).


0

If I correctly understand you, your setup is working, and sometimes, when a new machine is connecting, some logs shows up. You are tring to understand why. Is that true? I have several ideas about your issues, although I can't provide an answer yet. First, I want to be sure there are some "good" connections. To confirm this, you could disable the 1 packet ...


0

Very old post at this point, but its the top google result so I thought I would update with my solution... There must be a blank line after COMMIT or iptables-restore will fail with a "no command specified" error at the line COMMIT is on.


0

See if have enabled options: # sysctl net.ipv4.ip_forward net.ipv4.ip_forward = 1 to enable this : sudo sysctl -w net.ipv4.ip_forward=1


0

I don't remember the syntax for marking the traffic as NOTRACK, but doing it in the raw table is correct. You'll need a rule like iptables -A INPUT -m state --state NOTRACK -j ACCEPT to actually let the traffic through. (and a corresponding rule for IPv6).


1

The MASQUERADE of the iptables plus the /proc/sys/net/ipv4/ip_forward = 1 does the magic. And the matching condition for the -o $EXTIF comes from your routes. You should have one route add default gw x.x.x.x $EXTIF The x.x.x.x should be the inside IP (LAN) of your internet router. With that default gateway the kernel knows the packet it received it's not ...


0

I think you script should look like this: EXTIF=$1 INTIF=$2 WLAN_NET="192.168.10.0/24" echo "1" > /proc/sys/net/ipv4/ip_forward # Flush all rules IPTABLES -F #Allow masquerade only if requested internet address IPTABLES -A POSTROUTING -s $WLAN_NET ! -d WLAN_NET -o $EXTIF -j MASQUERADE #Allow forward from localnet ...


1

It's a conntrack issue. Once the connection is considered "established", the NAT table isn't even consulted, and the traffic will continue to pass. Restarting networking is a brutal way of flushing the conntrack table (because entries get removed when the addresses they relate to get removed); more subtly, there are conntrack table manipulation tools ...


0

Any rules you apply using iptables take affect immediately (loaded in kernel). Most provably you have logical issues in your firewall and/or network configuration. A dump of your iptables rules would be helpful.


0

Delete all duplicated lines except COMMIT /sbin/iptables-save | awk '!COMMIT||!x[$0]++' | /sbin/iptables-restore


1

Assuming you only want to redirect the connections originating from your machine (as opposed to forwarded by your machine), the following rules should suffice: iptables -t nat -A OUTPUT -d hostA -p tcp --dport 3306 -j DNAT --to hostB iptables -t nat -A INPUT -s hostB -p tcp --sport 3306 -j SNAT --to hostA The first one consists in changing the ...


1

Iptables/Firewall "introduction" A Firewall is basically a policy-based network filter. Linux firewalls are built around Netfilter; the kernel's network packet processing framework which is made of several kernel modules performing specific tasks: The FILTER module (always loaded by default) mainly allows us to ACCEPT or DROP IP packets based on a certain ...


0

/edit: Ok, I have found a solution which works rather nice for my needs. I have managed to improve upon the first working idea below. Especially, now I can manage a list of ips to be routed / forwarded directly to A in an external list. I have added the following to /etc/firewall.user # If connection was established before, accept it (so we dont have to ...


1

Your application is most likely listening only to the localhost network interface, that is 127.0.0.1:8082, therefore it can be reached only from localhost. You can check this by running netstat -lnp, and checking the Local address column corresponding to your software. If it is 127.0.0.1:8082, this is the reason and you need to change your software to ...


0

Try to use nat in first rule. iptables -t nat -A PREROUTING -i eth0 -p udp -m udp --dport 57875 -j REDIRECT --to-port 5060 If you have problems again run this command and post information from them iptables -L -n iptables -t nat -L


1

With the assistance of a few friends helping me research this, I was FINALLY able to get it working. Had to run this script in order to properly forward TCP/IP traffic: #!/bin/sh PATH=/usr/sbin:/sbin:/bin:/usr/bin # Primary Connection - 2085426230 IF1=eth0 IP1=172.16.0.2 P1=172.16.0.1 P1_NET=172.16.0.0 # Secondary Connection - 2085420213 ...


0

I found the solution myself thanks in part to @symcbean's comment which got me thinking. It turns out, that for whatever reason, Linux does not route response packets back on the interface they connected on. To fix this we set up advanced routing. ip rule add fwmark 1 table mycustomtable ip route add table mycustomtable 0.0.0.0/0 via 192.168.0.1 dev ...


0

You may also use ferm which i also use for the past year and has helped me a lot with cases such as conditional firewall rules.


1

iptables -L doesn't list NAT rules. To list NAT rules, you have to run iptables -t nat -L Similarly, for any NAT based operations (adding a rule, a chain, deleting, listing, etc), you have to specify the -t option.


0

You should investigate using the ipset module for this: http://ipset.netfilter.org/ Simply add all the IP addresses into a set, and then setup a single iptables rule which drops/rejects packets against that set. Also easy to manage as you can add, remove and empty the set easily, and generally modify it "on the fly", as and when required.


1

When your /etc/rsyslog.conf loads yours *.conf in /etc/rsyslog.d, it reads your files alphabetically. So, you need to make sure that your rules are in a file that comes before 50-default.conf, like: 01-myiptablesrules.conf This way, your rules will be read first, and discard it. You should also use this syntax: :msg, contains, "iptables@@" { *.* ...


0

go into the etc/sysctl.conf file and change **net.ipv4.ip_forward=0** to **net.ipv4.ip_forward=1** **sysctl -p /etc/sysctl.conf** #iptables -P FORWARD ACCEPT #service iptables save For the second question you need to have two interfaces for LAN on your router. Say for example you have Eth3 and Eth4 as your LAN interfaces. Eth3 address for BOB and Eth4 ...


0

So I fixed the problem: As I already guessed, I had to set a separate gateway-entry on 191.167.1.2 with: route add default gw 191.167.1.1 Now I connected the subnet-server to the www via the proxy while MASQUERADE is active.


1

iptables -A FORWARD -i eth0 -j DROP Will not block incoming traffic. You should add rule on INPUT chain, e.g.: iptables -A INPUT -i eth0 -j DROP


-2

As an iptables noob, I'd say: The mangle table allows to modify some special entries in the header of packets. (such: Type of Service, Time To Live ) (it also allows to set special marks and security context marks)


0

In addition to allowing DNS queries, you will need to allow traffic via port 9418. Git uses port 9418 to communicate. You don’t want to open up the port externally so I used stateful inspection to open the port only if we established the connection. # allow git sudo iptables -A OUTPUT -o eth0 -p tcp --dport 9418 -m state --state ...


0

After flushing iptables, I used iptraf to display a real time list of connections to port 3306. The requesting server was a shared hosting server, and the IP address associated with the request differed from the IP address of the web application initiating the request. It was different AND changing. The only solution was to move the application to a VPS ...


3

The issue is the rule order. Entering the commands in that order will end up like this: If port 3306 DROP If port 3306 and Source IP is 1.2.3.4 ACCEPT The issue is you drop the connection for before checking the Source IP. This is because the commands you entered prepend and not append the rules, thus the last command entered becomes the first rule. ...


0

iptables-DNAT rules will be replaced with the following settings. (Script execution user's .ssh/config) Host 10.20.30.40 Hostname 127.0.0.1 Port 1234 If ssh-portforward is running with the same user, I think it good to use the ProxyCommand. Host 10.20.30.40 ProxyCommand ssh server1.test.com nc %h %p


0

Beware: read this only if you have root access to both source and intermediate machines. Since you say source machine (let's call it A ) has no way to contact the destination one (called C ), I assume that there are routing or permission restrictions that prevent this. Restrictions that the intermediate (machine B) can avoid. You can make the source machine ...


0

Either use VPN connections for this (all machines connected via private network) which is safer or port forwarding (which is not a bad idea), just remember to limit connection IP pool on machine in private network.


0

Is there a line in your rsyslog config files that prints the message to /var/log/kern.log? If so, post that code. Also post your rsyslog verison number. In the meantime, this could work: :msg,contains,"iptables@@" /var/log/iptables.log :msg,contains,"iptables@@" ~ Though I believe once you do that second line, rsyslog will ...


0

gosh. After trying to find the problem since 2 hours, I posted the question. An when reading my own post, I saw the answer: Packets are not referred to the services chain when coming in on lo - just eth0+ (and then also not captured in service chain)


0

The best solution for firewall is forbid all and then make a holes. Make one chain for protocol Make rules structured not linear, it help to be faster in big load. For LOG use with limit too, beware full log disk partition. Some example which not cover your example, but show way howto $IPTABLES -n ftp $IPTABLES -n ssh $IPTABLES -n webapp $IPTABLES -n ...


0

It looks like your nginx is listening on your class C IP only and not on 127.0.0.1 REDIRECT target is a DNAT to 127.0.0.1:port, so you could need to listen on 127.0.0.1. Basically, you could use for your troubleshooting these commands to check where are the errors. journalctl -xef -k -n 50 tail -f -n 50 /var/log/access.log


0

Please ensure that the SMTP port (TCP 25) is not blocked, either by your hosting provider or by the ISP/network operator from which you run your remote nmap check.



Top 50 recent answers are included