[Techtalk] iptables rules for openvpn review, please

[John Clarke]

On Tue, Feb 27, 2007 at 05:22:46 -0800, Carla Schroder wrote:

Hi Carla,

> On Tuesday 27 February 2007 16:14, John Clarke wrote:
> >  Maybe I'm paranoid, but I'd restrict what the
> > remote end of the vpn is allowed to do.
> 
> Like what? I'm treating it as an extension of the local network, so what would 
> you restrict?

It depends upon how much you trust the remote end.  I give remote
clients no more access than I give LAN clients.  So any filtering you
have on the LAN interface you should also have on the VPN tunnel
interface.

I trust the remote end less than I trust the LAN, and I don't trust the
LAN much :-)

> I'm trying to work up a basic set of rules to get VPN traffic through NAT. 
> Nothing fancy, just make the dommed thing work. :) So any examples are 
> appreciated.

If you're trying to get VPN traffic through to a server which is behind
a NAT firewall, you need something like this on the firewall (assuming
that the VPN server is on the LAN interface):

    lan=eth0
    wan=eth1
    vpn_server_wan_address=xxx.xxx.xxx.xxx
    vpn_server_lan_address=192.168.1.16

    iptables -t nat -A PREROUTING -p udp -d $vpn_server_wan_address \
        --dport 1194 -i $wan -m state --state NEW -j DNAT \
        --to-destination $vpn_server_lan_address
        
    iptables -A FORWARD -p udp -d $vpn_server_lan_address --dport 1194 \
        -i $wan -o $lan -m state --state NEW -j ACCEPT

The first rule changes the destination of new VPN connections to be the
LAN address of the openvpn server.  The second rule forwards the traffic
though the firewall, and the destination is now the LAN address of the
openvpn server because it's already been changed due to the PREROUTING
rule.  With these two rules you should be able to establish a VPN
connection (assuming there's no firewalling on the VPN server itself).

If the VPN server is the firewall, just use an INPUT rule with no NAT
instead:

    iptables -A INPUT -p udp -d $wan_address --dport 1194 -i $wan \
        -m state --state NEW -j ACCEPT

Then to forward everything between the VPN client and the LAN, in both
directions, you need something like this on the VPN server itself:

    lan=eth0
    vpn=tun0
    lan_subnet=192.168.1.0/24
    vpn_subnet=192.168.42.0/24
    iptables -A FORWARD -s $vpn_subnet -d $lan_subnet -i $vpn -o $lan \
        -m state --state NEW -j ACCEPT
    iptables -A FORWARD -s $lan_subnet -d $vpn_subnet -i $lan -o $vpn \
        -m state --state NEW -j ACCEPT

If you also want to accept input from the VPN client, add:

    vpn_address=192.168.42.1
    iptables -A INPUT -s $vpn_subnet -d $vpn_address -i $vpn \
        -m state --state NEW -j ACCEPT

Note that I'm assuming that you have state ESTABLISHED,RELATED rules
already in place on each of the INPUT, FORWARD and OUTPUT chains (you
don't need them in the NAT table) on both the firewall and the VPN server.

The other thing you need to consider is that traffic from the VPN client
will appear on the LAN with the client's VPN address.  You can NAT the
packets on their way through the VPN server, or you can configure your
LAN's default gateway to route VPN traffic back to the VPN server, and
add rules to forward the packets, e.g.:

    route add -net $vpn_subnet gw $vpn_server_lan_address
    ipables -A FORWARD -s $lan_subnet d $vpn_subnet -i $lan -o $lan -j ACCEPT

You only need to forward in one direction (lan -> vpn) because packets
from the vpn  go directly.  For the same reason, state matching isn't
needed, and in fact will break things (because the state machine only
sees half of the traffic), so make sure you don't use it here.


Does that all make sense?


Cheers,

John
-- 
>>See? I'm deep, I am.
It's all relative, Jim; if you turn to the side, you're thick instead.
            -- David P. Murphy