Re: replacement of security/ipsec-tools
Victor Sudakov wrote:
> >
> > If you ever find good documentation/howto for strongswan on FreeBSD,
> > please share with me.
>
> Really, please! I know there are people present here using strongswan.
>
> I would like to try and replace racoon with it.
Now thanks to Sergey Matveev and some good docs on
https://wiki.strongswan.org/ , I have some working examples of
strongswan usage. I must admit it is rather elegant.
But for this bug-or-feature:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
I could even easily and elegantly secure all communications between my
FreeBSD hosts (I can't of course due to the above bug, but this is not
strongswan's fault).
However, not the same with Windows. By much experimenting, I once
created a working configuration for IPsec transport mode between FreeBSD
and Windows with racoon:
remote "win2012" {
exchange_mode main;
my_identifier address;
peers_identifier address;
remote_address 192.168.246.12;
proposal_check obey;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2;
}
}
sainfo anonymous {
pfs_group 2;
lifetime time 1 hour;
encryption_algorithm aes,3des;
authentication_algorithm hmac_sha512,hmac_sha384,hmac_sha256,hmac_sha1;
compression_algorithm deflate ;
}
But now when I try to replace racoon with strongswan, the following
configuration does not work:
conn Win2012
keyexchange = ikev1
ike=3des-sha1-modp1024!
esp=3des-sha1-modp1024!
left=192.168.246.1
right=192.168.246.12
type=transport
compress=yes
authby=psk
auto=route
In Wireshark, I see ISAKMP exchange between 192.168.246.1 and
192.168.246.12. Also "service strongswan status" reports that there is a SA:
Security Associations (1 up, 0 connecting):
Win2012[5]: ESTABLISHED 114 seconds ago,
192.168.246.1[192.168.246.1]...192.168.246.12[192.168.246.12]
but in fact there are none:
# setkey -D
No SAD entries.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
signature.asc
Description: PGP signature
Re: replacement of security/ipsec-tools
Michael Grimm wrote: [dd] > > Then this mail made my day: > > >> What do I need? > >>#) a VPN tunnel between two hosts > >>#) both local networks reachable from the remote host > > > > That is what kernel IPSec is for, you can even do it on static keys > > without any ISAKMP daemon like racoon. See an example in if_ipsec(4). > > I did install my IPSEC/racoon tunnel many years ago and missed the recent > implementation of if_ipsec completely. > > Victor, thank you very, very much for pointing me to this interface. > Now, my tunnel is far less complicated to implement[1], and I will no > longer need security/ipsec-tools at all! You are welcome. But maybe one day you'll want to change your IPSec keys more often than in a manual setup, then you'll return to some ISAKMP implementation. I've been trying out strongswan for the last 2-3 days and must admit it's not that scary when you grasp the concept. But it is not without its problems either, see my another post about it. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
[Bug 242744] IPSec in transport mode between FreeBSD hosts blackholes TCP traffic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744 Bjoern A. Zeeb changed: What|Removed |Added CC||b...@freebsd.org --- Comment #26 from Bjoern A. Zeeb --- I think anyone looking into this should look at the later RFCs not the original ones: https://tools.ietf.org/html/rfc4301 section 4.1 and appendix D.1 might be the best starting points. Searching the document for "transport" will yield more easily. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [PATCH] ipoib: Patch for crash in icmp_error, fault trap 12
Thank you for your patch: https://svnweb.freebsd.org/changeset/base/356633 --HPS ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: replacement of security/ipsec-tools
On 1/11/2020 05:23, Victor Sudakov wrote:
> Victor Sudakov wrote:
>>> If you ever find good documentation/howto for strongswan on FreeBSD,
>>> please share with me.
>> Really, please! I know there are people present here using strongswan.
>>
>> I would like to try and replace racoon with it.
> Now thanks to Sergey Matveev and some good docs on
> https://wiki.strongswan.org/ , I have some working examples of
> strongswan usage. I must admit it is rather elegant.
>
> But for this bug-or-feature:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744
> I could even easily and elegantly secure all communications between my
> FreeBSD hosts (I can't of course due to the above bug, but this is not
> strongswan's fault).
>
> However, not the same with Windows. By much experimenting, I once
> created a working configuration for IPsec transport mode between FreeBSD
> and Windows with racoon:
>
> remote "win2012" {
> exchange_mode main;
> my_identifier address;
> peers_identifier address;
> remote_address 192.168.246.12;
> proposal_check obey;
> proposal {
> encryption_algorithm 3des;
> hash_algorithm sha1;
> authentication_method pre_shared_key;
> dh_group 2;
> }
>
> }
>
> sainfo anonymous {
> pfs_group 2;
> lifetime time 1 hour;
> encryption_algorithm aes,3des;
> authentication_algorithm
> hmac_sha512,hmac_sha384,hmac_sha256,hmac_sha1;
> compression_algorithm deflate ;
> }
>
>
> But now when I try to replace racoon with strongswan, the following
> configuration does not work:
>
> conn Win2012
> keyexchange = ikev1
> ike=3des-sha1-modp1024!
> esp=3des-sha1-modp1024!
> left=192.168.246.1
> right=192.168.246.12
> type=transport
> compress=yes
> authby=psk
> auto=route
>
> In Wireshark, I see ISAKMP exchange between 192.168.246.1 and
> 192.168.246.12. Also "service strongswan status" reports that there is a SA:
>
> Security Associations (1 up, 0 connecting):
> Win2012[5]: ESTABLISHED 114 seconds ago,
> 192.168.246.1[192.168.246.1]...192.168.246.12[192.168.246.12]
>
> but in fact there are none:
>
> # setkey -D
> No SAD entries.
Strongswan works fine with Win10 HOWEVER note that Windows 10 until
somewhat recently (last summer, I believe) and ALL PREVIOUS VERSIONS
(e.g. Win7, 8, etc.) had a SEVERE problem with IkeV2 connections, which
you want, in that their fragmentation support was just flat-out broken.
What you'd see is the part of the initial ISKAMP exchange but you never
got the full message in both directions.
Thus if you had a path that refused UDP frags the connection would never
come up. Once it was connected it was fine but these days due to the
abusive potential for frag UDP packets they are often black-holed
somewhere between source and destination. This is now fixed for Win10,
however, I believe there's no fix for Win8 and before. Allegedly Ikev1
will work with frags correctly in any event but I never got that working
well; until Microsoft fixed the IkeV2 frag problem I used to run OpenVPN
for Windows clients. Fortunately that's no longer necessary and the
internal IkeV2 client is a LOT faster in terms of performance over the
network than OpenVPN.
Here's the stanzas I use:
ca StrongSwan
cacert=CudaSystems.Int.crt
ocspuri=http://ocsp.cudasystems.net:
auto=add
conn %default
keyingtries=5
keyexchange=ikev2
fragmentation=yes
conn WinUserCert
left=%any
leftsubnet=0.0.0.0/0
leftcert=ipgw-rsa.denninger.net.crt
leftauth=pubkey
right=%any
rightsourceip=192.168.2.0/24
rightauth=eap-tls
eap_identity=%identity
auto=add
dpdaction=clear
dpddelay=300s
ike=aes256-sha2_256-prfsha256-modp1024
This assigns an address out of 192.168.2.0; you need to have your
firewall (which ideally is the same machine that's the gateway) handle
that properly for NAT out to the "wider world" assuming you want that
all to work.
Also, make very, very sure you do not publish an IPv6 listener via DNS
(e.g. "ipgw.denninger.net" does NOT resolve both an IPv6 and IPv4
address) because by default StrongSwan WILL respond to an IPv6
connection attempt. You can configure it to run dual-stack but it's a
bit tricky because your IPv6 prefix can (does) change dynamically and
thus you need to have something to detect that and re-write the source
IP and restart the stack if it happens. In addition Wind
[Bug 242744] IPSec in transport mode between FreeBSD hosts blackholes TCP traffic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744 --- Comment #27 from Victor Sudakov --- (In reply to Bjoern A. Zeeb from comment #26) Bjoern, can you formulate in a few own words what behavior you deem appropriate in accordance with the later RFCs? I can only say that what we have now is completely broken: you enable IPSec transport mode between FreeBSD hosts on your LAN (very easy and elegant with strongswan, as it turns out) and bummer! Your TCP does not work any more. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
