Tag Info

New answers tagged

0

In postgres you must specify which ips are allowed to connect (even though the fw is open). Maybe percona has a similar configuration option, which you need to enable?


0

iptables forwarding between two interface http://askubuntu.com/questions/338100/forwarding-traffic-between-2-interfaces Good info in both of those links for this. You might need to dig into the iptables documentation about forwarding a specific port between interfaces. But as a start, something like this: -A FORWARD -i eth1 -o eth2 -j ACCEPT -A FORWARD -i ...


0

iptables has a statistic module, which could be used. It can operate in two modes which are either randomized or deterministic. Here is how your rules could be written with that module. Deterministic version: -A POSTROUTING -s 10.8.0.0/24 -m statistic --mode nth --every 5 --packet 0 -j SNAT --to-source 192.0.2.1 -A POSTROUTING -s 10.8.0.0/24 -m statistic ...


0

To be clear, this is not load-balancing. Load balancing would balance the load over multiple hosts. You're only spreading the source address across multiple IP's on the same host. It's not going to give you any performance benefits, but make your set up more complicated. But, assuming you want to go ahead. According to iptables-extensions man page. ...


0

While not relevant to serverfault, the short version is yes. To pass port 88 back to your home server, you will need three rules at least: iptables -t nat -A PREROUTING -p tcp --dport 88 -j DNAT --to <internal VPN address> iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -o tun+ -p tcp --dport 88 -j ACCEPT ...


0

You can achieve this using iptables u32 module. See: http://www.stearns.org/doc/iptables-u32.current.html and TCP packet filter based on TCP sequence


1

Fixed by adding the -i eth0 to my iptable rules (to specify only outside traffic should be redirected to container X:22. iptables -t nat -A PREROUTING -p tcp --dport 22 -i eth0 -j DNAT --to-destination 10.0.0.4:22


0

netstat + grep is a good and simple option for a few connections but if you have a huge number of connections I would recommend ss as recommended in nixCraft. For instance: ss -s Total: 78 (kernel 79) TCP: 31 (estab 27, closed 0, orphaned 0, synrecv 0, timewait 0/0), ports 16 Transport Total IP IPv6 * 79 - - RAW 0 ...


1

It was a datacenter problem. Diagnosed by running a copy of the server in a different datacenter. I didn't even get to complain, it was fixed by the time I figured it out. Cost me 3 days. Thanks, Digital Ocean!


1

There are some problems with how you wrote your rules. -A POSTROUTING -j MASQUERADE This rule applies too broadly. You only need such rule for connections from the LAN leaving your network. One way to do that would be to specify which outgoing interface it applies to: -A POSTROUTING -o eth0 -j MASQUERADE Additionally your filter table does not make ...


1

In addition to Magellan's answer, do not use -j MASQUERADE, unless you really know what that does and must use it. Instead use -j SNAT --to <source address>. Second, your POSTROUTING rule needs to include -o eth0, otherwise it is MASQUERADEing connections coming back in as well, which your internal boxes probably have no idea how to handle.


2

Before one jumps straight into firewall rules, one should also perform a simple forwarding check. Rather like when one checks the power cord is plugged in before taking apart the hardware. Run: cat /proc/sys/net/ipv4/ip_forward If you get a zero, IPv4 will not forward. You'll need to turn this on. To turn it on immediately and ephemerally to verify ...


1

Before one jumps straight into firewall rules, one should also perform a simple forwarding check. Rather like when one checks the power cord is plugged in before taking apart the hardware. Run: cat /proc/sys/net/ipv4/ip_forward If you get a zero, IPv4 will not forward. You'll need to turn this on. To turn it on immediately and ephemerally to verify ...


2

When you are trying to reach localhost, your source address is 127.0.0.1, as is your destination address. So, packet looks something like this: | SRC | DST | | 127.0.0.1 | 127.0.0.1 | Since packets that are locally generated first traverse OUTPUT chain, you modify the packet with DNAT rule: iptables -t nat -A OUTPUT \ -d ...


0

That looks like it's open to me. I used to make this mistake all the time before I really understood ports and firewalls. Test it to make sure. You can do this using nmap on a remote computer. This is what you would run: nmap (server IP address) -p10205 You should get some output like this: PORT STATE SERVICE 10205/tcp filtered unknown If the ...


10

Take advantage of the state engine: iptables -t filter -A OUTPUT -p tcp --dport 3306 -j ACCEPT iptables -t filter -A INPUT -p tcp --sport 3306 -m state --state ESTABLISHED -j ACCEPT or in later versions of iptables iptables -t filter -A OUTPUT -p tcp --dport 3306 -j ACCEPT iptables -t filter -A INPUT -p tcp --sport 3306 -m conntrack --ctstate ESTABLISHED ...


2

802.1Q tag is inserted into MAC header, and kernel won't decode it if your interface isn't VLAN tagged. So, even if you could mangle outgoing packets, incoming traffic with VLAN tag would stay ignored. What you need to do is create a VLAN tagged interface, just as you did, and add an IP to it within the same rage the switch IP you're trying to access is in. ...


3

iptables and ebtables can't set VLAN tags on packets. That's what VLAN sub-interfaces are for. There's an article on the Ubunut wiki that discusses VLANs that you should probably review. In summary, though, you want to: Make sure the 802.1q module is loaded with a modprobe 80211q. Create the VLAN sub-interface with vconfig add eth0 444. Add an IP ...


1

I found solution from another Answer add RELATED,ESTABLISHED rule iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT reason I faced same problem I changed iptables policy to reject to connection iptables --policy INPUT DROP ^^ this cause the problem and the above code solve it .


3

I used the Traffic Control package and commands such as tc qdisc add dev eth0 root handle 1:0 netem delay 2ms tc qdisc add dev eth0 parent 1:1 handle 10: tbf rate 10mbit buffer 15000 limit 15000 I suggest you do a bit of googling as there are lots of resources out there such as http://www.tldp.org/HOWTO/html_single/Traffic-Control-HOWTO/


1

Your model opens up a raft of routing and configuration issues. Having distinct DNS entries for each service all resolving to the same IP address would be much more workable approach. It is common for DNS names like smtp.example.com, ftp.example.com, ssh.example.com, and others all returning the same IP address. These services all use distinct ports which ...


0

check your iptables table settings with '-vL', most likely you have a rule in a table, that doesn't belong there and so can't be interpreted by iptables-restore. E.g. this happened to me, when I used chef-recipes that configure iptables and I didn't use the API the right way.


2

Got me! :-) I was wrong. What I thought about (the -m string match extension) is not possible, we are in the nat table and only first packet of the "connection" (even if udp) will pass through this table. So we cannot check all packets of same connection and deviate just one. You could check the match extension string (-m string). Note also that the DNAT ...


