Re: IKEv2/IPSEC "Road Warrior" VPN Tunneling?
On Wed, Apr 17, 2013 at 11:57:19AM +0200, Willy Offermans wrote: > Hello Karl and FreeBSD friends, Hi all. > I recall having read about racoon and roadwarrior. Have a look to > /usr/local/share/examples/ipsec-tools/, if you have installed it. I'm also > planning to install this on my server. However I have only little time at > the moment. I'm also looking for examples of configuration files to work > with. First, ipsec-tools is for IKEv1 only, as the subject of the original mail talks about IKEv2. For IKEv1 (with ipsec-tools), the simplest way to do this would be to create a remote "anonymous" and a sainfo "anonymous" section, with "generate_policy" set to on: racoon will negociate phase 1 / phase 2, then will generate SPD entries from peer's proposal. Of course, this means that you'll have to trust what your peers will negociate as traffic endpoints ! If you have some more time to spend on configuration (recommanded !), you can specify traffic endpoints for the sainfo section: valid endpoints (which match the sainfo) negociated by peer will work as described upper, and other traffic endpoints will not negociate, as racoon won't find any related sainfo. Yvan. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ipsec kernel panic
User-Agent: All mail clients suck. This one just sucks less. On Mon, Jun 25, 2012 at 07:34:25AM +0300, mbsd wrote: > Hi stable users. Hi. > Like this good guy: > http://www.freebsd.org/cgi/query-pr.cgi?pr=159629&cat= > I'm bad guy also have kernel panic. >1;2802;0c Maybe it's doesn't matter good or bad gay you are. > > It happened first time around Freebsd 9 ~ beta 2 or three. I don't > remember exactly. > > All what I have is > > ?? ~ ??? cat /etc/ipsec.conf > add 192.168.0.2 192.168.0.1 esp 10022 -E blowfish-cbc "dododo"; > add 192.168.0.1 192.168.0.2 esp 10020 -E blowfish-cbc dododo; > > add 192.168.0.2 192.168.0.1 ah 10007 -A hmac-md5 "dododo"; > add 192.168.0.1 192.168.0.2 ah 10006 -A hmac-md5 "dododo"; > > # for internet > spdadd 0.0.0.0/0 192.168.0.2 any -P in ipsec > esp/tunnel/192.168.0.1-192.168.0.2/require ah/transport//require; > spdadd 192.168.0.2 0.0.0.0/0 any -P out ipsec > esp/tunnel/192.168.0.2-192.168.0.1/require ah/transport//require; > > After service ipsec start I always have kernel panic on stable. This will *not* solve the crash, but do you really need such IPsec configuration with both ESP/tunnel and AH/transport ? Most people who use such configuration just wants in fact ESP/Tunnel with payload authentication, which will be done by that: add 192.168.0.2 192.168.0.1 esp 10022 -E blowfish-cbc "dododo" -A hmac-md5 "dododo"; add 192.168.0.1 192.168.0.2 esp 10020 -E blowfish-cbc dododo -A hmac-md5 "dododo"; (if you do really use static SAs, please also consider moving to an IKE daemon...) spdadd 0.0.0.0/0 192.168.0.2 any -P in ipsec esp/tunnel/192.168.0.1-192.168.0.2/require; spdadd 192.168.0.2 0.0.0.0/0 any -P out ipsec esp/tunnel/192.168.0.2-192.168.0.1/require; If you do not really need AH, then you can move to this configuration, and confirm us that you don't have the crash anymore. Of course, as I already said, the issue will still be in the code Yvan. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Support for IPSec NAT-T in transoprt mode
Hi. On Sun, Apr 15, 2012 at 04:40:03PM +0300, Zmiter wrote: > 14.04.2012 19:59, Bjoern A. Zeeb ??: > >On 13. Apr 2012, at 04:28 , Zmiter wrote: > > > >>Hello. > >>Does FreeBSD 8.[0-4] support IPSec NAT-T in transport mode? Or it's still > >>in broken state? > >It's not broken; it was never implemented. No FreeBSD tree shipped does > >support transport mode at this time. There are patches but you also need > >to fix ipsec-tools or your ike daemon. If you do the latter I can commit > >the former. > > > >/bz > > > Where could I get that patches? I'd like to test them and to see what > could I do with them. You can get kernel patches in kern/146190, but as said in the pr and by Bjoern, it needs some work on userland (IKE daemon). > And, if it's really so difficult to implement transport mode in kernel > some way, I didn't review/try the patch, but kernel part seems to be done. > describe it (I think, all the work for third parties will be > implemented through pfkey interface), and wait some time (or may be help > a little) until it'll be implemented in ipsec-tools. > It's not the egg and chicken problem, may be the kernel must be the > first. Or may be I'm not in theme so deep? Is it really some sort or big > and principal incompatibilities with ipsec-tools? That's why I took the pr a while ago: to have a look at both parts (kernel and ipsec-tools) and try/commit that once patches exists for both. Afaik, no one already worked on the userland part for ipsec-tools (contact me if I'm wrong !). Yvan. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Enabling IPSec panics stable/9 (runs OK on stable/8)
On Thu, Jan 05, 2012 at 11:20:48AM +0100, Attila Nagy wrote:
> On 01/04/12 17:31, VANHULLEBUS Yvan wrote:
[]
> >Could you check that you are running a correct debug kernel ?
> The kernel config is GENERIC, plus some, so it contains DEBUG=-g
> makeoptions.
Ok.
[]
> (kgdb) frame 7
> #7 0x809bf779 in ipsec_process_done (m=0xfe001977a600,
> isr=0xfe019eb96480) at
> /data/usr/src/sys/netipsec/ipsec_output.c:170
> 170 switch (saidx->dst.sa.sa_family) {
> (kgdb) p saidx
> No symbol "saidx" in current context.
>
> BTW in the same frame:
> (kgdb) p tdbi
> $1 = (struct tdb_ident *) 0xfe017ce5e418
> (kgdb) p mtag
> $2 = (struct m_tag *) 0xfe017ce5e400
> (kgdb) p isr
> $3 = (struct ipsecrequest *) 0xfe019eb96480
Strange. may be related to some kind of code optimization
As the line juste before is:
saidx = &sav->sah->saidx;
Could you show the value of &sav->sah->saidx ?
And also check if kgdb can print sav->sah->saidx (without the &) ?
> >>Strange I'll review changes in IPsec stack which have been done in
> >>STABLE/9 and not backported to STABLE/8.
> >>
> >>Oh, sorry, not quite an up-to-date 8-STABLE, it's from Sat May 21
> >>22:05:26 CEST 2011 (csup'd some hours earlier).
> >>Should I check with a more recent version? Does that help?
> >>Thanks for helping.
> >
> >Yes, this may help if you try with a most recent 8-STABLE: I don't
> >remember exactly what, but I'm quite sure there have been some IPsec
> >related commits on stable/8 between that date and now !
> I will try it.
Ok.
To help you having a quick workaround, do you really need ESP+AH ?
Most of the time, people who configure ESP+AH just needs in fact ESP
with optional data authentication.
And the crash occurs in some part of the code which deals with
encapsulation in encapsulation.
This also may explains why I never saw that crash..
Yvan.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Enabling IPSec panics stable/9 (runs OK on stable/8)
On Wed, Jan 04, 2012 at 04:17:41PM +0100, Attila Nagy wrote:
[]
>#7 0x809bf779 in ipsec_process_done (m=0xfe000c7c7a00,
>isr=0xfe001bf54380) at
>/data/usr/src/sys/netipsec/ipsec_output.c:170
>
> Here seems to be the problem
> Can you do the following (in this order) in kgdb:
> frame 7
> p saidx
> p *saidx
>
>(kgdb) frame 7
>#7 0x809bf779 in ipsec_process_done (m=0xfe000c7c7a00,
>isr=0xfe001bf54380) at
>/data/usr/src/sys/netipsec/ipsec_output.c:170
>170 switch (saidx->dst.sa.sa_family) {
>(kgdb) p saidx
>No symbol "saidx" in current context.
There *is* such a symbol, as confirmed by kgdb's output when you
switched to frame 7 !
Could you check that you are running a correct debug kernel ?
> The latest will probably generate an error, as (if you have the exact
> same ipsec_output.c as I have from HEAD) saidx will probably have an
> invalid adress.
>
>I have the same as in HEAD.
Yep, kgdb's outputs confirms that (at least for this line, which is
the most important).
> [...]
>
>8-STABLE runs fine with the same config.
>
> Strange I'll review changes in IPsec stack which have been done in
> STABLE/9 and not backported to STABLE/8.
>
>Oh, sorry, not quite an up-to-date 8-STABLE, it's from Sat May 21
>22:05:26 CEST 2011 (csup'd some hours earlier).
>Should I check with a more recent version? Does that help?
>Thanks for helping.
Yes, this may help if you try with a most recent 8-STABLE: I don't
remember exactly what, but I'm quite sure there have been some IPsec
related commits on stable/8 between that date and now !
Yvan.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Enabling IPSec panics stable/9 (runs OK on stable/8)
On Wed, Jan 04, 2012 at 01:46:03PM +0100, Attila Nagy wrote: >Hi, Hi. >I've just upgraded a 8-STABLE box to 9-STABLE (well, just few commits >before it has been tagged as STABLE), which runs from NFS (pxebooted). >It has some IPSec config in ipsec.conf, like this for several boxes: >add 172.28.16.4 172.16.248.2 ah 15704 -A hmac-md5 "asdfgh"; >add 172.16.248.2 172.28.16.4 ah 24504 -A hmac-md5 "asdfgh"; >add 172.28.16.4 172.16.248.2 esp 15705 -E blowfish-cbc "hgfdsa"; >add 172.16.248.2 172.28.16.4 esp 24505 -E blowfish-cbc "hgfdsa"; >spdadd 172.28.16.4 172.16.248.2 any -P out ipsec > esp/transport/172.28.16.4-172.16.248.2/default > ah/transport/172.28.16.4-172.16.248.2/default; There is probably nothing related to the crash, but do you really use static IPsec without IKE keying [] >kgdb says: >(kgdb) bt >#0 doadump (textdump=1) at /data/usr/src/sys/kern/kern_shutdown.c:260 >#1 0x80845705 in kern_reboot (howto=260) >at /data/usr/src/sys/kern/kern_shutdown.c:442 >#2 0x80845bb1 in panic (fmt=Variable "fmt" is not available. >) >at /data/usr/src/sys/kern/kern_shutdown.c:607 >#3 0x80b167a0 in trap_fatal (frame=0xc, eva=Variable "eva" is >not available. >) >at /data/usr/src/sys/amd64/amd64/trap.c:819 >#4 0x80b16ae9 in trap_pfault (frame=0xff80002cd2a0, >usermode=0) >at /data/usr/src/sys/amd64/amd64/trap.c:735 >#5 0x80b16faf in trap (frame=0xff80002cd2a0) >at /data/usr/src/sys/amd64/amd64/trap.c:474 >#6 0x80b012ef in calltrap () >at /data/usr/src/sys/amd64/amd64/exception.S:228 >#7 0x809bf779 in ipsec_process_done (m=0xfe000c7c7a00, >isr=0xfe001bf54380) at >/data/usr/src/sys/netipsec/ipsec_output.c:170 Here seems to be the problem Can you do the following (in this order) in kgdb: frame 7 p saidx p *saidx The latest will probably generate an error, as (if you have the exact same ipsec_output.c as I have from HEAD) saidx will probably have an invalid adress. [...] >8-STABLE runs fine with the same config. Strange I'll review changes in IPsec stack which have been done in STABLE/9 and not backported to STABLE/8. Yvan. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SPD
On Fri, Mar 25, 2011 at 12:28:53PM -0400, Stephen Clark wrote: > Hi, Hi. > If one has multiple entries in the SPD some representing more specific > network addresses not to be encrypted and sent over an > ipsec tunnel vs more general networks that would be encrypted would this > work? > > In other words say I have a x.x.0.0/16 that should encrypted but in that > x.x.0.0/16 I don't want x.x.84.0/23 > to be encrypted could I do that? If so is dependent on the order the SPD > entries are made? Yes, SPD entries are ordered. Just set up first specific SPD entries for traffic which must not be encrypted, then the tunnel/transport entries for networks. Yvan. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: IPSec NAT-T in transport mode
Hi. On Thu, Jan 21, 2010 at 04:36:12PM +, David Murray wrote: [...] > On 2010-01-20 Wed 1:22 pm, Crest wrote: > > >Yes the NAT-T Patch has been integrated into FreeBSD 8.0. > > > >Just rebuild your kernel with this options: > >device crypto # IPsec depends on this > >options IPSEC > >options IPSEC_DEBUG > >options IPSEC_NAT_T > > I'm trying to do the same thing as the OP, so thanks for these replies. > > However, they seem to be at odds. Are we saying that the NAT-T patch is > there, but is missing checksum re-calculation, so MPD's packets are > going to be discarded? Yes, see my other mail in this thread. > (FWIW, this seems to be what happens. All the negotiation to set up > IPSEC SAs happens, but MPD's log never shows a single entry. I hadn't > got as far as packet dumps when this thread popped up.) And if you have a look at system stats, you'll see lots of UDP packets dropped because of invalid checksums Yvan. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: IPSec NAT-T in transport mode
On Wed, Jan 20, 2010 at 03:16:02PM +0600, Rabidinov M.A. wrote: > Hello, Freebsd-stable. Hi. > Does FreeBSD 8.0 support IPSec NAT-T in transport mode? > I want to create a L2TP/IPSec server. My VPN clients are NATed. > L2TP server (MPD5.x) makes tunnel, so I need working IPSec NAT-T in transport > mode. > Thanks a lot. It may work. or not The missing part is support of NAT-OA payloads, which are used to update checksums when receiving packets. For TCP, this is mandatory. For UDP (so for L2TP), checksums of 0 are allowed, and of course not checked, so packet will go to destination. But afaik, most L2TP implementations computes checksums, so they will be checked, and of course will be wrong Yvan. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ifconfig won't allow me to change ether address and inet address in the same command
On Tue, Oct 21, 2008 at 04:48:50PM -0200, Eduardo Meyer wrote: > Hello :) Hi. > Please, follow: > > # ifconfig rl0 ether 00:02:4f:0a:ce:f3 inet 192.168.2.12 netmask 255.255.255.0 > ifconfig: can't set link-level netmask or broadcast > > # ifconfig rl0 inet 192.168.2.12 netmask 255.255.255.0 ether 00:02:4f:0a:ce:f3 > ifconfig: ether: bad value > > # ifconfig rl0 inet 192.168.2.12 netmask 255.255.255.0 > # ifconfig rl0 ether 00:02:4f:0a:ce:f3 > > I ask you some help, how can I accomplish both tasks with rc_ng? In > /etc/rc.conf > > ifconfig_rl0="inet 192.168.2.12 netmask 255.255.255.0 ether 00:02:4f:0a:ce:f3" > > Won't allow me to do what I want. Any suggestions? I would like like > to edit /etc/rc.local and any other kind of "workaround". Can rc.conf > issue ifconfig twice for the same nic? > > Or can ifconfig accomplish this task by someway else other than > issuing the command twice? For your information, I already filled PR bin/124004 some moths ago related to that issue. Yvan. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
