state of ipsec
Bruce M Simpson
> I unsuccessfully tried to get ipsec and racoon working on 5.2-RELEASE-p2.
> Despite a setup that is proven to be correct, i don't see any outgoing
> packets whatsoever during phase1, which then results in a timeout.
> I know there have been issues with ipsec but i lost track of what got fixed
> for wich tag.
Have you tried using setkey -D to inspect the 'last used' timestamp present
on Security Associations?
Are you able to tcpdump ESP/AH traffic on both peers? Can you verify that
the path between both peers doesn't filter this traffic?
BMS
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
Tobias Roth
> On Sat, Feb 14, 2004 at 06:41:44PM +0100, Tobias Roth wrote:
> > I unsuccessfully tried to get ipsec and racoon working on 5.2-RELEASE-p2.
> > Despite a setup that is proven to be correct, i don't see any outgoing
> > packets whatsoever during phase1, which then results in a timeout.
> > I know there have been issues with ipsec but i lost track of what got fixed
> > for wich tag.
>
> Have you tried using setkey -D to inspect the 'last used' timestamp present
> on Security Associations?
yes, setkey -D never outputs anything, no SAs get created at all.
> Are you able to tcpdump ESP/AH traffic on both peers? Can you verify that
> the path between both peers doesn't filter this traffic?
that's what i was trying to say. tcpdump does not show any outgoing packets
when doing phase 1, no packets leave the interface. it looks like this:
security policies are correctly set, racoon is configured correctly and
running, i start pinging, and no packets leave the interface. i drop the
security policies (/etc/rc.d/ipsec forcestop), and the pings immediately
get through. in racoon output this looks like phase 1 gets initiated but
since no reply packets come back, it timeouts. i have no packet filter
running.
Guido van Rooij
> On Sun, Feb 15, 2004 at 12:54:26AM +0100, Tobias Roth wrote:
> > yes, setkey -D never outputs anything, no SAs get created at all.
>
> or there has been a problem when racoon is issuing PF_KEY socket writes.
>
> Can you recompile with IPSEC_DEBUG enabled and try to replicate the problem?
IIRC IPSEC currentky has the porblem that if you happen to use require
in your policies, even the ISAKMP packets do not gte out.
I switched to FAST_IPSEC, which doesnt have this problem.
You can of course also use "use" in stead of "require".
-Guido
Bjoern A. Zeeb
> > Are you able to tcpdump ESP/AH traffic on both peers? Can you verify that
> > the path between both peers doesn't filter this traffic?
>
> that's what i was trying to say. tcpdump does not show any outgoing packets
> when doing phase 1, no packets leave the interface. it looks like this:
> security policies are correctly set, racoon is configured correctly and
> running, i start pinging, and no packets leave the interface. i drop the
> security policies (/etc/rc.d/ipsec forcestop), and the pings immediately
> get through. in racoon output this looks like phase 1 gets initiated but
> since no reply packets come back, it timeouts. i have no packet filter
> running.
ok before any more people tell us that it does not work can you please
give me the following details:
a) what branch/date or release are you seeing these problems ? 5.2R is broken
b) if you are using 5.2R can you please try 5.2.1-RC2/HEAD so that we
definitively know that it is (not) another problem from those
we had seen and almost fixed around 5.2R and report if it works there
with the same setup ?
c) if it still does not work please let me know.
Additionally: if anybody is using 5.2.1-RC2/HEAD and had seen the
problem before but can no logner reproduce it after the update please
let us know too.
--
Greetings
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
56 69 73 69 74 http://www.zabbadoz.net/
Craig Boston
> IIRC IPSEC currentky has the porblem that if you happen to use require
> in your policies, even the ISAKMP packets do not gte out.
>
> I switched to FAST_IPSEC, which doesnt have this problem.
> You can of course also use "use" in stead of "require".
One workaround that solved it for me is to modify your IPSEC policy and insert
something like this at the top:
spdadd 0.0.0.0/0[500] 0.0.0.0/0[500] any -P out ipsec
esp/transport//default;
spdadd 0.0.0.0/0[500] 0.0.0.0/0[500] any -P in ipsec
esp/transport//default;
If that's at the top before anything else, it should override the policy for
ISAKMP packets and get things working again without having to fall back to
'use'. A similar entry should be possible for IPv6 as well if you need that.
On a somewhat related topic, has anyone encountered panics when the interface
that racoon is watching is destroyed (say, gif0)? This is on 5.2-RELEASE.
I'll try to get a dump if it happens again...
Craig
Bjoern A. Zeeb
> On a somewhat related topic, has anyone encountered panics when the interface
> that racoon is watching is destroyed (say, gif0)? This is on 5.2-RELEASE.
> I'll try to get a dump if it happens again...
I even got a dump by killing racoon at that time ;-(
You might also be able to get a crash by only setting the int to down
and/or chaning IPs. The panic may not be seen at once but somewhen
afterwards.
This is fixed.
--
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
56 69 73 69 74 http://www.zabbadoz.net/
Tobias Roth
> On Sun, Feb 15, 2004 at 01:37:00AM +0000, Bruce M Simpson wrote:
> > On Sun, Feb 15, 2004 at 12:54:26AM +0100, Tobias Roth wrote:
> > > yes, setkey -D never outputs anything, no SAs get created at all.
> >
> > This would tend to suggest either IPSEC support is missing from the kernel,
> > or there has been a problem when racoon is issuing PF_KEY socket writes.
> >
> > Can you recompile with IPSEC_DEBUG enabled and try to replicate the problem?
>
> IIRC IPSEC currentky has the porblem that if you happen to use require
> in your policies, even the ISAKMP packets do not gte out.
>
> I switched to FAST_IPSEC, which doesnt have this problem.
> You can of course also use "use" in stead of "require".
i did some more tests and have now verified that IPSEC plus "require"
does not work, no packets get sent over the wire. the same setup works
like a charm when i change "require" to "use". this is with 5.2.1-RC2
on both machines.