0

To match string in [acket content You can use "--string [!] string" if it compiled in Your kernel. But there no wildchar and I don't found way to use hex.


0

Using tc is a right way for shaping in linux. The best documentation is LARTC. First of all you need to understand what kind of traffic will you shape - egress or ingress. After that you must to choose an interface to doing that (it is simpler to shape ingress traffic on outgoing interface based on source addresses before NAT and egress traffic on local ...


0

Anyway, you are missing a FORWARD RULE iptables -A FORWARD -i ens160 -o ens192 -p tcp -m tcp -d 192.168.30.37 -m state --state NEW -j ACCEPT You need to insert the above rules, before this: -A FORWARD -j REJECT --reject-with icmp-host-prohibited


3

In RedHat Entrprise Linux 7.0 (the "upstream" of CentOS 7.0) the intended interaction with iptables is through firewalld. Manually modifying the iptables configuration, while possible, is not the intended method if interaction. If you do want to modify the iptables configuration directly you might want to have a look at documentation about iptables. You're ...


0

Here is how I fixed the issue thanks to Xavier Lucas' comment. I changed the following line in my iptables: ## Allow VPN iptables -A UDP -p udp --dport 1194 -j ACCEPT


1

First we make sure that ssh listens only to the desired ip. In the following file: /etc/ssh/sshd_config You'll see a line like: #ListenAddress 0.0.0.0 This is commented out, but is the default, to list on all IP addresses for ssh requests. You can change this so that it is the IP address of the interface you want to accept connections on, and so only ...


1

Add/edit the following line in /etc/ssh/sshd_config: ListenAddress 192.23.6.12


1

Your log definitely shows communication happening on the lo interface. Disable iptables by changing INPUT table default policy to ACCEPT and deactivate any REJECT or DROP rule which might stand in the way Test again and check that it works. If not, the problem comes from somewhere else I would bet $1000 on the fact your filtering rules accepting traffic ...


1

I don't know if iptables has a feature like the one you are asking for, but I can explain why such a feature wouldn't help you. If you receive a flood of unwanted UDP packets, they can either be targeted at a closed or an open port. If they are targeted at a closed port, the kernel will send a proper ICMP error response back. This error response is ...


1

Many thanks to @MichaelHampton. Was finally able to confirm my local ISP was the issue and that the settings were working by launching a second AWS EC2 instance and testing the connection from there.


2

Note the quotation marks. The 'real' destination here is the destination IP after DNAT i.e. the actual IP packets will be sent to. As both IPs somewhow exist in the process, the term real must be balanced that's why you see this notation.


0

What I realized is that a LXC contained works fine out of the box with defaults when it is CREATED, but all subsequent CLONED containers had this connection problem, along with SSH stopped. I ended up creating all my containers and running my install scripts inside them, as opposed to cloning the original container. I was not able to get the connection ...


2

You rules are completely contradictory or redundant. You accept all outgoing traffic on eth0 but then add more specific rules. You use -m tcp while -p tcp already loads the module. You use -m conntrack --ctstate while you also write deprecated -m state --state etc ... This needs a big cleaning session. But the main thing is you inverted sport and dport. -A ...


0

I personally assign a hostname to a ip manually in /etc/hosts and then use it in iptables. This way you Do not offload your Firewall rules to an external entity Have easily maintainable iptables


0

Within the APF config file, usually located at /etc/apf/conf.apf, search for SET_TRIM. Default appears to be 150, which can be changed to unlimited or a specific number. Also, the refresh value can be changed to change the how long between refreshing of the rules. When this is active, it will issue a iptables flush, clearing any rules that you set directly ...


0

I think you forgot to update the policy file: #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST $FW net ACCEPT net all DROP $LOG # The FOLLOWING POLICY MUST BE LAST all all REJECT $LOG


0

Use squid to limit all the domain you want on http protocol, easy to configure and for https protocols use: iptables -A FORWARD -m string --string "facebook.com" --algo bm --from 1 --to 600 -j REJECT


0

The following howto shows example of transparent "intercept" redirection for Squid + arbitrary ICAP server using CentOS 7 with firewalld http://docs.diladele.com/tutorials/transparently_filtering_https_centos/index.html. Actually the extended HTTP/HTTPS commands are just plain iptables rules so it will be helpful in your situation. The problem with DG - it ...


1

It turns out that this was an Amazon issue. I had to disable src/destination checking from the panel to allow it to route packets.


2

It appears you are using CentOS5 or another RHEL5 variant. Netfilter's connection tracking in RHEL5 is broken and will never be fixed. As a result, the typical iptables rule like -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT will not work and ip6tables/connfilter will simply consider them 'INVALID'. In the following example, notice how Netfilter ...


1

I don't think this is an unreasonable configuration, per se. Since you're doing everything in kernel space (versus something like fail2ban, which runs in userland and acts upon the kernel's syslog messages) it should be reasonably efficient. Be aware that you have a major denial-of-service attack potential here, though. An attacker can send SYNs with ...


1

I agree with @Glueon, in that you really should reconsider your iptables rules, seems unnecessarily complex. That said, there is a way to do what you want. I'll just give an example: -A INPUT <some_matches_here> -j ParentChain ... -A ParentChain <some_matches_here> -g ChildChain1 ... The -g switch orders netfilter to perform a GOTO instead of ...


0

I'd be cautious, as IP was designed to route based on destination IP address, and you will be better off if you can make that happen. For instance, if what you really want is all traffic from a particular virtual server to be sent out a particular interface then use bridging instead. That being said, you can use multiple routing tables along with routing ...


2

The conntrack tool won't return a flow because, by the time your ping command has ended the flow has been terminated. Create a persistent TCP connection to something on the Internet and do a conntrack -L and you'll see a flow. You could also send some ping requests to an Internet host that doesn't respond-- you'll see a flow created (waiting for the ICMP ...


2

You need rule which will update 'nat' tables PREROUTING chain like this : iptables -t nat -A PREROUTING -p tcp --dport 1443 -j REDIRECT --to-port 443


0

You can use UFW/iptables to allow ranges. If your servers are created within the same range, you setup specific subnets to be allowed through. example: ufw allow in on eth0 from 192.168.4.0/24 proto tcp to any port 1234



Top 50 recent answers are included