Re: [tlug] Iptables trouble

[Furkan Mustafa <furkan@example.com>]

Hello,

Not an exact solution to your problem.

I usually add a LOG command to default DROP tables, to debug (to see 
what
is going to be dropped).

Insert these rules after all of your accept rules.

-A INPUT -j LOG
-A FORWARD -j LOG

With these two, I believe you'll see the problem immediately. (if 
iptables
rules is the source of your problem)

Use `dmesg -w` to see the logged entries.

And you would probably want to disable logging for normal use.

---

About your configuration, I noticed that you only allowed some tcp 
connections,
which leaves out icmp and udp connections. It should be okay if that's 
your
intention. But pings probably won't work unless you allow them.

Also depending on your system, you might not be the only source of 
iptables rules.
You can verify using; `iptables -L -v -n --line-numbers` etc.

That will also show you which rule is dropping packets (with dropped 
packet count).

I hope it helps.

Furkan Mustafa

On 2018-01-11 12:31, David J Iannucci wrote:
> Hi again TLUGgers... I have another request for help. Note that my last
> plea, about tethering my iPhone, is still under investigation... I've
> already spent quite a bit of time on the phone with Apple support
> without solving it, but will report here when it is solved :=)
>
> This time it's about iptables... maybe something a bit more
> straightforward for this group. I'm just learning to write these rules,
> and have been frustrated because the following is not doing what I
> expect. This is on a server in my university's data center. The VM has 
> a
> public-facing interface on 133.171[*], and also a private interface to
> the IT dept's maintenance subnet, which is numbered in the 172.16
> private range. I've already tried to ask them for help, but apparently
> they do not provide that level of support :=\
>
> The problem is that the IT dept cannot communicate with this box over
> the private subnet when these rules are in place, and I don't know why.
> I've annotated them with my idea of what the rules mean. My
> understanding is that after the first three policy lines, each rule is
> tried in order until one matches, and then the given action is taken 
> and
> evaluation stops.
>
> If someone could point out where I'm mistaken, I'd be very grateful.
>
> Dave
>
>
> ## Default policy: allow nothing coming in, everything going out
> :INPUT DROP [150:10296]
> :FORWARD DROP [0:0]
> :OUTPUT ACCEPT [42178:3090645]
>
> ## Accept anything over the loopback i/f
> -A INPUT -i lo -j ACCEPT
>
> ## Accept any packets that are part of an already ESTABLISHED
> ## connection, or RELATED(?) to something? Not sure about
> ## RELATED, but I don't think it's hurting me :=)
> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
>
> ## Accept all TCP connection packets whose origin IP is in the
> ## given range. This is SUPPOSED to allow the IT dept to talk to me.
> -A INPUT -p tcp -m tcp --source 172.16.0.0/12 -j ACCEPT
>
> ## Accept all TCP connection packets to ports 80 and 443. I suppose
> ## this is only needed on initial establishment, as the ESTABLISHED
> ## rule should then take over, no?
> -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
>
> ## Accept all TCP connection packets to port 22 only if the origin
> ## is in the given IP range.
> -A INPUT -s 133.171.0.0/16 -p tcp -m tcp --dport 22 -j ACCEPT
> -A INPUT -s 112.160.0.0/16 -p tcp -m tcp --dport 22 -j ACCEPT
>
> ## More like the ones above for SSH, but for different ports
> -A INPUT -s 133.171.0.0/16 -p tcp -m tcp --dport 3000 -j ACCEPT
> -A INPUT -s 133.171.0.0/16 -p tcp -m tcp --dport 3030 -j ACCEPT
> -A INPUT -s 133.171.0.0/16 -p tcp -m tcp --dport 4040 -j ACCEPT
> -A INPUT -s 133.171.0.0/16 -p tcp -m tcp --dport 4200 -j ACCEPT
> COMMIT
>
> [*] Note that I've changed the IP addresses in an attempt at obscurity
>       security, though against what I'm not sure.