Re: [RFC/RFT] projects/ipsec

[Jim Thompson]

> In it's initial state if_ipsec allows to use only one set of encryption 
> parameters (because only one sainfo anonyumous is possible), so at this time 
> it doesn't allow to create multiple tunnels with VPN hubs that use different 
> cipers and/or transform sets, but as far as I understand this is subject to 
> change and Andrey is already working on a support of this feature from 
> ipsec-tools IKE daemon.

pfSense (which you mention below) is using strongswan, so when Andrey
is finished with ipsec-tools, we will need to review his changes and
see what we can do for strongswan.

I'm looking forward to the mutliple-tunnel support, which is required
for pfSense.

> But even in this state this feature is already useful and I'm excited to see 
> it commited to HEAD and then MFC'd to 11.x, to start using it in my 
> production network (as you may know, buiding gre/ipsec tunnels on Juniper is 
> very hackish and tricky, bit I still have more than dozen of them). I've 
> already saw a discussion on FreeBSD web forums, and people there are excited 
> about if_ipsec too.

> Furthermore, I believe that guys using pfSense will be very happy about 
> if_ipsec in their routers, because I saw several discussions mentioning 
> missing VTI support there.

I'm not sure what discussions you saw.  We're aware, and very
interested in the VTI support.
https://twitter.com/gonzopancho/status/809412164259893248

