Hot answers tagged

5

Here's the rules you're looking for: iptables -A INPUT -p tcp -s 202.54.20.22 --sport 5000 -j DROP iptables -A OUTPUT -p tcp -d 202.54.20.22 --dport 5000 -j DROP If the service sends UDP packets, you have to change -p tcp with -p udp.


4

Use Multiport for that iptables -A INPUT -p tcp --match multiport --dports 16000:65535 -j DROP also you may try iptables -A INPUT -p tcp --dport 16000:65535 -j DROP


3

As for firewalls, I would be worried where they are placed, your Internet speeds, and how much rules you need on them. They can pretty much dictate the kind of hardware you will need. Be aware for more performance/higher speeds you may need better NIC cards. In the past I used top tier Intel Pro cards. About router/firewalls in ISP settings, I used to have ...


3

With RHEL 7 / CentOS 7, firewalld was introduced to manage iptables. IMHO, firewalld is more suited for workstations than for server environments. It is possible to go back to a more classic iptables setup. First, stop and mask the firewalld service: systemctl stop firewalld systemctl mask firewalld Then, install the iptables-services package: yum ...


2

I'm pretty sure anything coming from the local machine never goes through the PREROUTING table, as seen in this awesome ASCII figure.


2

As the chain names suggest, PREROUTING is done at first when a packet is received and is thus routed based on where it is going (destination). After all other routing rules have been applied, the POSTROUTING chain will determine where it goes based on where it came from (source). For example, on my server, incoming ports that are to be forwarded (NATed) ...


2

The problem was a missing module XT_TCPUDP There is the full list of dynamic loaded module for my command : xt_nat 1527 1 - Live 0xbf12f000 xt_tcpudp 1961 1 - Live 0xbf12b000 iptable_nat 2396 1 - Live 0xbf127000 nf_conntrack_ipv4 11354 1 - Live 0xbf120000 nf_defrag_ipv4 1331 1 nf_conntrack_ipv4, Live 0xbf11c000 nf_nat_ipv4 3401 1 iptable_nat, Live ...


2

nftables are currently under development to replace iptables, and while they don't say as much, I would consider it "beta" for now. I don't have any insight into their timeline, but you can read more here: http://netfilter.org/projects/nftables/ Many linux distributions already have iptables enabled by default. Either it's compiled in, or they load the ...


2

You have to block tcp and udp ports: iptables -A INPUT -p tcp --match multiport --dports 16000:65535 -j DROP iptables -A INPUT -p udp --match multiport --dports 16000:65535 -j DROP


2

netstat shows you that something (probably Labview) is listening on that port. Your iptables line will block packets from outside the computer arriving at that port, and so there should be no problem. The program is listening, so you see that the port is open when executing netstat, but packets cannot arrive from outside, and so one cannot access the port ...


2

