Tag Info

New answers tagged

1

I'm by no means an iptables or firewalld expert, but it seems to me something like this would work: firewall-cmd --permanent --direct --add-rule filter INPUT -p esp -j ACCEPT firewall-cmd --permanent --direct --add-rule filter OUTPUT -p esp -j ACCEPT If you have zones and such all setup, you could also do it with the --zone and --add-rich-rule options ...


2

You'll need to use a (fairly simple) rich rule for this. For example: firewall-cmd --zone=vpnendpoint --add-rich-rule="protocol=esp accept"


0

The solution is not to implement routing rules in order to duplicate packages on the two interfaces, but to merge the interfaces into one. For this, you have to create and use a network bridge. The bridge shall have a unique IP addresses, whereas the "real" interfaces shan't, even if they shall be up. # apt-get install bridge-utils # ifconfig bnep0 up # ...


0

INPUT and OUTPUT are defined solely with respect to the system on which iptables is running. To put it another way, iptables doesn't care what sort of systems are on any of its interfaces; it doesn't care whether an interface connects to your trusted LAN, or a DMZ, or a tank full of sharks with laptops. INPUT always refers to traffic entering an interface ...


0

Your DNAT rule is not specific enough. It is applying to all traffic being forwarded through the host to port 443, regardless of origin or destination. To resolve the problem, make the rule more specific, such as by specifying that it applies only to inbound traffic from the outside world. If this arrives on the eth0 interface, then you would add -i eth0 to ...


0

Your kernel ignores packages that are not addressed to the local network interfaces. You should change eth0 to promiscuous mode: ip link set dev eth0 promisc on You could make this persistent via the network configuration: Debian auto eth0 iface eth0 inet manual up ifconfig eth0 promisc up down ifconfig eth0 promisc down Redhat ...


5

You can't do this at the firewall layer (well, you can - but it won't accomplish what you think it will, nor what you want). The second packet (which you desire) is part of the same TCP stream as the first packet (which you don't want), and TCP is a reliable delivery mechanism. That means that the OS knows if a packet in the middle of the stream has gone ...


1

Most certainly your server is trying to resolve 'target-express.com' and it is failing. The reason it is failing is the NS servers for 'target-express.com' are not properly setup. (Google 'lame servers'). Doing 'dig +trace' shows two NS records for the domain, but if you query those domains, there is no response. Now the question is who is querying your ...


1

Could your DNS forwarders be forwarding requests back to the original server? If so this might be something like the problem I had last year (see Windows DNS servers repeatedly requesting records in zone when they get SERVFAIL response). Fix is to not have forwarding loops. This only shows up as a significant problem with zones that return SERVFAIL because ...


4

You can block/Allow based on IPs as well. In the man Page http://linux.die.net/man/8/iptables -s, --source [!] address[/mask] Source specification. Address can be either a network name, a hostname (please note that specifying any name to be resolved with a remote query such as DNS is a really bad idea), a network IP address (with /mask), or a ...


0

Also occurs if your configuration produces 'multiport' and 'all' together ('all' can be used to work around bots switching from tcp to udp, which fills logs with "WARNING: ... already banned"). $ sudo iptables -I INPUT -p all -m multiport --dports ssh -j fail2ban-ssh iptables: multiport needs `-p tcp', `-p udp', `-p udplite', `-p sctp' or `-p dccp' $ echo ...


3

Canonically, that ESTABLISHED rule is actually RELATED,ESTABLISHED. It won't affect SSH or HTTP(S), though—the difference is that RELATED also encompasses what are technically new connections, but at related to an existing one, as in FTP data channel communications or ICMP echo replies. Overall, what you have done here is just fine.


4

I used chain which logs everything with limits so it won't spam your syslog $IPT -N DUMP > /dev/null $IPT -F DUMP $IPT -A DUMP -p tcp -m limit --limit 3/minute --limit-burst 3 -j LOG --log-prefix "TCP DUMP: " $IPT -A DUMP -p udp -m limit --limit 3/minute --limit-burst 3 -j LOG --log-prefix "UDP DUMP: " $IPT -A DUMP -p tcp -j REJECT --reject-with ...


0

The tun tap device appears the same to the kernel in that it can't tell whether the data comes from a wire connected to an ethernet interfaces or from a userland application. When data is written it is forwarded to the userland application rather than a physical interface device eg. eth0 The interface a packet is forwarded to will be based on the routing ...


0

If you want redirect only http/https it's better user nginx (but you can apache) Depending on what your Web Server is (Apache, NGinx) you should consider an HTTP Proxy on your front-end server: proxy_pass (NGinx) mod_proxy (Apache) You can use bridges to provide for some VM dedicated IPs. Iptables solution iptables ...


0

Perhaps you need to turn on forwarding in the kernel with: sysctl -w net.ipv4.ip_forward=1


0

Unfortunately, there has been an error in the Firewall of my (external) MySQL host which I didn't know about. The MySQL port was blocked for my vServer's IP after all, so that is why the requests were not coming back and the HTTP requests were working. The issue has been resolved. Always double check all Firewalls! Lesson learned.


1

hi, i have a host system with 2 interfaces, eth0 and eth1. eth0 will receive packets with ip of 127.3.x.x. i want to forward these packets to go out of eth1 to a server (10.0.1). eth1 has ip of 192.168.0.100. the server needs to see the packets as if they are coming from the host (192.168.0.100). i think i can remove -m flag, but when i do, i am getting ...


3

1) What you ask is the simplest way for iptables to work - block all traffic to a destination regardless of connection status, so that existing connections will time out. So in your example iptables -I OUTPUT -d 8.8.8.8 -j DROP will immediately block UDP (DNS), ICMP (ping) and TCP packets reaching 8.8.8.8. So that seems to be your answer. If you are ...


