Tag Info

New answers tagged

0

I found that a slash notation mask of /32, implies one single host. Thanks Binary Hex Quad Dec 2ⁿ CIDR Number of addresses 00000000000000000000000000000000 00000000 0.0.0.0 2³² /0 4,294,967,296 4 G 10000000000000000000000000000000 80000000 128.0.0.0 2³¹ /1 ...


1

When you use a -A (for APPEND) iptables command, your rule is added at the end of the table. The way rules are evaluated are from the first to the last, and any matching rule that results in a decision (ACCEPT, REJECT, DENY) stops the evaluation of any subsequent rule. So here, what happen is that your DROP rule will never matter, since if iptables ...


0

You are using the recent module to dynamically maintain a list of IP addresses for each connection attemp to port 22 and refuse IPs trying to connect more than 4 times in a minute or using changing TTLs (note: this last check could cause trouble to legitimate connections too in some cases). However, you are doing it wrong because you are not adding them ...


2

Your iptables rules are doing exactly what you want: they're blocking outbound port 25 connections: May 21 14:50:12 CentOS-70-64-minimal postfix/smtp[5484]: connect to mx.domen.tl[93.158.134.89]:25: Connection timed out Unfortunately, your server appears also to have a valid ipv6 address (I'm guessing it's a modern VPS, I've noticed most of these come ...


0

As you said, you have the default chain policy set to DROP. So, you need to have explicitly ACCEPT rule for each type of traffic you want to allow. The following rule will allow traffic passing through your box coming from lan0 interface and going out of interface wan0. iptables -I FORWARD -i lan0 -o wan0 -j ACCEPT Also, it is a good idea to allow other ...


1

If you can ping, there is traffic in your bridged interface. You can watch the traffic using the appropriate options of tcpdump: tcpdump -elnXXi br0 In the same way, you can totally filter this traffic using iptables, taking into account that it will only operate to the IP layer. You would need ebtables if you need to filter traffic on layer 2 (Ethernet)


1

The correct syntax, as described in the firewalld.richlanguage(5) manpage, is: # firewall-cmd --zone="FedoraWorkstation" \ --add-rich-rule='rule family=ipv4 source address=1.2.3.4 service name=smtp reject' success # iptables-save | grep 1.2.3.4 -A IN_FedoraWorkstation_deny -s 1.2.3.4/32 -p tcp -m tcp --dport 25 -m conntrack --ctstate NEW -j REJECT ...


2

Ok, after a small chat with Yahia Zakaria I managed to pinpoint the problem. The app uses more than TCP to communicate, so the proper DNAT should look: iptables -t nat -A OUTPUT -d 192.168.1.15 -j DNAT --to-destination 54.3.22.1 And that's basically it.


2

Routing table looks okay, look at metric column. Route with the lowest metric will be preferred. Your routing table contains now two default routes and 10.11.12.13 will be preferred over 192.168.178.1 because of lower metric. About the traffic on physical interface; this is also normal because you have listening services which respond for ...


1

Using this rule You blocks only packets that match with conditions (input, 270 length), --syn packet made connection established already, so all next packets with length less than 270 will be permit. So, "to reject the first packet after check the length of third packet" is impossible, connection already exist. But, "Drop or Reject the whole connection" ...


0

Try to add interface name in Your rules: -i eth0 for INPUT rule and -o eth0 for OUTPUT rule. To find Your own interface name You can with command: ifconfig


3

It seems that you are not using the available tools in an appropriate way. The tool iptables-save will dump your current ruleset from memory to stdout. It will not save the rules in any file unless you explicitly redirect its output. Also, you are mixing two things: using iptables tool and using ufw at the same time. I recommend to go all the way with one ...


4

AFAIK, pf does not have the flexibility and modules available in iptables. iptables comes with really large number of modules that provide more match options and others that provide more targets. You can even develop your own module. This page provides some explanation regarding iptables development if you are interested.


0

As it turned out, a simple postrouting rule did the trick. iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o eth0 -j SNAT --to 1.2.3.4 I also had to delete a bunch of MASQUERADE postrouting rules that were just creating a big mess.


0

Add the IP and appropriate hostnames/aliases to /etc/hosts.


0

That all seems overly complicated to me and subject to becoming one of those "customized" solutions that tend to become a problem in the future (i.e. "so-and-so set this up long ago before leaving the company and no one knows how to change it"). So, I personally would look at something that is a bit more standards based. Unless you have a need for devices ...


0

I had to deal with a similar situation when organizing large LAN parties (>500 users), where you don't have control over the workstations, pretty interesting. if your L3 switch (router, technically) is reasonably high grade, it is probably manageable by SNMP, and you can read its ARP table for the appropriate subnet (the one that directly connects to the ...