I assume by "local access" you mean you want containers to be able to talk to each other and the docker host, but not be able to get to the network outside the docker host ? You have a couple of options. 1. Use iptables to drop all packets to/from your external network interface in the DOCKER chain. iptables -I DOCKER -i eno1 -j DROP (eno1 might be ...


2

Shorewall is a tool for configuring iptables/netfilter firewall rules, so the documentation for netfilter is a more effective place to look. It says: It is perfectly legal to specify an interface that currently does not exist; the rule will not match anything until the interface comes up. This is extremely useful for dial-up PPP links (usually interface ...


2

If the ports are contiguous, like yours are, then use the --destination-port,--dport [!] port[:port] syntax to set up the range: ... --destination-port 16000:65535 ...


2

In order for NAT to work, you need to have a protocol-specific helper module loaded. By default, you're only going to have ones for TCP and UDP loaded. That's why you're seeing your PPTP traffic (which is actually PPP over GRE) escaping without NAT. That module is nf_nat_proto_gre, at least as of Linux 4.4. A similar story applies to connection tracking ...


1

No it doesn't. Those rules works on TCP and IP level and does not process data in higher level (HTTP) To learn more about how iptables-based NAT works, see here


1

If your target IP (165.93.198.220) is another system in the network add an ACCEPT rule in the FORWARD chain like this: iptables -A FORWARD -p tcp -d 165.93.198.220 --dport 8080 -j ACCEPT also check if ip forward is enabled: sysctl net.ipv4.ip_forward if it is not set to 1, enable it on the fly with: sysctl -w net.ipv4.ip_forward=1 or echo 1 > ...


1

for squid3 transparent proxy write.. http_port 3127 transparent force traffic from 80 to your port 3127 iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to-destination Server.ip.Address : 3127 to make sure it takes that route close/block port 80 all traffic coming from lan network can't access port 80. iptables -A INPUT -i eth0 -p tcp ...


1

in my case in centOs 6.7 i use this iptables rules: iptables --table nat --append POSTROUTING --out-interface ppp0 -j MASQUERADE iptables -I INPUT -s 192.168.0.0/24 -i ppp0 -j ACCEPT iptables --append FORWARD --in-interface eth0 -j ACCEPT iptables -A INPUT -i eth0 -p icmp -j ACCEPT iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE && ...


1

I had the same problem with mqtt broker called vernemq, but solved it by adding the following. $ sudo vmq-admin listener show To show the list o allowed IP's and ports for vernemq $ sudo vmq-admin listener start port=1885 -a 0.0.0.0 --mountpoint /appname --nr_of_acceptors=10 --max_connections=20000 To add any IP and your new port. Now you should be able ...


1

Can you try this setup: iptables -t nat -A INPUT -p tcp --dport 5000 -j DNAT --to-destination 192.168.2.3:5000 iptables -t nat -A SRCNAT -j MASQUERADE You can see more examples here. It should work, but why are you trying implement at firewall level anyway? If you have a webserver at your host 192.168.2.14 why don't you just add redirect to the right ...


1

If you only have ACCEPT rules but some traffic ends up being blocked, it means that your rule's policy is DROP. So your first attempt denies all traffic that isn't explicitly authorized. Your second attempt also denies all traffic that isn't explicitly authorized, but the second rule allows most traffic (it only blocks a few things that should be allowed ...


1

Those firewall rules ordinarily suggest that traffic is otherwise blocked, and they only serve to allow traffic to and from the given port. Since apparently all traffic is allowed by policy, these rules add nothing to it. Next, the second routing rule likewise doesn't seem to be of much use, since the $dev device already would have the $route_vpn_gateway IP ...


1

It is partially possible. You can route traffic based on IP to a certain interface through judicious manipulation of your system's routing table. Specifics of how to do this are extremely dependent on your specific goals, but in general you're looking at route add commands. This requires that the upstream connections be able to handle the types of routing ...


1

try this: iptables -t mangle -L -t mangle = access mangle table -L = show list of the rules to remove all the mangle rules you can use: iptables -t mangle -F -F = flush / delete all rules.


1

To list all mangle iptables rules by specification: iptables -t mangle -S This will list the rules as you specified them, for easy copy paste. Replace the -I or -A with a -D to delete them. To remove those two specific rules type: iptables -t mangle -D PREROUTING -j TEE --gateway 10.20.0.129 iptables -t mangle -D POSTROUTING -j TEE --gateway 10.20.0.129 ...


1

I'd use shorewall in preference to writing iptables rules directly. There are also alternatives such as firewalld. With regard to kernel compilation it really depends whether or not the features that you need are available either in the stock kernel or as a modular add-in. If they are not, then you're going to need to roll your own. However, that's not ...


1

sed -e "$(awk '/^[[:space:]]*(#|$)/ { next } ; { print "s/ PROTO="$2" / PROTO="$3" /;" }' \ /etc/protocols)" /path/to/iptables.log This uses awk to construct a sed script from fields 2 and 3 of the /etc/protocols file. It then runs that sed script on /path/to/iptables.log. This will convert ALL numbered protocols in the log file ...


1

TL;TR: FTP is a broken protocol and FTPS more so. Due to a combination of protocol design and encryption it plays very bad together with firewalls. Try to use SFTP (i.e. file transfer over SSH protocol) instead. FTP consists of a control connection (usually port 21) and the data connections. Which ports are used by the data connections are dynamically ...



Only top voted, non community-wiki answers of a minimum length are eligible