0

ISTR oddities like this before, but there's something missing as you say. The following information might be useful from the router: iptables -t nat -L -n iptables -L -n ip route And this from the mail server: iptables -t nat -L -n ip route grep . /proc/sys/net/ipv4/conf/*/rp_filter Without that info, I think I'd just wipe out your existing firewall ...


0

You appear to have set up a 1-to-1 NAT with the first two iptables rules, but then you've added a third, rather curious rule: iptables -I FORWARD -d 192.168.1.2 -p tcp --dport 25 -j ACCEPT Such rules aren't necessary when doing 1-to-1 NAT, and don't actually do anything useful. Of the information you've given, this appears to be the most likely cause of ...


1

Looks like if I put the last rule as the first one, everything works correctly. So the solution is to use the following iptables rules: iptables -t nat -N REDSOCKS iptables -t nat -A PREROUTING -i eth0 -p tcp -j REDSOCKS iptables -t nat -A REDSOCKS -d 0.0.0.0/8 -j RETURN iptables -t nat -A REDSOCKS -d 10.0.0.0/8 -j RETURN iptables -t nat -A REDSOCKS -d ...


1

INPUT, OUTPUT and FORWARD are three separate chains. A packet will only hit one of these three. The order for forwarded packets is: PREROUTING -> [routing] -> FORWARD -> POSTROUTING. The netfilter doco is pretty good on this topic: http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-6.html


0

Your two reject rules are in the wrong place. As currently written, these rules will only let traffic through on port 22. The "catch all" reject rules need to go after all of the accept rules.


0