2

Try something along the lines of this: ip6tables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-port 80 Your packet would not be hitting the INPUT chain for the nat table. Incoming packets go through iptables like so: On the wire -> raw:PREROUTING -> mangle:PREROUTING -> nat:PREROUTING - > routing decision -> mangle:INPUT -> filter:INPUT -> ...


1

The DOCKER chain is a custom chain defined at the FORWARD chain. When a packet hits any interface and is bound to the docker0 bridge interface, it is sent to the custom DOCKER chain. pkts bytes target prot opt in out source destination 54492 21M DOCKER all -- any docker0 anywhere anywhere ...


1

You can just deny the request for those ip's from the virtual host with a rewrite. RewriteEngine On RewriteCond %{REMOTE_ADDR} ^185\.62\.189\.92 [OR] RewriteCond %{REMOTE_ADDR} ^186\.62\.189\.92 [OR] RewriteRule ^(.*)$ - [F,L]


0

Your rules ACCEPT packets up to a certain rate, but is there anything after that that DROP the traffic when it doesn't match the rules? Either default chain policy (-P) or an explicit rule... What you could do is change your rules to DROP traffic with --hashlimit-above; ex: # iptables -t filter -A it2net -s 10.5.2.43/32 -m hashlimit --hashlimit-above 8kb/s ...


0

Since you want to affect the traffic generated on the local machine, you need to edit the OUTPUT target rather than the PREROUTING. (Or maybe keep both of them)


3

As I and others are telling you above, blocking traffic with iptables doesn't prevent it from reaching your server; it only stops your server from processing it. If the sheer volume of traffic is saturating your server's connection, and causing you to lose connectivity to it, you have no choice but to work with your hosting provider, to have them filter out ...


1

The problem is that the MAC filter rule is processed after accepting it. So it is never reached. What you need to do is change the order of these two lines: -A FORWARD -i eth1.10 -o eth0 -j ACCEPT -A FORWARD -i eth1.10 -p tcp -m tcp --dport 443 -m mac --mac-source 00:60:DD:44:85:43 -j DROP So they become: -A FORWARD -i eth1.10 -p tcp -m tcp ...


0

I believe you actually need to put MAC filter in the PREROUTING chain because of the way iptables re-writes some fields internally. From Chain traversal for routing, when the bridge and netfilter code are compiled in the kernel The side effect explained here occurs when the netfilter code is enabled in the kernel, the IP packet is routed and the out ...


1

Privoxy is an HTTP proxy. What you're trying to do is feed it intact network packets, which I'm 99% sure it's not going to accept that without some very complex mangle rules in iptables. Instead you should expose the proxy to the VPN (seems like it is already), and push it as a DHCP option to your VPN clients. Instructions for doing that via OpenVPN can be ...


2

You can push proxy configuration to the OpenVPN clients. From the OpenVPN Access Server web interface go to Advanced VPN Settings → Server Config Directives and enter the following directive with your proxy ip/port info. push "dhcp-option PROXY_HTTP 111.222.333.44 8118" I am not sure if all OpenVPN clients support this config. But on IOS it works well.


0

Is kernel module nf_conntrack exist at /lib/modules//kernel/net/netfilter/ and loaded? If exist try: modprobe nf_conntrack


1

I have managed to diagnose my own problem. The IPtables are fine. The problem was my understanding that I could not (as configured) test port forwarding of port 7022 on the external IP from the internal network. The issue is covered quite well in the canonical answer to "hairpin NAT" which explains how to route an internal client through the FORWARD ...


4

You need to add the system-config-firewall-base package, which provides the lokkit command used to configure the firewall during kickstart. Versions of RHEL/CentOS prior to 6.6 automatically included this package, see https://bugs.centos.org/view.php?id=7956 and https://bugzilla.redhat.com/show_bug.cgi?id=1161682 for discussion of the issue.


0

Why to use NAT? In this scenario, you can directly router between the two LANs, without port forwarding at all. Anyway, if you really want to use NAT, port 5060 should be sufficient if your clients are standard SIP ones. If they are mixed/custom protocol clients (eg: Cisco H323 and/or SCTP/SCCP implementation) you will need to open additional port ranges. ...


0

You need to allow destination port 22 on the input chain, it's only on the forward chain.


1

The masquerade rule is wrong: iptables -t nat -A POSTROUTING -s '192.168.0.0/24' -o vmbr0 -j MASQUERADE It is saying that packets going out the vmbr0 interface and from 192.168.0.0/24 should be masqueraded. But no packets will ever match this, because they aren't going out the vmbr0 interface! Instead they are going out your physical interface. Change ...


