netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Jellinghaus <aj@dungeon.inka.de>
To: bert hubert <ahu@ds9a.nl>
Cc: "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: ipsec without interface
Date: 01 Jul 2003 15:33:24 +0200	[thread overview]
Message-ID: <1057066404.4054.9.camel@simulacron> (raw)
In-Reply-To: <20030701125808.GA19408@outpost.ds9a.nl>

On Tue, 2003-07-01 at 14:58, bert hubert wrote:
> On Thu, May 29, 2003 at 09:16:27PM +0200, Andreas Jellinghaus wrote:
> > sure, the simple configurations work fine with kernel 2.5.* ipsec.
> > But I miss the interface and things I did with it. How are these
> > setups supposed to work without an interface?
> > 
> > a) in iptables allow everything coming from ipsec0,
> >    allow only ssh and ipsec on eth0.
> 
> iptables can filter on ESP/AH presence.

the packet is seen once as ESP/AH and once as normal (e.g. TCP)
packet. where is the connection? how can you see that a packet
came in first as ESP/AH packet and was then decrypted, and did
not came in without ipsec?

with freeswan that was easy: drop everything, unless it is from
interface ipsec0. And you always new, packets from ipsec0 came
in with valid ipsec encryption, that was easy to make sure.

and now? use fwmark? even if that works, its not as easy.

> 
> > b) source address selection. put the default route on ipsec0,
> 
> Do you need a separate source address?

I'm a "road warrior", so the local wireless lan gives me a
192.168.* address. For my ipsec tunnel to $company gateway
I need get an official address assigned, so I can use that
to access the company network, or even the internet (if I don't
trust the local network, and don't want unencrypted connections
to the internet). I think such a setup will be quite common.

local lan			some nat	company gateway	
192.168.0.* <-> 192.168.0.1			<->  1.2.3.4
ipsec tunnel
1.2.3.5 		<->				1.2.3.4 

connetion will use 1.2.3.5 <-> 1.2.3.80 (e.g. company file server,
allowing access from 1.2.3.*).

ip route del default
ip route add default gw 192.168.0.1 src 1.2.3.5

yes, that works. but it's not nice.
also company getway needs a 
	ip route add 1.2.3.5 dev eth0/1/2/whatever
even though no packet to "1.2.3.5" will ever be on any
wire - the packet will be alway encrypted and have a final
ip address somewhere in the internet or wireless network.

hmm. I haven't tried to use an explicit ipip tunnel.
did anyone use ESP in transport mode to encrypt packets
of an IPIP tunnel? that might help me.

Regards, Andreas

  reply	other threads:[~2003-07-01 13:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-29 19:16 ipsec without interface Andreas Jellinghaus
2003-07-01 12:58 ` bert hubert
2003-07-01 13:33   ` Andreas Jellinghaus [this message]
2003-07-01 14:00     ` James Morris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1057066404.4054.9.camel@simulacron \
    --to=aj@dungeon.inka.de \
    --cc=ahu@ds9a.nl \
    --cc=netdev@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).