On Fri, 23 Jan 2004 16:11:07 +0000, Nico Schottelius wrote:
> Hello!
>
> While experiement with ipsec I found the following problems:
>
> Encapsulated ipsec data (esp) passes through iptables and becomes
> decrypted. So far so fine.
>
> Now what happens with thoso unencrypted packages? It looks like
> they travel through iptables again!
That behaviour is absolutely right.
Otherwise you could not filter what was inside that ipsec tunnel
The problem is: netfilter does not allow to filter
what gets encrypted - only the already encrypted packet
is seen in OUTGOING.
Dave M considers this behaviour ok, and already stated: it will not change.
So we have to live with it.
What you can do is this:
create an IPIP interface, e.g. with:
ip tunnel add ip4sec0 mode ipip \
remote 192.168.1.10 local 192.168.1.1 # dev wlan0
and then you can protect that interface with:
spdadd 192.168.1.10 192.168.1.1 4 -P in ipsec
esp/transport//require;
spdadd 192.168.1.1 192.168.1.10 4 -P out ipsec
esp/transport//require;
as normal you can assign that interface an ip address and
because you route to that interface it will be used for
new connections.
iptables setup using that ipip interface is also quite
easy: on wlan0 don't allow any forwading, and only
allow ping,ssh,ike and esp in incoming.
you can then allow packets from ip4sec0 interface to
use additional services and forwarding, because you know
that they come via an authenticated ipsec connection.
the catch? its unstable as hell. I tried such a setup,
and get lots of call traces, sometime shard lockups,
racoon often blocks and seems to do nothing. also creating
an ipip interface triggers racoon to try to connect,
which is not necessary AFAIK.
I also tried a second interface for ip6 traffic, independent
from the first, using ip6ip6. There were several bugs, but
all but one problem got fixed, thanks to Ville. Some patches
are already accepted by dave m. I hope the other will find their
way into the official kernel, too.
So, what to do in the meantime, till ipsec becomes usable?
I whish I could use wpa and to hell with ipsec, but there is
only a supplecant (client part of wpa) implemented for hostap,
so far there is no server implementation (athenticator?).
So what I'm currently doing and what you can do, too is this:
-- warning, this is sick, don't look if you have a weak stomach --
add one more ip address to use like a tunnel endpoint.
assign that ip address manualy to wlan0 and use it for
source routing. e.g.:
up ip addr add 192.168.3.1 dev wlan0
up ip route del default dev wlan0
up ip route add default via 192.168.1.1 src 192.168.3.1 dev wlan0
on client/laptop and on gateway/router:
up ip route add 192.168.3.1 dev wlan0
down ip route del 192.168.3.1 dev wlan0
then use that ip in the ipsec configuration:
spdadd 192.168.3.1 0.0.0.0/0 any -P out ipsec
esp/tunnel/192.168.1.10-192.168.1.1/require;
spdadd 0.0.0.0/0 192.168.3.1 any -P in ipsec
esp/tunnel/192.168.1.1-192.168.1.10/require;
the gateway has these rules reverse, but also in addition:
spdadd 0.0.0.0/0 192.168.0.0/16 any -P out discard;
spdadd 192.168.0.0/16 0.0.0.0/0 any -P in discard;
and then filter in iptables based on ip address:
iptables -A INPUT -p udp --sport 500 --dport 500 -j ACCEPT # ike
iptables -A INPUT -p 50 -j ACCEPT # esp (who needs ah if you have esp?)
iptables -A INPUT -s 192.168.3.1/32 -j ACCEPT # "virtual tunnel endpoint"
# drop the rest from wlan0...
what I hate about this is:
a) setting source addr is ugly.
b) the gateway needs to know where the source addr is, because it does
no routing lookup after encapsulation. if you switch your laptop to
lan and still want to use vpn, you need to reconfigure the routing
table on the vpn gateway. urghs.
c) labil setup. I prefer stable setups, where the default is safe (i.e.
nothing works), and then I can selectivly open up for some cases.
in this setup however iptables is completely insecure, if it where not
for the setkey database, that would shut down everything.
d) dhcp? anyone using dhcp? you surely don't want dhcp via a tunnel,
because to configure the tunnel you first need ... aha!
I had to add rules lile this to the gateway, so dhcp is allowed and
does not need a tunnel:
# allow dhcp
spdadd 0.0.0.0/0[68] 192.168.1.1[67] udp -P in none;
spdadd 192.168.1.1[67] 0.0.0.0/0[68] udp -P out none;
I also added to iptables:
iptables -A INPUT -i wlan0 -p udp -d 255.255.255.255 \
--sport 68 --dport 67 -j ACCEPT
This setup still gives me headaches, but it is working more
or less, and I only sometimes see call traces as opposed to
all the time.
Regards, Andreas
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