What kind of hardware are you using? It sounds like you might be working on an embedded device, in which case you should probably go with the netfilter option. But if you have more resources at your disposal, you should consider using OVS (http://openvswitch.org/), which is the de-facto open source standard for software defined networking. Software defined ...


4

Well, unless you cut-and-pasted it wrong, that first line should also start with a comment. That is, change Firewall configuration written by system-config-firewall to # Firewall configuration written by system-config-firewall You might want to pay closer attention to that second line, too; there's nothing wrong with it, but you should probably read ...


1

You should probably enable ip forwarding in your servers. It is usually done by $ sysctl net.ipv4.ip_forward To make the changes permanent you must edit /etc/sysctl.conf and set net.ipv4.ip_forward = 1


0

In first example you are using "--src" which is incorrect swich, you should either use --source or -s. In second example, you are creating new chain named "xchain", and you are filtering packets there. But, if you don't point packets from other chains to go traverse xchain, those filters will never get matched. Also, you've send packets from INPUT chain to ...


0

After further research, it seems that the best solution is to use libvirt's built in network filters: https://libvirt.org/formatnwfilter.html


5

Netfilter (iptables) has queue module to send frames to a userspace program. Libraries for different languages (c, python, perl, etc...) are available to examine packets. After processing a frame you will return an ACCEPT or DROP verdict, the original or modified frame, and an option to set a mark. My guess that you can use the mark to handle this packet ...


0

The next three commands can put all incoming packets from two ip addresses to current host $iptables -t nat -A PREROUTING -s 1.1.1.1 -p tcp --dport 1234 -j DNAT --to-destination 1.1.1.2:1234 $iptables -t nat -A PREROUTING -s 2.2.2.1 -p tcp --dport 1234 -j DNAT --to-destination 2.2.2.2:1234 $iptables -t nat -A POSTROUTING -j MASQUERADE


1

Your are getting this problem as your are using !. Say, one request comes and if mac address of coming host in that is other than mac address of host A, it will be redirected. And hence it is also being redirected for host B. And your second rule will never be executed. So the solution for, how to except my mac address list? Jump to one custom chain ...


1

One cheap and cheerful way is to look for the second packet in the three-way handshake. It's easy to spot, as unusually it has both SYN and ACK flags set, which is generally unique to a given connection. Although it is still possible for the originator not to respond with the third and final packet, that's entirely by the grace of the originator: at this ...


2

If you are running services via Docker, then changes to your INPUT chain will not have any effect. The iptables INPUT chain is for traffic that is destined for your host. A docker container has it's own IP address, so when your host receives a packet on one of the exposed ports, it is forwarded to the container. This means that rules in your FORWARD chain ...


1

Both options are incorrect. The right answer is : An error will occur. Because DNAT can only be used in PREROUTING or OUTPUT chains.


0

To see the packet flow through iptables check the NetFilter iptables packet flow diagram. https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg In short, the routing decision occurs after PREROUTING and before POSTROUTING. Besides, I think you cannot do DNAT on POSTROUTING anyway. iptables will throw a syntax error.


0

Your policies are applied one after the other. Your default policy should then be applied at the end, not the begining. So you should remove this block: # Bloque tout le trafic sudo iptables -t filter -P INPUT DROP sudo iptables -t filter -P FORWARD DROP sudo iptables -t filter -P OUTPUT DROP and add this one at the end of your script: # Bloque tout le ...


0

Teeproxy could be used to replicate traffic. The usage is really simple: ./teeproxy -l :80 -a localhost:9000 -b localhost:9001 a production server b testing server When you put a HAproxy (with roundrobin) before your webserver you can easily redirect 50% of your traffic to testing site: /------------------> production HAproxy / ...


0

Your rules are dropping ICMP. This is wrong for both IPv4 and IPv6, and it will notably break PMTU discovery; however, most IPv4 stacks implement workarounds for this (very common) kind of misconfiguration. For IPv6, however, many things will be broken, notably access from Teredo hosts. A simple solution is to add rules to allow ICMP: iptables -A INPUT ...


5

Userspace routing can be achieved by pointing a default route at a tun device, and having a userspace program examine each received packet. It's an inefficient and brittle approach, but it has been made to work — there was an AODVv2 implementation that worked that way, due to Henning Rogge. The other option, of course, is to implement your routing protocol ...


0

You're right about marking packets using the firewall, but you should not be routing them at that level — use multiple routing tables. First, set up your main routing table so that it routes through eth0: ip route add default via XXXX dev eth0 Once the tunnel is up, set up a secondary routing table that routes through tun0: ip route add default via YYYY ...


0

On the off-chance that you have a BGP-enabled router or two in your stack AND have some kind of idea what the hell it is you're doing/work with someone who knows what the hell it is they are doing, or are maybe behind a DDoS prevention provider cool enough to assist in the implementation of this, there's a relatively fresh method for restricting traffic to ...


1

If you wanted to retain the ability to connect from anywhere without maintaining a geo-location blacklist/whitelist, you could implement port-knocking. It would stop most automated attempts while allowing you to still connect from any address. Note: Don't put the port to knock adjacent to the port to open, otherwise a sequential port scan will activate your ...


0

The answer is as Michael Hampton stated in the comments... Almost the exact same issue as: Debian Squeeze ip6tables setup My final ip6tables rules are as follows: *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp ...


1

Ignoring the bit about whether or not doing it this way is a good idea, you can do what you asked for with the GeoIP module for iptables. After building and installing the module (and keeping your IP lists updated monthly), you can do stuff like this to block individual countries: iptables -I INPUT -m geoip --src-cc CN -j DROP Or use --src-cc US -j ...


0

Transparent proxying is a little involved when it comes to HTTPS. I know squid supports a MITM setup that should work - they call it SSL bump. It is possible to do this without MITM but I don't think squid supports this yet. Various commercial web filters do.


5

What you need is a tool called ipsets IP sets are a framework inside the Linux kernel, which can be administered by the ipset utility. Depending on the type, currently an IP set may store IP addresses, (TCP/UDP) port numbers or IP addresses with MAC addresses in a way, which ensures lightning speed when matching an entry against a set. the important ...


33

Setting up specific rules to block every IP range (by listing every range) is the wrong approach. Set the default rules in iptables to drop all traffic to your management ports. Then add rules to only allow access from your trusted IPs (yours and your host). Blocking everything by default, and allowing only approved traffic is usually called "explicit ...


9

In order to do this, you would have to add tens of thousands of firewall rules, one for each netblock, where a country may have anywhere from one to several thousand netblocks associated with it. When a request comes in, it would have to be checked against every single rule, which takes very little time for a few dozen or maybe even a few hundred rules, but ...


1

You are not. But I think it would be simpler and more ideological to change the FORWARD policy to DROP, and then adding just the rules you need in order the packet forwarding works only when needed. This will exclude any possible mistakes. You could also use another approach, which is more complex, but also more flexible. You could create separate routing ...



Top 50 recent answers are included