On Wed, Dec 14, 2016 at 10:52 AM, Eugene M. Zheganin  wrote:
> Hi,
>
> On 11.12.2016 4:07, Andrey V. Elsukov wrote:
>>
>> Hi All,
>>
>> I am pleased to announce that projects/ipsec, that I started several
>> months ago is ready for testing and review.
>> The main goals were:
>>* rework locking to make IPsec code more friendly for concurrent
>>  processing;
>>* make lookup in SADB/SPDB faster;
>>* revise PFKEY implementation, remove stale code, make it closer
>>  to RFC;
>>* implement IPsec VTI (virtual tunneling interface);
>>* make IPsec code loadable as kernel module.
>>
>> Currently all, except the last one is mostly done. So, I decided ask for
>> a help to test the what already done, while I will work on the last task.
>>
> Well, at last FreeBSD got one of the most anticipated features in it's ipsec
> stack. When I wrote the message in the freebsd-net ML in the middle of 2012
> (https://lists.freebsd.org/pipermail/freebsd-net/2012-June/032556.html) I
> had a very little hope that someone will actually implement this, and now
> I'm very grateful that Andrey got the time to do this (and I'm really sorry
> for being such a pain in the ass, I'm saying so because I was bothering
> Andrey all this time in IRC). This isn't definitely a feature that every
> FreeBSD enthusiast will use, and, sadly, even not the feature that every
> network engineer that use ipsec in it's every day work will configure (many
> people still use obsoleted legacy interfaceless ipsec approach, not to
> mention weird and hybrid software routers like openvpn), but it's definitely
> a feature that will be appreciated by every skilled L3 VPN engineer that is
> using FreeBSD in it's operating stack. I've ran some tests in my production
> network and I should say that even on it's initial release state if_ipsec is
> fully operational with Juniper st tunnel on the other side, so I'm already
> running one FreeBSD <--> Juniper tunnel at my work:
>
> # ifconfig ipsec0
> ipsec0: flags=8051 metric 0 mtu 1400
> tunnel inet 128.127.144.19 --> 128.127.146.1
> inet 172.16.3.104 --> 172.16.3.105 netmask 0x
> inet6 fe80::204:23ff:fec7:194d%ipsec0 prefixlen 64 scopeid 0x9
> nd6 options=21
> reqid: 16385
> groups: ipsec
>
> racoon.conf:
> path pre_shared_key "/usr/local/etc/racoon/psk.txt";
>
> padding {
> maximum_length 20; # maximum padding length.
> randomize off; # enable randomize length.
> strict_check off; # enable strict check.
> exclusive_tail off; # extract last one octet.
> }
>
> listen {
> isakmp 128.127.144.19 [500];
> strict_address; # requires that all addresses must be bound.
> }
>
> timer {
> counter 5;
> interval 20 sec;
> persend 1;
>
> phase1 30 sec;
> phase2 15 sec;
> }
>
> #
> # SPb, Test
> #
>
> remote 128.127.146.1 {
> exchange_mode main;
> lifetime time 1 hour;
> my_identifier address 128.127.144.19;
> peers_identifier address 128.127.146.1;
> passive off;
> proposal_check obey;
> dpd_delay 20;
> proposal {
> encryption_algorithm des;
> hash_algorithm md5;
> authentication_method pre_shared_key;
> dh_group modp768;
> }
> }
>
> #
> # SPb, Test
> #
>
> sainfo address 0.0.0.0/0 [500] any address 0.0.0.0/0 [500] any {
> pfs_group modp768;
> lifetime time 60 min;
> encryption_algorithm des;
> authentication_algorithm non_auth;
> compression_algorithm 

Re: BBB (cpsw(4)) seems to be broken in the latest 11-current

[Jim Thompson]

There are recent changes to enable the switch and two port MAC mode. 

These were lightly tested on BBB prior to being committed. 

-- Jim

> On Jun 18, 2016, at 11:49 AM, Maxim Sobolev  wrote:
> 
> Well, I am not sure either as I don't have any issue restarting it
> afterwards.
> 
> Yes, it seems to be happening fairly reliably here. :( Happened for me
> again, I left it running overnight. I am 99% positive it was not the case
> before kernel upgrade..
> 
> 07:11:52 CPSW watchdog cpswss0: watchdog timeout
> cpswss0: Unable to cleanly shutdown transmitter
> 
> 
>> On Sat, Jun 18, 2016 at 1:09 AM, Svatopluk Kraus  wrote:
>> 
>> On Sat, Jun 18, 2016 at 8:50 AM, Maxim Sobolev 
>> wrote:
>>> Updated my BBB to the latest -current, immediately got this while trying
>> to
>>> make world over ssh console:
>>> 
>>> 06:02:17 CPSW watchdog cpswss0: watchdog timeout
>>> cpswss0: Unable to cleanly shutdown transmitter
>> 
>> My BBB stucks in cpsw0 during boot rarely, and even soft reset (reset
>> button) does not help. Only hard reset (power-off) helps. I have never
>> had time to discover where a problem is. I'm not even sure if this is
>> related to your problem as I did not remember exact dmesg in my case.
>> 
>> Svata
>> 
>> 
>>> 
>>> Interface seems to be locked after that, no traffic comes in or out.
>>> 
>>> This is:
>>> 
>>> FreeBSD 11.0-ALPHA3 #1 ba7edef(tps65217x)-dirty: Fri Jun 17 16:22:07 PDT
>>> 2016, svn revision 301898
>>> 
>>> The previous version that was rock-solid was:
>>> 
>>> FreeBSD 11.0-CURRENT #0 9d390ee(tps65217x)-dirty: Mon Jul  6 19:31:30 PDT
>>> 2015, svn revision 284878
>>> 
>>> I've been running buildworlds for literally days on that board, because
>>> it's how long it takes to build on that hardware. :)
>>> 
>>> I'll run it again and see if the issue re-appears.
>>> 
>>> If anyone seen this or if it's known issue please let me know.
>>> 
>>> Thanks!
>>> 
>>> -Max
>>> ___
>>> freebsd-...@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>>> To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org"
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Leaving the Desktop Market

[Jim Thompson]

On Apr 1, 2014, at 6:57 AM, Sean Bruno sean...@yahoo-inc.com wrote:

 Why even bother?  Its over, just embrace the future and be like this
 happy Mac user:
 
 http://people.freebsd.org/~sbruno/happy_desktop_user.jpg

I have Macs at work (typing on one now), and a mac at home.  I like them.

I recently installed FreeBSD 10 on an Intel i5 NUC.  16GB ram, and a 120GB 
m-SATA SSD.
I put a nice keyboard and an old 19” Dell monitor on it, used vidconsole to 
make the screen
green on black, and a decent resolution.

It’s just like being back in the 80s, when Unix had a desktop market, only 
much, much faster.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ipfilter(4) needs maintainer

[Jim Thompson]

On Apr 14, 2013, at 5:25 PM, Mark Martinec mark.martinec+free...@ijs.si wrote:

 ... and as far as I can tell none of them is currently usable
 on an IPv6-only FreeBSD (like protecting a host with sshguard),
 none of them supports stateful NAT64, nor IPv6 prefix translation :(

pfSense 2.1 has a lot of work to make this happen for pf, so it should be 
possible for pf with some attention.

Jim

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org