David Miller writes:
> Essentially, if you use ports as part of your selector,
> then it is impossible to handle anything other than the
> first fragment of a fragmented frame because the subsequent
> fragments will not have the ports which you need in order
> to match.
If you have port/proto
From: Alexey Kuznetsov <[EMAIL PROTECTED]>
Date: Tue, 5 Sep 2006 13:05:30 +0400
> Look into old rfc2401, search for word "fragment".
> Then search for the same word in new rfc4301. All those 100K of new text
> deal with various design bugs in IPsec, mostly with pathologies encountered
> in the cas
* H. Peter Anvin <[EMAIL PROTECTED]> 2006-09-07 15:28
> Thomas Graf wrote:
> >What about adding blackhole device to be used for such routes.
> >I believe it would be good architecture to always use devices
> >to state directions packets are being received from and sent to.
>
> The dummy device can
Thomas Graf wrote:
What about adding blackhole device to be used for such routes.
I believe it would be good architecture to always use devices
to state directions packets are being received from and sent to.
The dummy device can be used for that.
-hpa
-
To unsubscribe from this list:
Alexey Kuznetsov writes:
> Probably, you are not aware that "standard IPsec tunnel device",
> if it is created:
>
> 1. Probably, will not accept fragmented frames, because IPsec cannot
>handle them
IPsec can handle them, though not particularly smoothly if the IPsec
tunnel is only suppos
Hello!
> >1. Probably, will not accept fragmented frames, because IPsec cannot
> > handle them
...
> I'm clearly failing to understand where, exactly, the problems lie. I
> would appreciate any pointers and/or clue transfusion...
I said "probably".
Look into old rfc2401, search for word "fra
Stephen J. Bevan wrote:
> Really... if saying our configuration is so screwed up that we have to
> run a different over-wire protocol isn't an admission of failure I don't
If you use ipip the over-wire protocol is identical, see RFC 3884
section 3.1 or you can test it right now using manu
Alexey Kuznetsov wrote:
sarcasm mode is not accepted. Linux does exactly "standard tunnel-mode IPsec".
It does not give you device to make you totally happy.
The sarcasm was a commentary to the "just switch protocols then" comment.
Probably, you are not aware that "standard IPsec tunnel dev
Hello!
>
>
> What I great idea. Now I just have to get every host I want to
> interoperate with to support a nonstandard configuration. The scary
> part is that if I motivate it with "Linux is too stupid to handle
> standard tunnel-mode IPsec" I might actually get away with it.
sarcasm mod
>
>
> What I great idea. Now I just have to get every host I want to
> interoperate with to support a nonstandard configuration. The scary
> part is that if I motivate it with "Linux is too stupid to handle
> standard tunnel-mode IPsec" I might actually get away with it.
>
>
Linux
Stephen J. Bevan wrote:
H. Peter Anvin writes:
> Fair enough. However, that does beg a question: is there any sane way
> to create the pseudo-device model on top of the current model, as a
> convenience layer? That way you could get the best of both.
I assume you were using tunnel-mode I
H. Peter Anvin writes:
> Fair enough. However, that does beg a question: is there any sane way
> to create the pseudo-device model on top of the current model, as a
> convenience layer? That way you could get the best of both.
I assume you were using tunnel-mode IPsec and depending on exact
Alexey Kuznetsov wrote:
Hello!
I'm thinking that David definitely has a point about having a usability
problem, though. All other kind of tunnels have endpoint devices
associated with them, and that would make all these kinds of problems go
away,
Yes, when you deal with sane practical set
Hello!
> I'm thinking that David definitely has a point about having a usability
> problem, though. All other kind of tunnels have endpoint devices
> associated with them, and that would make all these kinds of problems go
> away,
Yes, when you deal with sane practical setups, this approach
* David Miller <[EMAIL PROTECTED]> 2006-08-23 15:14
> From: Thomas Graf <[EMAIL PROTECTED]>
> Date: Wed, 23 Aug 2006 21:14:25 +0200
>
> > * H. Peter Anvin <[EMAIL PROTECTED]> 2006-08-22 17:31
> > > Specifically, Linux will not ProxyARP for an address unless it has a
> > > route for it, *and* that
Andy Gay wrote:
Just tried it, and it works as advertised.
... except that OpenSwan will rip out the route and install a route
pointing to eth0, thus breaking the thing again.
Use a custom updown script with Openswan to fix that.
*Nod.*
I'm thinking that David definitely has a point abo
On Wed, 2006-08-23 at 18:14 -0700, H. Peter Anvin wrote:
> H. Peter Anvin wrote:
> > Alexey Kuznetsov wrote:
> >>
> >> The question is where is this host really?
> >>
> >> If it is far far away and connected only via IPsec tunnel with
> >> destionation
> >> of tunnel different of host address
> >>
H. Peter Anvin wrote:
Alexey Kuznetsov wrote:
The question is where is this host really?
If it is far far away and connected only via IPsec tunnel with
destionation
of tunnel different of host address
ip ro add THEHOST dev dummy0
should be enough. It asserts that THEHOST is not on eth0.
IP
Alexey Kuznetsov wrote:
The question is where is this host really?
If it is far far away and connected only via IPsec tunnel with destionation
of tunnel different of host address
ip ro add THEHOST dev dummy0
should be enough. It asserts that THEHOST is not on eth0.
IPsec policy will figure ou
Hello!
> What he's trying to accomplish doesn't sound all that weird,
Absolutely sane.
> does anyone have any other ideas?
The question is where is this host really?
If it is far far away and connected only via IPsec tunnel with destionation
of tunnel different of host address
ip ro add THEH
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Wed, 23 Aug 2006 21:14:25 +0200
> * H. Peter Anvin <[EMAIL PROTECTED]> 2006-08-22 17:31
> > Specifically, Linux will not ProxyARP for an address unless it has a
> > route for it, *and* that route either has a DNAT marking or points to a
> > different i
* H. Peter Anvin <[EMAIL PROTECTED]> 2006-08-22 17:31
> Specifically, Linux will not ProxyARP for an address unless it has a
> route for it, *and* that route either has a DNAT marking or points to a
> different interface than the input interface:
I can think of a very ugly way: Use netfilter to
Hello all,
I am having a puzzlement combining ProxyARP and IPsec. Specificially, I
want to take a single address from a local LAN and extend it via IPsec
to another site.
Unfortunately IPsec tunnels, unlike all other tunnels, don't have
pseudo-devices associated with them. I under
23 matches
Mail list logo
