Tag Info

Hot answers tagged

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 ...


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 ...


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. ...


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 ...


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

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


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.


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 ...


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

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 .



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