1

First: You don't want to do it this way, as I describe below. Second: a very similar problem is answered here http://spamcleaner.org/en/misc/w00tw00t.html . I'm relaying their solution to your specific question. There is an iptables string module which you can use to match the browser agent. However, iptables will then inspect every packet ... we can ...


1

You sire, are a scholar, a gentleman, and a saint! On my second server, I added a virtual loopback device with the IP of the first server, and IT'S ALIVE! Here is how to add a virtual loopback device in Centos 7: cd /etc/sysconfig/network-scripts cp ifcfg-lo ifcgf-lo:1 vi ifcfg-lo:1 and put in that file: DEVICE=lo:1 IPADDR=10.88.72.41 ...


1

You need to use the PREROUTING chain to forward port : iptables -t nat -A PREROUTING -p udp -i eth0 -d 192.168.1.2 --dport 1003 -j DNAT --to-destination 192.168.1.2:1004 By the way, it seems filter is happening directly on the target host, so you could use REDIRECT in that case : iptables -t nat -A PREROUTING -i eth0 -d 192.168.1.2 -p udp --dport 1003 -j ...


1

Thanks for your answer, but i was not an iptable problem, but an apache one. I have varnish listening on the 8080 port, and a port.conf config was blocking any connection directly on 8080 I've fixed it by writing NameVirtualHost *:8080:127.0 Listen 8080 Before it was NameVirtualHost 127.0.0.1:8080 Listen 127.0.0.1:8080


0

Add the: -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7 rule to the end of the INPUT chain instead of near the top. It will allow all the allowed ports through and then limit+log any unwanted traffic.


1

It sounds very much like you want to use what was some-time-ago known as 'port knocking' (thankfully it seems to have been a short-lived fashion). I believe there is google-able software for that, now that you know what you need to do. ... I would suggest though that it would be better to use something like a VPN or a client-side SSL certificate (preferably ...


0

Just configure mysql to use port 41020 for networking while usual 3306 is still blocked.


3

To change the state of the network link for a KVM guest it would be much better to use the appropriate tool, i.e. the hypervisor virsh domif-setlink domain interface-device state Modify link state of the domain’s virtual interface. Possible values for state are "up" and "down". If --config is specified, only the persistent configuration of the ...


0

I am not sure what is going on but suspect a routing problem/mismatch is a possibility. Have you tried usinga tool like tcpdump to check is the packets make it and the route the take?


1

You've got an asymmetric routing situation involving NAT, here, and that isn't going to work. Of course, if your target instance has a public IP anyway, it would seem that there's not much of a bastion effect going on at the bastion host... but assuming you have a logical reason, here's my take on the problem: Let's call the client machine C, the bastion ...


0

You have RELATED,ESTABLISHED rules only for interfaces eth0 and eth1, therefore the answer of the web server to the connection request of cURL will be dropped by iptables because it is not accepted by any rule. Changing the RELATED,ESTABLISHED rule so it applies to all interfaces should solve the problem. Do not use rules accepting traffic from specific ...


0

The issue is with the iptables -A OUTPUT -j DROP and how ports are used. Thou you have allowed port 20, 21, and 22. You will never use these ports as your outgoing port. They will be a random number high up in the port range. Try adding someting like sudo iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT before your iptables -A OUTPUT -j ...


0

Finally, opening port 3306 on the docker0 interface solved my issue : iptables -t filter -A INPUT -p tcp -i docker0 --dport 3306 -j ACCEPT iptables -t filter -A OUTPUT -p tcp -o docker0 --dport 3306 -j ACCEPT


1

You are correct that with the REDIRECT, Squid cannot see the original intended destination IP; instead it will resolve the host provided by the client in the Host: HTTP header, which is mandatory in HTTP 1.1.


0

That is very similar to the gateway. When client host does not know where the destination host reside, it send the packet to the default gateway. And gateway define where that packet should be sent. Transparent proxy do the same. All packets to the xxx.xxx.xxx.xxx:80 are diverted to the port 3128 instead of port mentioned in the packet header. Squid ...


0

Here is a full explanation, which might help you understand it all http://lartc.org/howto/lartc.cookbook.fullnat.intro.html


0

What I've found instead is -- most daemons are capable of using Unix sockets and you can mount that socket from the host into the container with -v . The ancient trick of everything is a file comes very handy. For eg docker run -v /var/run/mysqld/mysqld.sock:/tmp/mysql.sock. Inside the container you will connect to /tmp/mysql.sock. Also the same trick works ...



Top 50 recent answers are included