[TriLUG] having trouble writing firewall rules for openvpn

[Thomas Gardner]

Joe,

Disclaimer:  I'm no firewall expert.  Although, I would never do it
intentionally, what I'm about to tell you could blow your firewall
wide open and send out advertisements about the pitiful condition of
your system's security to all known crackers on the 'net.  If you're
smart, you won't take my word for anything and use what I tell you as
only one source of guidance.  Nonetheless I'll give this a shot.

On 5/7/12, Joseph Mack NA3T <jmack at wm7d.net> wrote:
> client: tun0 10.88.0.6 -> eth0 50.55.x.x -
>
> server: eth2 50.55.y.y -> tun0 10.8.0.1
> server network 192.168.2.0/24 is visible to the client.
>
> I'm not quite sure how the packets go. Traceroute from the
> client gets to the server 192.168.2.0/24 in one hop. I
> assume the tcp IPIP packet (10.8.0.6->10.8.0.1:T22) is
> encapsulated in a regular IP packet
> (50.55.x.x->50.55.y.y:U1194). I assume a ssh connect request
> from the client arrives as an IPIP packet at the
> server:U1194. So I did this

OK, first, are you trying to write the rule for the server or the
client?  I'll assume the client for now.

> #default INPUT policy
> iptables -P INPUT DROP  #I have to comment this out to get an openvpn
> connection

You DEFINITELY don't want to comment this out.  You might want the
other two in the triplet set, too:

    iptables -P OUTPUT DROP
    iptables -P FORWARD DROP

or at least the OUTPUT one.  If your machine is ever compromised,
you want to at least try to limit the ability of a 'bot to contact
the mother-ship (or whatever else it wants to contact).  Of course,
if it uses some port that you open up somewhere else (like http,
for instance), this won't help, but it's worth doing just in case.
I do both of these for that reason (I use the laptop that this runs
on as a router sometimes, hence the need for a FORWARD policy).

Of course, if you do this on the OUTPUT chain, you'll have to
specify a rule to open up each port you want opened up to the outside
individually.  There really aren't that many of them.

Also, I use rules like:

    iptables -A INPUT -p all -i $EXTERNAL_INTERFACE \
      -m state --state RELATED,ESTABLISHED -j ACCEPT

    iptables -A OUTPUT -p all -o $EXTERNAL_INTERFACE \
      -m state --state ESTABLISHED,RELATED -j ACCEPT

    iptables -A FORWARD -p all -i $EXTERNAL_INTERFACE \
      -m state --state RELATED,ESTABLISHED -j ACCEPT

as the very first set of rules in each of those chains.  Remember
that these rules are processed IN ORDER for each packet received.
So, the sooner you establish whether you're going to accept, reject or
drop a packet, the better.  What I was doing before is, for each port
I opened up for outgoing traffic, I would add a rule for the response
coming back.  When I switched over to using these rules at the top,
the speed of my Internet connection increased dramatically.

The one on the OUTPUT chain was overkill for me, and would almost
definitely be for most people.  However, if I do ever run a server
on my machine for something, this is one point of confusion that
will be eliminated.  It seems like it's probably harmless enough.

> #I assume the packet arrives on server:eth2:U1194, here I'm just logging
>
> iptables -A INPUT -p udp -j LOG --log-prefix "UDP"
> iptables -A INPUT -p tcp -j LOG --log-prefix "TCP"
> iptables -A INPUT -i eth2 -j LOG --log-prefix "eth2"
> iptables -A INPUT -i tun0 -j LOG --log-prefix "tun0"
>
> next I try to accept the packet
>
> iptables -A INPUT -p udp --dport 1194 -j ACCEPT

OK, here's where the confusion of client/server comes in.  This might
be right for the server, but not the client.  I don't know what your
setup is like where you're trying to VPN into, but on the system I was
on, it was just using https ports....

Now, if that 1194 port is correct, and if you take my advice and lock
down outgoing packets as well as incoming, what you probably really
want is something like:

    iptables -A OUTPUT -dport 1194 -o $EXTERNAL_INTERFACE \
      -d $VPN_SERVER -j ACCEPT

if you used the generic ``let all inbound RELATED/ESTABLISHED traffic
pass'' rule from above, then this might do it for you.  Otherwise, you
might need the mating rule for the answer back from the server like:

    iptables -A INPUT -i $EXTERNAL_INTERFACE -s $VPN_SERVER \
      -m state --state RELATED,ESTABLISHED -j ACCEPT

(ur sumsuch).  I suspect this is where you were having a problem.
I didn't see an input rule allowing the server to respond.  Again,
the INPUT rule above wouldn't work for that.  Also, at the end of
my firewall script, I include a little ditty like:

    # Log everything that gets this far:

    iptables -A INPUT   -i $EXTERNAL_INTERFACE -p all -j LOG
    iptables -A INPUT   -i $EXTERNAL_INTERFACE -p all -j DROP
    iptables -A FORWARD -i $EXTERNAL_INTERFACE -p all -j LOG
    iptables -A FORWARD -i $EXTERNAL_INTERFACE -p all -j DROP

    # What I really wanted was a REJECT policy for outbound stuff,
    # but since REJECT is not a built-in target, it can't be a policy.
    # So, we make the policy ``DROP'' then unconditionally REJECT
    # all output packets as my last rule.

    iptables -A OUTPUT  -o $EXTERNAL_INTERFACE -j LOG
    iptables -A OUTPUT  -o $EXTERNAL_INTERFACE -j REJECT
    iptables -A FORWARD -o $EXTERNAL_INTERFACE -j LOG
    iptables -A FORWARD -o $EXTERNAL_INTERFACE -j REJECT

So, I do get a log of everything my firewall doesn't let pass.
At first, I did it and kept an eye on it thinking it would be a lot
of extra logging.  It wasn't as much as I thought it was going to be,
so I kept it.

> I don't see any entries in /var/log/messages. The only way I
> get a connection if if the default INPUT policy DROP rule is
> commented out.

You really don't want to do that, but I suspect you already know that.
I'm having a hard time figuring out why you're not getting anything
in your logs.  I'm thinking you've got more rules in here that you're
not mentioning, and those rules are short-circuiting the packet to its
ultimate destination before it gets to the LOG rule.

>                I assume the rule accepting udp packets to
> port 1194 is not being triggered. An INPUT rule ACCEPTing
> port 22 doesn't accept connections either.
>
> I'm no iptables expert. Can anyone see what I'm doing that's
> wrong? To get an ssh connection client->server I have to
> remove the default DROP policy.
>
> Thanks Joe

Well, hopefully that'll get you started.  It's far from a full
treatment on the subject, but I'm not even sure if you're asking
about the firewall for the server or the client, yet....

L8r,
tg.